Rather than simply maintaining systems and infrastructure, the core tenet of the IT Service Management (ITSM) philosophy is to deliver IT as a service to customers. A key part of this is to have logical workflows that drive queries, problems, and incidents onward so answers can be provided and solutions can be implemented, quickly and effectively.
If ITSM is a delivery system, workflows are the railway tracks that lay out the path going forward – and automation adds fuel to the fire to fast-track the navigation process, reducing the need for manual intervention and cutting out confusion and uncertainty.
In this guide, we’ll explain how to access, customize, and create Jira Service Management workflows and how to implement automation on the platform.
What are ITSM workflows in Jira Service Management?
JSM is based on Jira and includes all the functionality you need for the ITSM IT Infrastructure Library (ITIL) framework.
Request types in the JSM service catalog are associated with request types, which by default, run along the following ITIL workflows, covering:
- Service Request Management
- Incident Management
- Post-Incident Review
- Problem Management
- Change Management
- And the Jira Service Management default workflow
- Service Request Fulfilment with Approvals and basic (without approvals) workflow.
Note: If you create an ITSM project, you get by default 1 more workflow: Post-Incident Review workflow
Workflows track requests from creation to resolution, from a service request being raised to the request being fully addressed. JSM includes default workflows for each of these areas, but you can also customize them for the specific needs of your team and organization.
Customizing ITSM workflows in Jira Service Management
“Service Requests” refer to any kind of IT request made by a user, whether that’s to receive hardware, a password reset, or access to a service.
“Incidents” represent unforeseen events that may impact your service, and in the case of major incidents need to be promptly addressed.
“Post-Incident Reviews” comes after incidents are resolved and bring the team together to discuss what happened, why, how it was resolved, and how it can be prevented from happening in the future.
The “Problems” workflow allows requests to be raised so your team can investigate and address them, identifying root causes before things can escalate, potentially leading to incidents.
“Change Management” is geared to log changes to systems to make sure they’re documented and understood, using the “Change” request type. Change requests correspond to activities relating to reviews, planning, approvals, and implementations, and require users to note systems affected by the change, potential risks, and expected outcomes before the change undergoes review. If approved, the team can then implement the change, the process can be reviewed and the request can be closed.
To access the workflows, from your JSM project:
First, click on “Project settings” and then “Workflows”
Then, as needed, go to one of the following:
- “Service Request Fulfilment workflow for Jira Service Management”
- “Incident Management workflow for Jira Service Management”
- “Post-Incident Review workflow for Jira Service Management”
- “Problem Management workflow for Jira Service Management”
- “Change Management workflow for Jira Service Management”
- “Service Request Fulfilment with Approvals workflow for Jira Service Management”
- “Jira Service Management IT Support Workflow” (the default workflow)
From here, you can use the editor to change the workflow as you need, altering steps and transitions within the workflow
To edit a request type’s workflow:
Go from your service project settings, go to “Request types” and then select the relevant request type, and then click “Manage workflow” / “View and edit workflow” / “Edit Workflow” and click “Publish” when finished. This allows you to change the workflow the request type is associated with.
You can also copy over the request type’s workflow to other request types from the manage workflow page by clicking on “Replace with existing”.
“Statuses” are the stages that request passes through the workflow. “Transitions” describe how issues are moved from one status to another
“Rules” can update fields automatically as requests move through the workflow or can determine which individuals can transition requests
Default statuses include “Open”, “Reopened”, “Pending”, “Work in progress”, “Waiting for customer”, “Waiting for support”, “Escalated”, “Done”, and “Canceled”. You can search for issues with a given status across different request types, and you can also batch request types within status categories, such as “to-do” or “done”.
Statuses can be used for multiple request types, which means you can search for request types – such as “Open” – across your JSM workflows, irrespective of the type of request being made.
To add a status to a request-type workflow:
- Go to “Service project settings” in the sidebar and then “Request types”
- Then select the relevant request type and click “Manage workflow” then “View and edit workflow”, and finally choose “Edit workflow” from the top right corner.
- From the toolbar at the top of the screen click on “Add status” and then you can pick a status to add to the workflow.
- Then add the status or, to create a new status, give it a name – and click “Add”
The status will now populate the workflow and you can define the transitions that connect it to other statuses (with the default being that requests in any status can progress to the new status). See below for details on transitions. Once finished with the workflow, click “Publish” on the toolbar. Existing requests and queues will be updated to reflect the change.
Up to 100 new statuses can be added across your JSM project workflows, and up to 50 in a single workflow. That said, this kind of hyper-customization isn’t necessarily recommended – see our best practice tips.
If you want to delete a status from a request type workflow:
- Go to “Service project settings” then “Request types” then to the relevant request type and click “Manage workflow” then “View and edit workflow”, finally choose “Edit workflow” from the top right corner.
- Choose the relevant status in the workflow and on the status details panel click the “Delete status” button at the bottom, then click “Publish” when finished
- If there are requests in statuses that are being deleted, JSM will ask you to move them to valid statuses, and it will then update requests and queues based on your changes
Removing a status will also remove transitions connected to it. However, deleting the status will only remove it from the specific workflow being edited, not from all the workflows that use it.
To create a new transition in your request type workflow:
- Go to “Service project settings” from the project sidebar and then “Request types”
- Click on the relevant request type and then click “Manage workflow” then “View and edit workflow”, finally choose “Edit workflow” from the top right corner.
- Then click “Add Transition” from the toolbar
- With the “From status” dropdown, choose where your transition path will start
- And with the “To status” dropdown, choose where it will end
- Then name the transition and click “Add”
- Once you’re finished with the workflow, click “Publish”
The transition will be illustrated on the workflow as an arrow between two statuses. Up to 200 transitions can be added to a workflow. To see all the transitions connected to status, click on the status in the workflow to bring up its details panel which will indicate this.
If you want to edit a transition:
- Click on “Service project settings”, then “Request types”, then the relevant request type, and click “Manage workflow” then “View and edit workflow”, and finally choose “Edit workflow” from the top right corner.
- From the workflow diagram, click on the relevant transition to access its details panel
- From here, you can change the transition’s name and all of the rules associated with it
- When finished with the workflow, click “Publish”
To delete a transition:
- Go to the relevant transition’s details panel from the workflow and click “Delete transition” – this will also delete any rules associated with it
- Once done, click “Publish” on the workflow
Be careful when deleting transitions as cutting connections may mean that requests cannot be progressed as intended.
ITSM automation in Company-Managed Jira Service Management Projects
Automation works slightly differently in JSM company-managed projects compared to team-managed projects. Company-managed projects are made up of:
- Rules – which perform an action at a specific time; they are built from triggers, conditions, and actions
- Triggers – the step that activates the rule
- Conditions – determine the scope of the rule
- Actions – the step that makes a change
- Validators – checking input is valid before transitioning an issue
- Post-functions – carrying out tasks after the issue has been transitioned
To go to your automation settings in a JSM company-managed project, go to project settings and then automation. Conditions, validators, and post-functions can then be added to transitions.
Atlassian has a library of JSM automation rule templates, which can give you an idea of what’s possible.
To initiate the rule, you’ll need a trigger and can pick from:
- Issue assigned, Issue commented, Issue comment edited, Issue created, Issue deleted, Issue linked, Issue link deleted, Issue moved, Issue transitioned, and Issue updated
- Field value changed
- Forms submitted
- Incoming webhook
- Manual trigger from issue
- Multiple issue events
- Scheduled
- Work logged
- Object trigger – when a JSM Assets schema is created, updated, or deleted
- Service limit breached
- SLA threshold breached
- Approval required and Approval completed
Emoji reaction to Slack message (works with the Atlassian Assist app on the Slack agent channel)
You can then set conditions to determine whether the rule will run, or which action it will take. These include:
- Issue fields condition – determines if an issue field matches specified criteria, comparing it with a value or field
- Advanced compare condition – compares two values
- Affected services – determines if the affected service field on an issue meets specified criteria
- Forms attached – checks if forms are attached to the issue
- If/else block – when “if block” conditions are met, the rule will perform one action and failing that perform the action assigned to the “else block”
- Issue attachments – checks the issue comment and description fields for attachments
- AQL – determines if an asset object or issue asset field matches an AQL query
- JQL – determines if an issue matches a JQL query
- Related issues – checks if there are related issues on the trigger issue
- User – checks if a user is in a group
Now you can set the rule’s action/s – what does it actually do? Options include:
- Assign issue, Clone issue, Comment on issue, Create issue, Create issue with a request type, Delete attachments, Delete comment, Delete issue, Delete issue links, Edit Assets field attribute, Edit comment action, Edit issue, Link issues, Lookup issues, Manage watchers, Transition issue, and Create sub-tasks
- Add service project customer
- Approve/Decline request
- Attach forms, Copy forms
- Create branch in (product name)
- Create Confluence page
- Create incident
- Create lookup table
- Create variable
- Create version, Release version, and Unrelease version
- Edit object
- Edit request type
- Link vulnerability to issue
- Log action
- Log work
- Lookup objects
- Re-fetch issue data
- Send email and Send Microsoft Teams, Slack, or Twilio message
- Send web request
- Set entity property
Validators can then be included to confirm the input is valid before the issue is transitioned. These include:
- Date Compare Validator – compare two dates
- Date Window Validator – compare two dates by adding a time span to one
- Field Required Validator – confirm a field is filled
- Field has been modified Validator – confirm a field value is changed in the transition
- Field has single value Validator – confirm a field has a single value filled
- Parent Status Validator – confirms a parent issue is in a specified state
- Permission Validator – confirms the user has the required permission
- Previous State Validator – confirms the issue has transitioned through a specified state
- Regular Expression Check – check a field against a regular expression during the transition
Post-functions can also be added if needed – adding an additional process after the transition. You can:
- Assign to Current User, Lead Developer, or Reporter
- Clear Field Value, or Copy Value From Other Field
- Set issue security level based on user’s project role
- Trigger a Webhook
- Update Issue Field/Custom Field
Automation in Jira Service Management
Here are a few applications to help fast-track your workflows.
One use case in incident management with company-managed projects is to use rules to automatically prioritize requests.
1. Go to your project sidebar and click “Project settings” then “Automation”
2. Click “Create rule” and the system will start to build up the rule automatically
3. Then give the rule the following settings:
-Create trigger (When): Issue created
-If, or Else if: For the relevant urgency and impact values – if these are optional fields, include an “Else if” condition so requests don’t get missed
-Then: Transition issue – moving the request to its next stage
4. Once finished, click the “Save” button and finally publish the modified rule by clicking on “Publish changes”.
To add new fields and make fields mandatory:
- Go to “Project settings” then “Request types”
- Click on the relevant request type
- Below “Request form” tab you can see the added fields. On the right section below “Fields” you can search for other available fields and drag and drop the field to the Request form.
- To make the field required, open up the field and click on the “Required” button.
- When ready, click on “Save changes”
When dealing with service requests, it can be very useful to link related support requests, so one fix can potentially resolve multiple support tickets relating to the same issue. Equally notifying linked reporters when requests are escalated, in the process of being addressed, and resolved, can save a lot of time in terms of communicating progress.
JSM also has several change management automation rules set by default:
- Creating a change management request will attach the default change management form automatically
- Completing, failing, or canceling deployments will transition the request automatically
Where possible, it’s effective to automate the approval of routine and very low-risk changes, clearing queues faster while ensuring everything is logged in the system. What’s more, fully automating the logging and documentation required for change management is also very useful, saving your team from having to manually record and reproduce information.
Best Practice and Tips for Jira Service Management Workflows
When looking at JSM workflows and automation, it’s worth keeping several points in mind.
Limit customisation
JSM comes with a huge amount of room for customization. However, it also has serviceable defaults in place from the get-go. Excessive customization of your instance will reduce interoperability with other systems and increase the chances that things may go awry. Given this, it’s advisable not to unnecessarily customize your setup and to consider whether matching the system to your team’s requests will enable you to better deliver service management or whether it will build needless complexity into the system.
Maximise automation
On the other hand, there’s enormous value in building as much automation as you can into JSM. This will save your team manual work and move requests through workflows more quickly, ensuring problems are dealt with faster and with less effort on your side, while everyone is kept informed.
Create service requests from email
Automatically converting email queries into service requests cuts out an annoying manual step and ensures that issues are logged in the system so they’re in line to be prioritized and addressed. Your JSM instance includes a default email and you can also set up a second email for users by going to “Project settings” and then “Email requests”, where you can select your email service provider and link the address.
Build out your knowledge base
Customer self-service is the ultimate form of automation. Having a detailed, up-to-date knowledge base that lists frequently asked questions means users can resolve many issues without even needing to get in touch, saving your team time and energy. What’s more, having a proactive approach to documentation ensures that practices and processes are aligned and systematized across your organization.
Conclusion
Jira Service Management provides a powerful toolset for managing ITSM, with a set of effective and efficient default workflows and room for extensive customization, so you can build your requirements into the platform as you need.
Automation, meanwhile, means you can fast-track basic service requests and address problems and incidents as quickly as possible, ensuring you’re able to consistently deliver a high-quality service for your customers and stakeholders.
All of this builds agility into the system, so you can do more with less and adapt to new approaches and technologies – taking the digital transformation journey one step forward.
Recommended Reads:
- Mastering Atlassian Intelligence: AI Insights in the Ecosystem.
- Mastering Jira Governance: Prioritizing Global Happiness over Complexity
- ITSM Workflows and Automation in Jira Service Management: A How-to Guide
- Mastering Jira Service Management Automation: A Guide for Team-Managed Projects
- ESM vs. ITSM: Key Differences in Enterprise and IT Service Management
