We are using Jira Service Management for our internal IT support since May 2021. We started with the companies headquarters in Germany and onboarded other locations one by one. Now, in autumn 2022 we've migrated all 38 location so the global IT support is using the same platform with Jira Service Management and Insight. Just to provide some KPIs: We receive 3000+ requests per month and the issue count in this projects gets closer to 100K.
In Insight, we store our lists of IT services and local responsivities. Some services are using a regional 1st level support, some not and tickets need to be forwarded to the global 1st level support team at German headquarters. We are talking about 10 roles in different processes like incident and request mgmt, provisioning, IT order mgmt, account creation etc. as different attributes to a complex Insight object type.
We also import the complete user master data coming from HR with the employees location. So, when a user raises a request for a IT service (e.g. Mail) we simply match his location and Insight tells us who is now in charge. We bring this information to the issue in a custom field from type Insight Object with a Filter assign scope configuration. Everything works really fine - except from these two topics:
No Notification to Teams
So far, we were not able to implement proper notifications to each support team. We've worked with complex JQL filter and subscriptions without a big success. Currently, we bring the support responsibilities into 10 additional custom fields from type group picker by using the Insight REST API so we could use the standard notification scheme with standard and custom events to get this done properly!
Here comes the tricky part! We are also using the Insight information to implement dynamic queues in JSM. Their configuration contains an IQLfunction with several inbound and outbound references in order to check who is in charge according to IT service, statuses and the personal support responsibilities of the current user. The simple aim is: Show me only those requests where I am responsible for.
The performance check of the JQL function is a mess! The automatic queue reload doesn't work any more so an agents always reloads the browser in order to change a queue or open an issue. We're trying to use the group picker thing (see above) in order to reduce the complexity of the IQL function or get completely rid of it. So far, we haven't accomplish this in any detail.
My question to you - and I hope there are still some readers left until this point ;) How do other big companies conquer this dynamic and automated routing of requests within one centralized IT support project based on Insight?
For notifications you can also use Jira Automation with html formatting to send customized emails to enhance the communications:
For insight, what we do when they select a service (Insight Customfield) from the portal, we copy the value of the owner group email address/business owner/ or any other attribute from the object to an insight customfield. That way when the issue is created, it automatically copies the values. In server, you can accomplish this with PowerScripts/JWME/Scriptruner plugins.
For example, the user selects "Application A", then with the script you go to Application A's object and get the support team Jira Group. We copy this value into a User group customfield called Support Team. Then the Queue is set with a JQL that selects the Support Team accordingly.
I hope this helps.
Thanks for the quick reply. From my point of view, it looks like you do it nearly the same way we do. In fact, we are using a project automation rule in order to send a web request to the Insight REST API and process the webhook response accordingly. Handling JSON files is new for us ... but it works quite well!
Then the Queue is set with a JQL that selects the Support Team accordingly.
Can you pleas be more specific? How many queues do you have? And what query do you use?
Attached you will find a screenshot of our current JSM queues.
...eturns true if any content is returned for the webResponse.body.data.first s...