Berto2002

Why are you getting emails in from archived users? Can you add a node in your workflows before they get assigned to Service Desk to "Get User" details and then have a decision/expression based on the Account status to cancel/close any tickets raised for emails where the user is archived (and perhaps send a nice email saying please do not email us again or what to do to activate their account)?

I'm starting to see a new font for my UI, is that expected?

We are talking about that; except we seem to have different experiences... unless something has changed since we last tried it...

We have worked-around the custom_33 issue by using another custom field, thank you. though.

It's quite a big question but involves this at the high level: Ensure you have "start response", "start timer" and "mark response" nodes in your workflows; and that they all go through resolution and closure to end Ensure you have at least one global Service Level configured and linked to the Service portfolio configuration for each service Then either get into the Reporting engine and work on a report that brings back the Breach and Response Time and Resolve Time which is available when you select Report Using An Entity and select Requests OR you can look at the Widgets and Dashboards to give you data online See what you can find in the documentation along these lines. I am not sure about averaging; I don't think that is possible in the Reporting Engine. It may be possible in Dashboards. I think you would need to use a data aggregator like Power BI to do that.

I recognise this potential for issues and for users this would be an issue. From my perspective, the benefit of the choice would be to ADMINS like Adrian and myself where we can make an educated choice.

And we got the Jira to Hornbill working too using the above! Now we have a basic configuration, we can try some new things. Thanks so much @Gareth Cantrell. I hope others find this resources useful in future.

@Victor do you know who to direct this to please? Seems we cannot remove the proxy reference.

What's use case here? What are you trying to achieve?

+1 for two reasons when people clone a change request (like the last time they upgraded a system 6 months ago), it picks-up an old change workflow from before our last release and it scuppers the CR so I have to cancel it when we find issues in a production workflow that we can fix quite quickly and republish and want to copy the original request so we don't lose the questions data entry or Request field values, we have to re-log from scratch (as per Adrian's case) I would always choose to "Proceed with Active Workflow" (the latest version of the workflow previously used) or "Proceed with Selected Workflow" than "Proceed with Original Workflow"

@Gareth Cantrell. We have managed to alter a parameter in the final branch statement and can get the h_last_update_activity_id to post on the JIRA timeline so we are connected. What we cannot do is get the content of the last update there. We were looking through the Send web requests automation steps in JIRA and we can see this one gets the h_pk_reference from HB and assigns to "requestId" in JIRA { "@service": "apps/com.hornbill.servicemanager/Requests", "@method": "getRequestRecord", "params": { "requestId": "{{webhookData.onEntityEvent.record.h_pk_reference}}", "returnRelatedData":false, "returnActivityStreamAccessToken": true } } We can then see this gets the h_last_update_activity_id and assigns to "activityID" in JIRA { "@service": "activity", "@method": "activityStreamQueryItem", "params": { "activityID": "{{webhookData.onEntityEvent.record.h_last_update_activity_id}}", "accessToken":"{{webResponse.body.params.accessToken}}" } } What we cannot see is how JIRA can get told of the cell contents for "h_content" from "h_buz_activities" table which is where the updates are stored (The last updates text is not stored on the h_itsm_requests table). We feel there should be perhaps be another web request or part of an existing one that uses the activityId to then pull back data from h_buz_activities/h_content for the given activityId?

Thank you, @Gareth Cantrell, that definitely enabled the hook to trigger and we get an error message in JIRA. That query is: "Hornbill_RequestID"="{{webhookData.onEntityEvent.record.h_pk_reference}}" And that's what we have called the field that contains the RequestID:

Ah, that would be interesting to try....

We've tried the set-up as @Gareth Cantrell described and it's not working, sadly. We're going to run through thing again in another session next week. A few observations include. The only issue that through an error was Custom 33 is not recognised in the webhook spec so we altered to custom d; but it still didn't work. @SamS is there a reason why custom 31 + are not included in webhooks? Our webhook:

@samwoo thanks for the session ID information. I have included it in our form for the profile updates also. {{user.phone}} also works. I found this list and all your suggestions are on it so I thought to try some others... / session / getSessionInfo (hornbill.com) '''Your Cost Centre''' {{user.Attribute2}} *'''Your Home Organisation''' {{user.homeOrganization}} But they didn't work.

I think the sync only sync status etc not other bespoke previously-added information

Correct but then there are no "triggers" in the whole system so this is expected. It would be a good enhancement for the system to have generic "wait for X" that can happen at any time in a workflow and trigger this kind of update or autotask.

I have this set in the workflow at key points: Schedule is added to the card as soon as the schedule is added to the CR by the implementer in the CR build (after a wait for schedule node) Schedule on the card is again updated after the change manager's quality review (even if not changed); in case the CM moves it Then schedule action is locked down so only Change Manager can alter it After authorisation, we have a task that sits there waiting for the Implementer to "start implementation" and in that task they also have a button to "re-schedule" which unlocks the schedule, allows an edit and then sends to the change manager to review. After that review, the card again updates if authorised.

Is this going to be a system-wide setting we can alter in future or per user?

Hi Josh. For us, the only case I have is to update start and end dates/times. I can imagine a case for adding new attendees.

We want to introduce automated addition of changes to the Office365 calendars of Change Coordinators and Implementers. We have tested it and it looks good. There is a flaw in the plan in that the meeting arrives as "Busy". This is bad when the event is the whole Change Window (start to end) because it blocks-out people's calendars (often not the whole period is time they cannot do other work or have meetings). I request an enhancement to add a new field into the Create Event node to set "Show As" according to the Microsoft options: I also suggest to add the Reminder options. This could be a list of the available MS options or a basic option of "None" and "Default" where "Default" follows the client's default for new meetings but "None" forces that outcome. While we're at it, can we please have "Location" relegated to optional? There's no need to force that. Oh, and can we have the Start field above the End field and them be together? At the moment, the End and Start and separated by GroupID and location and the wrong way around. And maybe but the User ID, Calendar ID and Group ID all together?

We want to introduce automated addition of changes to the Office365 calendars of Change Coordinators and Implementers. We have tested it and it looks good. But there's a flaw in the plan because we cannot edit or delete events after creating; so if the schedule changes we end up having to create a second new event and leave the removal of the old one to the individual. I request the ability to at least Edit existing events and hopefully also delete. The Create node gives us the EventID on creation so in that sense we can reliably direct the edit or deletion to the right Event.

It works using these parms in case anyone else needs to know and after giving the servicedesk userID mailbox permissions:

Will test