This page describes each of the workflow rules you can add to your team-managed projects and gives an example of why you might want to use one. Learn how to add a rule to your team-managed project's workflow.
Assign a request to someone
This rule helps ensure that the right agents address the right requests at the right time. It takes the manual work out of triaging and assigning an agent after a stage in the workflow is complete.
Jira Service Management can change the request's assignee automatically when you change its status:
Use the For transition dropdown to tell Jira Service Management the transition that updates the request's assignee field.
Nominate the person who you want to assign the request to in the Assign to dropdown.
You can assign requests to:
The current user, or the person updating the request's status
No one, making the request unassigned
A specific person in your service project
Example
Certain members of your service team may be subject matter experts in particular areas of service, or have explicit responsibility in carrying out certain requests. For example, you may have a service agent who's responsible for providing access to software tools or messaging lists. And, you might have a senior service agent who’s responsible for assessing how to escalate difficult or high-impact requests.
You can set up your request workflows to automatically assign certain request types to the person who’s responsibility covers that type of request.
In the example above, you might:
Navigate to the request type settings for IT help and edit its workflow. Select the first transition in the workflow (the Create issue transition from Start to Waiting for support). Add the Assign a request to someone rule to automatically assign these requests to your access specialist. Now, when an IT help request is created, your IT help specialist will be assigned the ticket automatically, skipping the need to triage your requests manually. Repeat this for each type of request, assigning them to the correct subject matter expert on your service team, and you’ll never have to triage requests again.
Edit your workflow to change the assignee when requests are moved into the Escalated status. You can set a rule to automatically assign these requests to a senior service agent or manager and they’ll be notified of particularly difficult or high-impact requests. Service agents can continue to work on other requests in their queue, safely knowing that the trickier requests are in good hands.
Restrict to when a request is a specific value
This rule looks at the value of a request’s field before allowing someone to use a specific transition. This virtual check can help your service team better resolve issues by narrowing down the request’s available paths in your workflow based on the information present on the request. You can use it to enforce best practices for similar requests without having to create a new request type and workflow.
To review the value of a request’s field before allowing someone to use a specific transition:
Use the For transition dropdown to tell Jira Service Management the transition that checks for the field’s value.
Select the field whose value you want to check in the For this field dropdown.
Optionally, adjust the Review its value as dropdown to change how you want to evaluate the field (see below for details).
Use the Check if it dropdown to select how Jira Service Management should compare the field’s value (see below for details).
Add the value you want to compare against to the This value field.
Click Add.
Review its value as
This capability is included to support older configurations of Jira and advanced uses of this workflow rule. We don’t recommend changing this option from its default.
Jira Service Management allows you to evaluate the value entered in a field in a number of different ways. This can be useful when comparing numerals entered as text in a short text field to see if they are equal to an integer, for example.
Depending on the type of field you’re checking, you can evaluate its contents as:
a number - any positive or negative number, including decimal values, between -1 trillion and 1 trillion (100000000000000). Keep in mind:
The field will not accept a number expressed as a fraction.
The field only accepts one separator–the decimal. Other notation (for example, commas to denote places) will break the rule.
Jira rounds decimals to the nearest 10th place. For example, 5.555555 will be rounded to 5.6.
You may enter large numbers using scientific notation. For example, the number 5000 can be entered as 5e3.
a selection - including the available options configured in the field for dropdown and checkbox fields, or user IDs in people fields.
a time stamp - including a date and, for time stamp fields, a time. We provide a calendar and clock to accurately select the date and time, so you don’t need to know specific formatting.
text - evaluated as a string, including special and non-Latin characters.
Check if it
The selection you make here tells Jira Service Management how they should evaluate the contents of the field you’re checking. For example, you can check if the value of a number field is greater than or less than a desired value.
Depending on the type of field you’re checking, you can compare the field’s value with these operators:
contains - for evaluating fields as either a selection or text, this operator looks to see if the desired string or selection is present in the field
doesn’t contain - for evaluating fields as either a selection or text, this operator looks to see that the desired string or selection is absent from the field
doesn’t equal - this operator looks to see if the field being evaluated doesn’t exactly match a specific pattern
equals - this operator looks to see if the field being evaluated does exactly match a specific pattern. For text, the evaluation is case sensitive and considers exact formatting.
is after - for date and time stamp fields, this operator looks for time stamps that occur after the desired value chronologically
is before - for date and time stamp fields, this operator looks for time stamps that occur before the desired value chronologically
is or is after - for date and time stamp fields, this operator looks for time stamps that occur at exactly the same time or after the desired value chronologically
is or is before - for date and time stamp fields, this operator looks for time stamps that occur at exactly the same time or before the desired value chronologically
is greater than - for number fields, this operator looks for values that are larger than what’s specified in the rule
is greater than or equal to - for number fields, this operator looks for values that are either exactly equal to or larger than what’s specified in the rule
is less than - for number fields, this operator looks for values that are smaller than what’s specified in the rule
is less than or equal to - for number fields, this operator looks for values that are either exactly equal to or smaller than what’s specified in the rule
Example
If your service project collects bug reports from people using your organization’s software, you can enforce a best practice for verifying the bug before notifying your software team that they need to address the issue.
In this example, you can create a checkbox field on your bug report request type called Verified. Then you can set up the Check a request’s field to check if the Verified field has been checked by an agent before allowing the bug resolution process to begin.
Jira Service Management’s default bug report workflow looks like this:
To ensure that the bug report is verified before starting work on the issue:
In your external service project, edit the Report a bug request type. Learn more about external service projects.
Create a Checkbox field, named Verification.
Add two options to this field: Verified and Rejected.
Click Save changes.
Select Edit workflow. The workflow editor appears.
Select the Start work transition.
From the toolbar, select Rule.
Choose the Check a request’s field rule and click Select.
In the For this field dropdown, select your new Verification field.
Leave the Review its value as dropdown set to its default a selection.
In the Check if it dropdown, select the equals operator.
In the This value field, select the Verified option.
Now, your agents won’t see and can’t transition a bug report to the Work in progress status without selecting the Verified checkbox on their requests.
Repeat this process for the Set as done transition, checking that the Rejected option is ticked in your Verification field, and your workflow will enforce a best practice for checking bug in your products before acting on bug reports.
Restrict to when a request has been through a status
This rule helps ensure that requests go through one or more required stages in your team’s workflow. It lets you enforce automated checks in your workflow, and prevents requests from skipping steps in your process. Or, the rule can be set up to do the exact opposite – check that a request hasn’t been through a particular status.
To check if an issue has been in a status before allowing a specific transition:
Use the For transition dropdown to tell Jira Service Management the transition that check previous statuses.
Select the status you want to check for in the Check that the request has been through dropdown.
You can also select the following options:
Include the request’s current status
By default, this workflow rule only looks at prior statuses when evaluating whether to allow a transition. If you want to also evaluate the current status, select the Include the request’s current status checkbox. This can help prevent looping transitions, where a transition resets the status and it appears unchanged. It keep issues moving down your workflow.
Reverse this rule
You can change the behavior of this workflow rule to check that a request hasn’t been through a particular status before allowing the transition. This can enforce that purchase requests or feature requests that have been in a “rejected” status don’t make their way back into your queue.
Only consider the request’s most recent status
By default, this workflow rule checks the entire history of a request from its creation in the project. Selecting this option forces the rule to only evaluate the status set just prior to the request’s current status. In some cases, this may be the same as the current status. We recommend also selecting the Ignore status updates from looped transitions option to ensure the rule evaluates the most recent different status from the request’s current status.
Ignore status updates from looped transitions
Some projects use transitions to trigger automation rules or actions in connected apps. These transitions usually reset the request’s status to the current request status. If you’ve selected to Only consider the request’s most recent status, the most recent status may be the same as the current status. Selecting the Ignore status updates from looped transitions option forces the rule to evaluate the most recent different status from the request’s current status.
Example
Service teams that collaborate with software teams may need to wait for verification that a bug or other issue has been fixed from a quality assurance engineer before closing a customer request. For example, your service team may collect and link bug reports from your service project. Your service team then communicates with your development team to get these issues resolved. In this case, you can use your workflow statuses to ensure your team doesn’t close a ticket until its been reviewed by a quality assurance engineer.
For example, a customer service team may have these statuses on their bug report requests:
Open → Pending development → In review → Done
You can use a workflow status as a quality gate before allowing the customer request to be set to “Done” in your project. Add the Check that an issue has been through a status rule to the final transition in your workflow, and you can ensure that work has been reviewed properly by your quality assurance engineer before marking the task as complete:
Add a Check that an issue has been through a status rule to the “Any status” transition leading to your “Done” status.
In the Check that the issue has been through dropdown, select the “In review” status.
Select the Include the issue’s current status option.
Select the Only consider the issue’s most recent status option.
Select the Ignore status updates from looped transitions option.
Now, the transition to “Done” is only allowed if the most recent status was “In review”.
Learn more about using Jira Service Management to collect bug reports.
Remind people to update fields
This rule is only available in team-managed projects.
This rule makes sure agents capture relevant information when changing a request's status. When you create the rule on any transition, you can prompt agents to complete empty fields that are relevant to that stage in resolving the request. The rule removes a burden on your teams to remember to fill in specific fields until they matter. It keeps them focused on the important work of helping your customers.
Jira Service Management can prompt your team to update or review up to 40 fields on each transition:
Use the For transition dropdown to tell Jira Service Management when to prompt your team.
Choose the fields you want them to update or review.
You can prompt them to complete most text, number, label, date, or time fields you’ve added to your service project, including custom fields. Learn more about custom fields.
You can include a personalized message explaining what fields to update and why.
Example
Most service teams categorize how they resolve a request when they mark a ticket as "done". If you use a field to capture how agents resolve tickets, you can use this information in reports. This can bring you insights into how your service team interacts with their customers. You can see if agents are closing tickets because they've lost touch with customers. Or, you might see that one channel is more successful in completing requests than another.
For example, you might create a dropdown custom field called “Resolution” in your request types. This field might have options like “Fixed”, “Canceled”, “Abandoned”, and so on.
Then, you can set up your request type's workflow to capture how agents resolved a request when then move the ticket into a “Done” status. To do so, add a Remind people to update empty fields rule to your transition, and choose your “Resolution” field. Jira Service Management will prompt your team to add a resolution when they mark a ticket as done.
Restrict who can move a request
This rule enforces who can move requests using certain transitions.
You can restrict who can move a request to:
The request’s assignee.
The request’s reporter.
A user of your choice.
People in a specific role.
- People in a specific group.
- People with specific permissions.
It’s handy for service teams that must enforce compliant or industry-standard ways of working. The rule makes sure the right person reviews and moves requests along their workflow.
Jira Service Management can restrict any transition in a request type’s workflow:
Use the For transition dropdown to tell Jira Service Management what pathway you want to restrict.
Choose the individual people or project roles allowed to use the transition. You can choose up to 20 people or roles.
Example
Some service teams have a manager or team lead who triages and distributes incoming requests to the most appropriate agent. They might want to verify the requests are valid or link them to other known requests in their project before assigning someone to work on them.
In this case, you can use a rule to prevent requests from moving down the workflow before managers or team leads have properly triaged the request. To do so:
Create a “Triaging” status in your workflow.
Change the starting status to move requests into the “Triaging” status.
Create an outgoing transition to the rest of the request’s workflow called “Send to team”.
Add a Restrict who can move a request rule to this new transition to restrict it to the manager or team lead.
Jira Service Management prevents any other person in the project from moving newly-created requests forward.
Validate that people have a specific permission
This rule looks at what permissions someone has before they’re allowed to use a specific transition. This check helps your team ensure only the right people can move a request at the right time. Use this rule to secure your workflow based on people’s Jira permissions.
Example
A team with a basic workflow might have these statuses in their workflow:
Start → To do → In progress → Done
You can use this rule to validate people have a specific permission by:
Only allowing people with the Create issues permission to move a request from Start → To do. This ensures that only the right people can create work for your team.
Only allowing people with the Assign issues permission to move a request from To do → In progress. This ensures that whoever starts working on a request can assign it to someone.
Only allowing people with the Close issues permission to move a request from In progress → Done. This ensures that people aren’t able to resolve a request without being allowed to.
Copy the value of one field to another
Just like the Update a request field rule, this one also helps ensure your work is updated in the right places at the right time by reducing data entry errors. The key difference is that this rule updates a field based on another field.
You can either copy the value of a field from:
within the request itself, which copies a field from a request to another field on the same request.
the parent request, which copies from the request’s parent to itself. This option only works if the request is the child of another request e.g. copying a request from an epic (parent) to a story (child), or from a story (parent) to a subtask (child).
When we’ll skip this rule
The information you configure this rule with may not apply to all request types that share the workflow. So we’ll skip this rule when:
it’s on a request that doesn’t have both your selected fields (in Copy from this field and To this field).
it’s configured to copy from the parent request and the request doesn’t have a parent.
Don’t worry, this rule being skipped doesn’t mean you’ve done something wrong, or that there’ll be a bug. You’ll be able to go on with your work. It just means there won’t be any fields copied or updated.
How fields are copied
There are three ways a field is copied to another:
Append: The field’s value is added to the destination field’s value.
Prepend: The field’s value is added to the start of the destination field’s value.
Replace: The field’s value replaces the destination field’s value.
Here’s a list of compatible field types and how they’re copied:
Field type | Can be copied to | Is copied by |
|---|---|---|
Text | Text Summary Description | Append |
Date | Date | Replace |
Labels | Labels | Append |
Number | Number | Replace |
Checkboxes | Checkboxes | Replace |
Single select | Single select of the same type e.g. group picker → group picker. | Replace |
Multi select | Multi select of the same type. e.g. version picker → version picker. | Replace |
User picker (single user) | User picker (single user) | Replace |
User picker (multiple users) | Append | |
User picker (multiple users) | User picker (multiple users) | Replace |
Assignee | Assignee Reporter User picker (single user) User picker (multiple users) | Replace |
Attachments | Attachments | Append |
Update a request field
This rule helps ensure that requests capture the right information at the right time. You can reduce data entry errors and increase consistency. There are particularly useful for internal fields in your service project.
Jira Service Management can update certain fields for you automatically when you move issues between columns or change their status:
Use the For transition dropdown to tell Jira Service Management the status that updates a certain field.
Choose which field you want to update automatically.
You can update most text, number, label, date, or time fields you’ve added to your project, including custom fields. Learn more about custom fields.
A few nuances:
When you update a text field using a rule, Jira Service Management adds the desired text to existing text in the field. It won’t replace any existing text in the field.
When you update a time or date field, Jira Service Management replaces anything in the field with the date and/or timestamp of when the request changed statuses. You can’t specify a static time or date.
Unknown custom field type
When updating a custom field of a type unknown to the workflow editor, make sure you enter a value that matches the custom field's type. Otherwise, the rule might not work.
You can use these:
- %%CURRENT_USER%%, which will be replaced with the user who transitioned the request.
- %%CURRENT_DATETIME%%, which be replaced with the date and time of the transition.
- For Select List (cascading) fields, you can either use the value or the id of the option to be selected.
Custom date and time formats
If you’ve set up a custom date and time format and want to configure this rule to update a date and time field, you must enter your desired in the correct format. If this is the case, you’ll see a text field with instructions on how to fill it instead of a date picker field.
For example, you might see a text field that says to enter a date in the “dd/MMMM/yyyy h:mm a” format. One date you could enter would be “15/July/1968 9:30 PM”. To learn more about these formats, check out Java SimpleDateFormat.
To change your date and time formats, you can configure the look and feel of Jira. Learn more about configuring the look and feel of Jira.