Hornbill Staff DR

To conclude the topic of 2FA, this functionality is now available (build 3629 and later). ÂÂ

Hi @Stephen.whittle thanks for your post. When it comes to the intelligent capture asset form, assets can be filtered based on the customer's assets, assets shared with the customer (the customer being the user selected in the customer search form), assets that belong to a particular site (when the site selection form precedes the asset form), and assets that are associated to the same company as the customer. This filtering takes place on the relevant tabs in the form and there is the option to show/hide each tab in which provides us the option to only make certain filters available. The "Asset Search Term" simply sets a default value which appears in the search bar. If the user cleared this value, they could type something else and select from the available assets returned. So this field doesn't perform any filtering on the asset records accessible by the form, all assets would still be available (as per any filtering on customer/site/company). I don't think this will help with your requirement. The solution might lie in Hornbill's ability to denote the sharing of assets. Among other things, an asset can be configured as being shared with a Hornbill group. Perhaps explore creating groups (or type General) which represent each of the roles within the organisation (such as Doctors) and sharing assets with the appropriate group(s). On your asset selection form, limit the options to only show the "Shared" assets tab. In terms of managing these groups, it may mean you'll need several additional user import configurations to ensure the users are being placed in the correct groups (i.e. Doctors are being placed in the "Doctors" group) and of course this will be dependent on that information being available in the directory source and in a format that allows the user objects to be filtered reliably using the filter options available to us (e.g. LDAP object filters if the source is Active Directory). While this approach may attract more configuration in the area of user imports, it will should help reduce the complexity of your progressive captures. I hope that helps. Dan

Hi @SJEaton,  the serial approach should technically work, but I suspect it wont have precisely the desired affect when it comes to the checkpoints. In essence, you're wanting to use the checkpoints as an indicator showing when each of the linked requests are complete. When things are configured in series, it means there is a definite order and one thing has to happen after another. If you set your checkpoints up in series, lets say your last one is "Equipment Issued" even if the corresponding linked request is resolved first, that checkpoint wont be marked until the workflow has passed through the other checkpoints in sequence. So ultimately, yes, all your checkpoints will eventually get marked, but there will likely be a situation where a linked request is resolved but the corresponding checkpoint is not checked because the workflow is still waiting for one (or more) of the other linked requests to be resolved first. I'd dispense with the specific checkpoints and perhaps have a single one which indicates that "User Provisioning Actions Complete" or something generic like that. This will only be marked when all the linked requests are resolved. If an agent wants to see what's still outstanding, they should be directed to the linked requests section where they can inspect the status of the linked requests. I hope that helps. Dan

@SJEaton nice, always great to see advanced capability being explored! I'll first cover off how we can wait for a linked request to be resolved. While there isn't a specific business process operation which waits for linked request resolution, we can actually use the operation "Wait for Request Resolution". Indeed, this is typically used to wait for the resolution of the request against which the BPM is running but, if we switch the "Request ID" input param to "variable" and inject a variable which contains a request ID belonging to one of the linked requests, then this node will actually wait for the resolution of the request ID specified. You can get a request ID by using an output variable available in the "Log Request" node which is logging these child requests from your BPM. Now, focusing on your requirement a bit more specifically, you have several child requests which may be resolved in any order. So as you have surmised, you're going to need a parallel processing block that has several "Wait for Resolution" nodes corresponding to each child request. Unfortunately, I don't believe the business process engine is capable of handling multiple suspend nodes in a parallel block. When the engine resumes a suspended process, I believe it sends a generic "resume" instruction which doesn't include any node identifier. So basically if the process is waiting at multiple suspend nodes, when the resume instruction is given by the system, it doesn't know which node it needs to unsuspend. This is what I encountered the last time I tried this approach, and I believe that's still the case. Perhaps you could try and confirm that is so? Dan

Hi Dan,  thanks for your post. These are great suggestions and the Product Team has visibility. Additional multi select actions on the request list would be a great complement the ones already available. If you're interested to see what's coming through the development pipeline, the current roadmap can be viewed via Hornbill Configuration > Solution Centre > Roadmap Library. This area lists all the Hornbill applications and the current development stories working their way through. For the benefit of others who may come across this post, I'll leave a link to the current multi-select actions available in the request list: https://wiki.hornbill.com/index.php?title=Multi-Select_Actions Dan

@chriscorcoran thanks for your post. There's a handy quick reference available on our wiki which describes the main request table (h_itsm_requests).  It can be found here: https://wiki.hornbill.com/index.php?title=Table_Info:_Main_Request_Table . There's also the "Entity Explorer" built into the Hornbill Service Manager Application which describes all the tables and columns (see image below) and some info on our wiki here: https://wiki.hornbill.com/index.php?title=Application_Entity_Viewer If I've understood your needs correctly, I believe you want to see what the response and resolution targets are for each request. The response target is stored in h_respondby and the resolution target is stored in h_fixby (the resolution-related SLA columns use the word "fix" in their names). h_respondby and h_fixby store the timestamp of the current SLA targets. These columns are also available to display in your request list. This allows agents to sort using either the response or resolve targets which allows you to sort by those requests that will breach soonest. I hope that helps, Dan  ÂÂ

