[Updates back from Jira Cloud into Service Manager]

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

[Updates back from Jira Cloud into Service Manager]

@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:

1. 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)
2. 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.

[Outcomes of changes - what do you do?]

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

[Outcomes of changes - what do you do?]

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:

[Portal UI issue: some 'required' fields of an ICF have the red bar greyed-out unless clicked]

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:

[Updates back from Jira Cloud into Service Manager]

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

[Updates back from Jira Cloud into Service Manager]

@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?

[Updates back from Jira Cloud into Service Manager]

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.

[iBridge issue passing Request ID to Jira]

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

[Analyst has changed their desktop logon and has some Problems raised under old logon - can I change customer on Problem records?]

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?

[Enhancement: Customers have asked for a portal button to close their own tickets (and Service Desk want it too)]

@Martyn Houghton did you +1 this?

[Let customers retrospectively connect other customers in the portal]

+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)

 

[Additional Notice types]

Indeed, we have quite an array of custom buttons and I do have one for change calendar. Maybe that was a bad example. I did make another post previously about the change calendar being a permanent link on all CRs.

[Feedback on Service Manager release notes]

Today's release notes: 

 

1. It would be more helpful if you listed the KE numbers for fixes not the PM numbers. AFAIK, it's the KE not the PM numbers that are quoted to us when you resolve premier support incidents into the backlog so we can search our emails for them. Do you ever quote PM numbers to customers?
2. This release contained the Request Insights but it was not mentioned on the release notes; so quite a nig omission...

[Additional Notice types]

+1 for another few types (colours) except I would add something to this.

Like Gareth said, we use notices for guidance and sometimes there are permanent pieces of guidance we want to persist for most if not all of the lifecycle of a Request. Examples: link to the Change Calendar for changes, (in the absence of a button for this), links to procedures or documents for a given ticket like Starters/Leavers. It would be useful to be able to be able to place some key bits of useful information like this in the Information Box

[Others (local authorities?) who access MOD.GOV and lose connection when Cloudflare alter the IP address]

At the HUG23 some other HB customers were experiencing the same issue as us: Cloudflare alter the public IP address without notice for their service so we lose connection until we update our network settings to match.

We have a solution in place for this involving a script that runs on a server to detect the IP address change and then spits an email out into Hornbill inbound rules which assigns to the infra team to run a standard change to update it.

Willing to share the script privately if you PM me as this is slightly off topic.

[Where please? "New button to the right hand summary section ... for a one-click option to assign the request to the session user"]

@Sam P these are all set in the Service Manager Application Settings. use this as a filter and you will see them all. Take care to click the "include advanced settings" because, for some reason, Hb have made half of them standard and half of them advanced...

ui.app.com.hornbill.servicemanager.operation

The "popup" one determines what options can be made available there and there is:

The one for general updates is this I think: guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.update

[Minor documentation update required]

Typo here is misleading:

Requests Entity - logRequest (hornbill.com)

...should read "h_sys_contact" (i.e. no 's')

[How do I "blank-out" (null) a custom date field? Or even set 'empty' if not null]

I have a workflow that feeds a report that goes into Power BI. I want the report to use conditional formatting to place a green icon against a RequestID when there is a 'next' problem review scheduled and a red icon when there is not one scheduled.

To achieve this I had planned to detect if custom 21 (date/time) is blank or not. The Workflow would place a date/time in custom 21 when one was planned (through Human Task) but then nullify that value (through expiry) once the date has passed.

My testing to run the node Service Manager > Enitity > Requests > Update Request > Custom Fields and then set the field to Manual but leave no value did not achieve the goal:

Is there a way to nullify (or even 'empty') a custom date/time field please?

PS my workaround would be to pick a date "long long ago in a galaxy far far away", 1978-01-29 00:00:01, for example, and have that as my null equivalent value for Power BI purposes; but it's a kludge.

[Enhancement: Increase character length in Description for Scheduled Requests (currently 300?)]

I want to use scheduled requests to point to SharePoint documents by pasting the link in the Description. That way, every month, the analyst is asked to follow the linked procedure stored elsewhere (which may have been updated).

But there is a short character limit on the Description that is not even long enough to hold a SharePoint document Link.

There is no mention of a character limit in the document; Scheduled Requests (hornbill.com). I think it is set at 299 or 300 characters because that's where my entry gets truncated:

One single link to a OneNote document is 342 characters and that's without any other text to explain it:

Can we please have this field extended to allow the same number of characters as any other Description field or at least something we would not hit in normal use like 5000.

Thank you.

[New issue: Requests are not (always) dynamically refreshing in the browser after completing an Activity]

Today we're getting that new Activities are not popping-up until we refresh even though the timeline has been updated that the task is added; if this is a widespread issue, it will be hitting hornbill performance as everyone refreshes whole pages.

[H_custom_26 field storing different values to Extended Information.H_custom_26]

I am using custom 26 to store a binary number outcome from some workflow; values such as 11001, 01101 etc.

I realised after testing that the number 01101 is not an integer when custom 26 was stored as 1101...

HOWEVER, I have an email that sends me the contents of each custom field and for fields a-t and 21-30 it shows both the values from the Request and the Extended Information 'versions' of that field and they are DIFFERENT. I have done because I have seen variances in the past and now there's another.

What I mean is that this expression in the email: {{.H_custom_26|empty}} --- {{Extended Information.H_custom_26|empty}} returns two different values: 1101 and 01101 respectively.

In short, the Extended Information.H_custom_26 is storing the full sequence of digits added to the field which includes the preceding zero (01101) but H_custom_26 is truncating (to 1101).

My question is can I rely on the extended information storing the digits (not as an integer) and thus refer to that in my workflow; or do I need to alter my number storage so we never have a preceding zero?

Thanks!

[Celebrating 100,000 Requests - how did you mark a milestone?]

@Sam P great idea and just in time. We're going with that and the date falls somewhere over christmas / new year which adds to the interest. we're at 98,843 this morning and run-rate of 200 per day... thanks and happy christmas. Comm:

[Celebrating 100,000 Requests - how did you mark a milestone?]

@Sam P great idea and just in time. We're going with that and the date falls somewhere over christmas / new year which adds to the interest. we're at 98,843 this morning and run-rate of 200 per day... thanks and happy christmas

[Error while creating a MS Teams chat from a ticket]

HB have confirmed there were issues with the iBridge tokens to Teams and I gather they fixed today so renew your token and should pick-up.