Berto2002

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:

We've just noticed this portal UI issue which seems to be present across most of our ICFs: In the example below, the field "In a few words..." is our h_summary. It's required but for some reason the red bar that indicates the required status is greyed-out; until you click the field. This is causing our users to only enter data in the "Please provide full..." (h_description) field but then they fail validation when pressing NEXT; because they get reminded to enter the summary. Can this be fixed please? All required fields should have the red flag and star consistently. The same issue is present in other ICFs but it's not always the first field. This is our New Starter form where the issue appears in the mid section but not at the top or bottom:

Thanks both I will review with my infra guy and see what we can get going

@SamS we can't trigger based on Service Manager can we? So if an update is made by a Customer, we can't listen for that and send the data to Jira?

Has anyone please worked out the Jira to Service Manager data push? For example, having updates or status changes on the Jira Issue pushed back via API into the (originating) Service Manager RequestID? @Sam P or @Martyn Houghton or @Keith Stevenson or @Adith or @HHH? I see you have all been part of the Jira Cloud forum posts.

@Sam P did you get anywhere with this? I would quite like to push the RequestID to a Jira field also.

I don't think Problems have Customers, only Raised By. I suspect the Raised By could be altered with an Autotask Update Request Details node?

@Martyn Houghton did you +1 this?

+1 I can see a use for this. If HB were looking for a 'project' to connect this to, I think there is a whole case for customers to be able to do more on their own Requests as per my previous request for buttons that Customers can use themselves to Close, Escalate, Hold, Approve (and now Add Connections)