@Malcolm it appears we were both led down the garden path thanks to that description in the entity viewer. As Steve has indicated, apparently that column (h_email_datelastsent) is only populated under a particular circumstance, namely when you have a business process running against the request which contains a "suspend wait for email to be sent" node. Personally, if the column is there one would think its sensible to populate it at all times when an email is sent from a request, surely the suspend node could then still reference it in some way? Anyway, I'm sure there were reasons for the design, even though I can't fathom them! Sorry I can't be of further assistance on this one. Dan

Hi @Malcolm thanks for your post. I believe you'll be referring to the column in the table h_itsm_requests called h_email_datelastsent. Using the Entity Viewer I've checked the description of that column and it should be storing "the last date of when an email has been sent from the request". So we should be able to use this in a report to understand when the last email was sent from a request. Obviously, it won't tell us who sent the email (but one would assume that this would usually be the owner of the request doing the sending), or to whom it was sent. To be honest, I would think that the who doesn't matter so much as you're probably most interested in confirming that some outbound correspondence has actually taken place within the last x days. From my checks, I can't see this actually updating when I send an email from a request so I'll have to defer to development to see what's going on. Dan

Hi Dan,  thanks for your post. From what I understand currently, MS Project Online doesn't offer an integration opportunity that can be packaged into the Hornbill iBridge. However, Hornbill iBridge does offer the ability to trigger Flows in MS Power Automate. This offers lots of opportunity when it comes to integration with Microsoft products. The Power Automate operations available for MS Projects Online can be found here: https://powerautomate.microsoft.com/en-us/connectors/details/shared_projectonline/project-online/ Once you've built your Power Automate Flow, simply use the Hornbill iBridge operation Microsoft > Flow > Trigger Flow to trigger the desired flow. I hope that helps Dan

Hi @Jeremy,  its an interesting ask. Typically, I would never advise that a two-stage closure set up is removed. An exception might be in specific requests (e.g. new starter, hardware,) where the process is established and reliable in fulfilling the customer needs. Here a two-stage closure may not offer value because the bpm is helping to ensure things are delivered the right way, every time. As I'm sure you're aware, the period between resolution and closure is intended to give the customer opportunity to confirm the resolution has been successful or re-open the request. I appreciate the distinction between resolution and closure is sometimes lost on the customer, but going directly to closed sets the precedence that closed requests can be reopened. Where is the line then drawn? Can a customer come back and open a closed request 3, 6, or 12 months later? Effectively, the ticket doesn't have an end to its lifecycle. If the bpm was adjusted to ensure resolution emails were sent after a ticket was reopened from closed, the bpm would technically never complete because you have to keep the bpm active in order to catch a reopen action and then loop to a wait for resolve before then sending the resolution email again. There are elements in Hornbill that are specifically designed to instil good practice. The two stage closure, "Its working/It's still broken" buttons, and feedback only being left once closed are the three elements involved here. There isn't really a way to circumvent these best practices without causing problems elsewhere. From my perspective, closed is closed and shouldn't be reopened. I'd suggest experimenting with the duration of the two stage closure, or remove the resolution text from the email and have a generic notification stating that their resolution is available in the portal. Forcing the customer to interact with the portal, thus building familiarity. Other campaigns outside of the tool to raise portal awareness and how feedback can be left will also help. Dan

I see. So the motivation is to increase the quality of feedback? Just to claify, I notice you state that the customer "cannot give feedback" which might imply customers simply aren't bothering to leave feedback. Do you find you receive a good number of feedback responses and it is just the quality of feedback that's lacking? ÂÂ

HI @Jeremy thanks for your post. I'd be interested to know why you feel that feedback can't exist in a two-stage closure situation, can you elaborate on your decision to remove two-stage closure? Dan

Hi All,  thanks for reporting the issue(s) and taking the time to supply the supporting screen shots. Hornbill Support are currently on the case and will provide update in due course. Dan

Hi @JAquino,  thanks for your post, The assets that are owned by, used by, or shared with a user can be found in one of two ways: From the asset list, use the asset search option (the stand-alone magnifying glass located next to the quick filter). Selecting the "Used By" condition and specifying a user will have the desired effect and return asset records shared with that user. The alternative is to approach it from the user's Profile. A users profile can be accessed from the Co-Worker directory (https://wiki.hornbill.com/index.php?title=Co-Workers) (Home Icon > Co-Workers) then search and select the specific user to view their profile. A Co-Worker can also be searched for using the Global Search bar at the top of the Hornbill interface Assets are available in the "Service Manager" tab as shown in the image: The quick filter doesn't act upon the list of users an asset is shared with, it only acts upon asset attributes which exist directly against an asset record. I hope that helps, Dan

Hi @Malcolm,  the following wiki page describes how to identify whether a user owns Documents or Libraries and to change ownership: https://wiki.hornbill.com/index.php?title=Change_Ownership . With regards to identifying which tasks a user is assigned, what @nasimgsuggests is a good idea. As the users manager you are able to see the tasks currently assigned to that user via the "My Activities" interface. However, only the task owner or task assignee are able to complete or edit a task (the specific detail on tasks is available here: https://wiki.hornbill.com/index.php?title=Activities ) There is a very useful Service Manager feature enabled by the setting app.experimental.advancedRequestTaskCompleter The advanced task completer feature extends the concepts of Team membership and Service supporting teams enjoyed by requests, to tasks. It should be noted that this only applies to tasks that are associated to requests. Detail can be found here: https://wiki.hornbill.com/index.php?title=Service_Manager_Experimental_Features I hope that helps. Dan