Berto2002

You may have a challenge putting nested authorisations in parallel working. There is an undocumented limitation in Service Manager that some nodes don't work and are unsupported in parallel streams. Our approach to approval escalations is not to move the approval up the chain but to inform the authorisers line manager that the authoriser hasn't responded and ask them to give them a kick to get it done. To do that we use nodes to get the authoriser's line manager and email them:

This is the flow we use for what we call "offline" approvals for Change Records: You have a human task for the analyst (change manager for us) to define which approvers: And then, depending on the number selected, the parallel workflow selects the one route that is appropriate and that node distributes the approvals by a suitable percentage. Each variable comes from the change manager's selection (or we also have one or two hardcoded ones):

Hi @Steve Giller, I can see how an incorrect format there would caus an issue. But the only way that field can be entered is using the 'UI wizard' by clicking the edit icon and it comes-up with this: [{"displayName":"Name Name","email":"NameName@domain.gov.uk","optional":"Required"}] If the format is incorrect it would suggest it's something Hornbill need to fix so the wizard outputs the correct format?

Trying to use this: Calendar / Create Calendar Event (hornbill.com) "When adding an event to a Users calendar, the userId parameter should be provided, and optionally calendarId" Am getting these outputs where the "Status: ok" but no event ID or error and would expect one or the other. Anyone using this? Something is broken on iBridge or config wrong here?

@Damien Lynn we have an autotask that cancels generic incidents and logs new requests (and vv) in a single autotask; for use at triage if the customer has logged the wrong type of generic ticket. The email that goes out is this:

+1 again to this. Not thought of using Connections for Change before; could be useful. But until we can add one person to multiple roles I won't...

We call ours "Unable to find what you're looking for?" The original belief was that we would analyse these and create new types to reduce the use of this cat item. In reality, users have such a HUGE variety of issues you can't ever get rid of it and a generic SR and generic IN is an efficient way to do it

Wow! @Fizza

Does that list also affect this view in service portfolio and allow full config of the utilisation of connections by service?

@samwoo inferring we are able to rename connections or add new types? How are you specifying the connection type as "Implementer", "Tester" etc?

The string here is just the data type; this is just asking you to enter the Role Name (or RoleID) manually or as a variable from a Get node

+1 pleeeeease. Just should never have a pop-up that obscures a mandated field; we can neither see nor edit the closing profile until we do another click so it's added one click to everyone closing every ticket...

+1 for sure. But then Hornbill have already committed to an overhaul of the Service Portfolio so I hope this kind of requirement was catered for. If you alter the Design of the Custom Fields of the Service, the changes are replicated across all services so there is a precedent for this type of behaviour

Bringing this up again as my analysts are still finding retired archived assets when raising changes and getting confused. @Steve Giller did this get assessed for inclusion please. Requirement is either filter to allow retired/archived assets to not be exposed for user/analyst use and or for the status/state to be exposed to allow them to see status/state. Explanation I have to give to analysts: "Sorry folks, I can neither filter-out those retired/archived assets nor reveal their status/state on the view you see when linking. This is something I have asked Hornbill to implement but no news yet. You need to right click to open the asset to check the status/state if in doubt and then only link active current assets, please. I will update the Hornbill forum post each time it is reported to me to keep the issue visible."

While there is an experimental method for this, I think it remains a popular enhancement request.

This seems popular

This is one of the reasons we restrict the option to "cancel" to admins; you have to remember to remove from the board. Of course you can build-in workflow to allow analysts to cancel changes themselves; whereupon you can include nodes to move the card to a cancelled lane.

This remains on our long-term hit-list for enhancements. Alignment of the Data Providers as Paul puts it, between ICF and Workflow.

@Steve Giller noticed this is not tagged as enhancement. Could you please?

Bump...

I am pleased to say I believe we have a solution to this now. Ping me if anyone else would like to know what it is.

Wow. Many thanks. This is also a great contribution for others to read in future. Looking forward to meeting you at HUG24 in March; I gather you're on the bill @Gareth Cantrell

@Gareth Cantrell that was a very helpful mock-up and I think there might be enough there for us to test it. Am I asking too much to ask you for the equivalent for updates the other way? I.e. pushing/pulling a customer update on a Hornbill Request into the JIRA Cloud Issue. @SamS I found this link for Webhooks (Webhooks (hornbill.com)) but I could not find a reference in there for how triggers work and as a result I can't write the trigger to test using the third part webhook system. Can you give any pointers to either docs or more info on what is required in there please or an example expression for a use case so we get the idea? The two use cases are: A Customer updates a Hornbill Request and we want that 'sent' to Jira Cloud (this would only happen for Requests where Custom 33 had a JIRA Cloud issue reference) A technician updates a JIRA Cloud Issue with a 'customer' type update and we want that added to the Hornbill Request timeline with a Customer visibility Many thanks in advance.

We've altered the last one from purpose/aim to: Validation - All steps taken and results documented - 1 - Some steps incomplete or results not captured - 0

I'm moving away from the classic "failed/success" change outcomes and have planned these five. Any comments from other SM users or perhaps feedback on what you guys do and what works in your environments? Binary 'values' for each and required one-line explanation for any '0' answers Implementation - Fully implemented as planned - 1 - Partial implementation or back-out - 0 Impacts on Services / Users - Impacts as defined and communicated - 1 - Greater or lesser impacts - 0 Detail of steps - As defined in the CR or procedures - 1 - Fewer, more or amended steps - 0 Scheduling and timing - Timing went to plan and in window - 1 - The planned timings didn't work out - 0 Purpose / aim - Fully achieved (fixed/delivered) - 1 - Not fully achieved - 0 These sum into change "Levels" 1-5 in the change board (a kind of gamification) and anything with either the Implementation as '0' or if it has two or more '0' gets pushed in Workflow for a post-implementation review (PIR). In addition, a short written statement representing each positive or negative answer is compiled into an automatic paragraph of the outcome and posted to the resolution and our teams channel such as: