samwoo

+1 we are having this issue too where the SLA's are not being applied at the start, but further on in the process they are suddenly assigned (though I cannot figure out at what point). We are also having issues with Human Tasks prior to the SLA being automatically assigned... we use the Get Request Details to grab the Team (for Tasks) and when using this in the Human Task, it errors saying the Team doesn't exist, even though it does! We had to manually update about at least 10 ticket BPM instances this morning (I've been on a course so there may be more now) by manually setting the team in the Human Task instead of relying on the variable. Not sure if my second issue is related to the SLA issue or not though, but it appears to coincide.

In our New Starter Process, we initially used the Hornbill/Admin/Create a New User iBridge to create Hornbill Accounts after the relevant fields were populated from both when the ticket was logged and a Human Task prior to that to capture the User ID once the Support Team has set them up in Active Directory and the Exchange. Once the Hornbill account is created, the relevant roles and company is assigned to the new user Hornbill account and then the account is created as a connection to the ticket. (Yes we've taken into account if someone is a returner rather than a new starter, and the flow has been catering for that too). This has been working for over 6 months, but suddenly yesterday and today, all our New Starter requests have been failing at the Create Connection part of the step. It turns out that the iBridge node was no longer creating any Hornbill Accounts, which is causing the Create Connection node to fail since the New Starter doesn't exist in Hornbill. I couldn't find any error details anyway in the logs, nor could I find a way to extract the outputs of the iBridge node to timeline (I could only capture if the status is errored, and it was erroring). I then used the Hornbill Automation equivalent of the Create New User node, and it is also not creating the User Accounts as well. This has resulted in 7 New Starter Requests failing, with two non-related Tasks being cancelled (this makes absolutely no sense as these Tasks are another part of the parallel process... they shouldn't have been cancelled......) The workaround for this issue is to create the Hornbill accounts manually and restart the process, but because the other Tasks are cancelled, it has completely messed everything up. For now I will advise the Tech Support Team to create the User Accounts in Hornbill before they progress with the Task where the following node "attempts" to create the User account. ps. don't worry about the password being "password" - I have been testing to see if that could be an issue or not, and it isn't.

+1

Good afternoon, I would like to request a BPM Status field within the h_itsm_requests table that changes based on the status of the BPM, whether it's active, suspended, failed or completed. In addition, I would like to expose this field in the Request List where the values are colour coded. Active = Green Suspended = Orange Failed = Red Completed = Blue (of a sort) This will be useful to quickly see at a glance within a view the status of the BPM behind the ticket. (This is intended to complement the existing the existing Manage Executed Processes but for non-admin users) Thanks, Samuel

I tried it with popup instead of URL and as Gareth mention, it doesn't work. It displays [[h_summary]] in the Google Search field, instead of the actual summary of the ticket. URL works though but I can see the benefits of using popup, so this certainly needs looking at.

Hi @Berto2002, That would be useful - we will be looking to revamp our change process at some point this year. We still currently use forms alongside raising a ticket. Initially my thoughts on our new process (before anyone has come to me about it) is that all Change fields will be updateable whilst the ticket is being logged but are non-mandatory to allow users to raise tickets if they still don't have enough information on-hand or want to get something in place in a "Saved" state as it were. When the ticket is raised, a Human Task appears with the buttons to "Cancel" or "Submit" the Change. This gives them time to populate everything before it goes to the Change Board. Once the Change has been "submitted", throughout the process will be Human Tasks, where there may be a step to "Update Change" which could include non-mandatory fields for updating the h_proposed_start_time or other fields if changes are required. This is particularly useful if the Change Board disagrees with the proposed date but agrees on a new one for example in the same meeting. So yes, I think this would be useful for when we start to review our processes, but for all Change related fields. +1 Thanks, Samuel

+1

Sorry Mike, I re-read your requirements so the above is probably not helpful - I can't think of how it can be displayed in a chart at this time (it's the end of the day...) maybe someone else will have some ideas, or, alternatively you could explore writing a report, and using Power BI + R Script to script to receive the reports from Hornbill, and create charts for them if that's possible in your org.

Hi @Mike Jones, I don't know if this is what you are looking to achieve... But this is how I pulled it off... Start Date: End Date: ---------------------------------------------------- (Horizontal line...ish): [Apps Team - RESPONSE %]: [Apps Team - RESPONSE %] (Copied): No. Within Response: No. NOT Within Response:

+1 to having per user configurable "unreadColour" option(s)

@Berto2002 - Not sure if this is helpful, but if you use the Business Process to create linked request (for example if you want to imitate Parent/Child tickets) then you can set the source in the Business Process. For example, this is a part of our New Starter Process: A ticket is logged to the Housing Service (the IT side only, our Housing Dept. don't have Hornbill access). When the ticket is created via the BPM, you can grab the Request ID, which can then be used in the following nodes afterwards: So for example, you can manually set the Source of the ticket to something like "New Starter Request": If you want the user to be able to update the source of the current ticket logged, then you will probably need a Simple List and a Human Task, but by default the Source is set based on how it is logged in the first place, so there is "Request", "Email", "Analyst", "Portals" (I think), "Post" etc. but these can be overwritten by the Update Request -> Task node. Not sure if this is helpful, but this has been useful for us.

Hi @James Ainsworth, Did this ever move up the backlog? Thanks, Samuel

What we do in our BPMs, when tickets are logged we set the status to "New" as one of the first nodes. We also assign the ticket to the initial team, send the request logged notification email to the customer, then start the response and resolve timers. Following all of this and any other "pre-processing" that may need to take place, we suspend the process and "Wait for Owner". Once an owner is assigned, the response timer is marked at that point. I dont know how the timers are used for reporting though. Hope that helps.

+1

+1 to all the above

Good afternoon, Has the patch been rolled out yet?

+1

+1

+1

+1

I've noticed that a few weeks or so ago - but I wasn't able to invest a lot of time looking into that report I was doing, so I didn't do any further testing - so looks like it might be a bug?

+1, with agreement to George's first point at the very least.

Don't think it's possible, so +1

+1 - this would be useful.

+1 nice idea!!