How do when, if, and then statements work for automation in next-gen service desks?

Automation can help free up time to help you focus on other important work. But first, you have to set up the “rule” for how it works - what it’ll do for you and when.

An automation rule is made up of three parts:

  1. When this happens… this trigger tells the automation what to look out for.

  2. Optional If these match… these conditions will make sure it’ll effect only certain issues, users, comments, links, statuses or resolutions.

  3. Then do this… this statement tells the automation what to actually do (what action to take).

Here’s what you can choose for each part.

When this happens

Automation rules require one When this happens… trigger to start an automated acton. Here are all the available When this happens… triggers:

Comment added

A comment is added to an issue.

Comment edited

A comment on an existing issue is edited.

Issue created

An issue is created in the project.

Issue resolution changed

The issue's resolution field is set or modified.

Status changed

An issue transitions through a stage in its workflow.

A linked issue is transitioned

An issue linked in the same Jira cloud site transitions through a stage in its workflow.

Participant added to issue

A request participant is added to the issue.

Organization added to issue

An organization is added to the issue, or someone shares an issue with an organization.

Approval required

The issue transitions to a workflow stage that requires approval.

SLA time remaining

The issue's SLA cycle reaches a certain time remaining.

If these match

Use the optional If these match… conditions to make sure that the rule affects only specific issues or activities on your service desk.

If these match… statements can vary depending on the When this happens… trigger.

Here are all the available If these match… conditions:

Issue matches

An issue matches a certain filter.

Comment visibility

A comment is visible either internally to agents or externally to customers.

User type

The user type is customer or agent.

Comment contains

A comment contains a key phrase.

Comment is primary action

A comment is the primary action and not the consequence of another action.

Resolution change

The issue's resolution status change either sets or clears the resolution field.

Status change visible to customer

The issue's workflow status change is visible to the customer.

Link type matches

A link type matches a certain type of link.

Linked issue matches

A linked issue matches a certain filter.

Then do this

A When this happens… starts the rule working. The Then do this… action is the what the rule actually does for you.

Here are all the available Then do this… actions:

Transition issue

Move an issue forward or backward through its workflow.

Add comment

Comment internally to agents or externally to customers on an issue.

Alert user

Prompt specific users with an @mention.

Edit request type

Change an issue's request type. Be sure your request types are the same issue type before applying this rule.

Edit issue

Change a field in the issue, such as assignee or priority. This affects fields that may not appear in each issue type.

Send email

Send a custom email notification.

Webhook

Send a POST request.

 

Are you on the right help page?

If you don’t have an image in the lower-left of your service desk sidebar which states you're in a next-gen project, check out these classic project articles instead.

Learn more about the difference between classic and next-gen projects.

Additional Help

Ask the Community