Jira Automation - Automated Customer Request Creation

[Tyler Groves]

Hello, 

I am currently attempting to use Jira Automation to enable the automatic creation of Customer Request tickets (in JSM) for each of our clients based upon tickets that are created by our Service Management users internally. The tickets the internal users will creating will be in our Jira Software instance. I will outline to flow below - 

1. Service Management user creates a ticket in our Jira Software instance
2. Jira Automation rule triggers and based upon the attributes of this ticket, a Jira Service Management ticket is created.

This seems simple but there are complications - 

• In our Jira Service Management project, we have x number of clients each of these has their own "Project". Lets say we have 50 Projects that we need to create and manage Customer Requests for
• Each of these Projects has an "Organisation" which contains the contact details for our client users who need access to the Customer Requests
• By default, created tickets are not visible to users in a given "Organisation"
• In Jira Automation rules, there is not a simple way to add all users for a given "Organisation" 

Currently I have setup automation for the following -

1. When ticket of type "Change Request" is created in Jira Software
2. Rule in Jira Software triggers and sends a web request to Jira Service Management, containing the data for the created ticket
3. An incoming webhook receiver in Jira Service Managment is listening for these events and when once is received, a web request is sent to the Jira Service Managment Rest API to create a new Customer request, based on the attributed passed into the webhook

At the minute some of the parameters passed to the rest api are hard coded (serviceDeskId, requestTypeId) and others are dynamic. The serviceDeskId is the hardest one to solve. serviceDeskId == Project. But the ID is just a integer, which is difficult map to the actual Client ID. 

The reason for using the RestAPI is because using the action type "Create work item with a request type" forces you to hard code the Project ID but this needs to be applicable to all project in JSM. The other option is to create a series of IF/ELSE statements in the automation rule, but this is cumbersome and will not scale as we add new clients to JSM.

Apologies for the long post, but I thought it best to include as much context as possible. My ask here is has anyone else solves this issue before using Jira Automation? And if so, how did you solve these problems?  

[Marc - Devoteam]

Hi @Tyler Groves 

Welcome to the community.

1st question why this approach, have all you internal user be customer on each project and let them use the portal of a project to raise an issue.

2nd why the "50" different projects? Use a sinlge project and have 50 organisations within the project.

Based on the user raising the issue you could automate the setting of the organisation based on the email domain of the user.

It's also not a best practice to have internal users raise issues for customers, if you will do this, let your internal users use the portal as well.

This to prevents mistakes and lack of information on requests.

Automation with web hooks will create single point of failures, based on every config change you make you need to go over the rules, or if changes are made on the API by Atlassian

Other point if you make use of forms on request, these can't be used on creating issue from internally.

[Tyler Groves]

Hi @Marc - Devoteam thank you for the swift response! 

To answer your first question, I'll add some more context to why/what we are trying to do. The tickets we will be creating on behalf of our customers will be to get them to agree to Maintenance Windows for environments that we manage on their behalf. Each ticket will have this format - 

Environment

Type of Maintenance

Window start 

Window end

Then using a custom workflow for the "Maintenance Window" request type (custom request type) the client can "Approve" or "Decline" the window. Currently we are organising this process through email which creates a large admin overhead. Since our customers are already onboarded with JSM and we store their contact details there. This provides the best UX/UI for our existing customers.

For question 2 - JSM was setup this way with 1 Project per client due to scale and to provide separation between Enterprise clients. Each of these Project has 100s of customer requests and 10s of users in the Organisation.

Agree with your point about webhooks and having them flake is definitely a concern, if this can be configured without the need for webhooks that would be ideal. The one webhook I think will be required is the webhook that connects Jira Software -> Jira Service Management. They live under the same Jira Cloud account, but have separate domain names so I think even at the "Global Automation" level, they are still separate entities? 

[Marc - Devoteam]

Hi @Tyler Groves 

As response why don't inform all your customer that they can raise issues via a portal, provide them with the link to the correct portal.

Your setup is creating duplicate issues as well.(creating issues in a JSW project and then cloning them to a JSM project based on attributes).

But as you have this setup, you could setup a create lookup table in the automation, the only limitation there is that it can only contain 20 entries.

So you might need multiple lookup tables.

https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Create-lookup-table 

With a lookup table you can specify the name of the project and the project key based on a project attribute (example) in the issue created in the change in the JSW project find the right row and use this lookup table variable in the webhook

[Tyler Groves]

Thanks @Marc - Devoteam

The duplication in this case is desirable, because we have internal tickets to track maintenance for client environments but these should not be client visible. We then create the client ticket to act as an interface to the client where we can seek their approval for the window.

Thank you for the lookup tables suggestion, I will experiment with these and see if they could facilitate this. 

I have had another idea which is to add a new "Work item security scheme" that I think will enable client users in a given Org to view all customer requests of a certain request type to view them by default. If this is possible it will remove the most complicated part which is adding "Request responders" or adding their Organisation to each request using some automation rule.

I'm going to experiment with this approach now

[Bill Sheboy]

Hi @Marc - Devoteam 

FYI -- Create Lookup Table has supported up to 200 rows since the last round of updates in July 2023.  It is the pagination (when creating rows) that is limited to 20 at a time...making larger lookups more difficult to use in the editor.

https://community.atlassian.com/forums/Automation-articles/Update-Create-lookup-table-action-improvements/ba-p/2427798

Kind regards,
Bill

[Marc - Devoteam]

Hi @Bill Sheboy 

Thanks for the clarification.