Field value changed

• Available in Server Lite: No
• Related smart values: {{fieldChange}}

This rule runs whenever a field changes. All system and custom fields are supported and this little gem makes it incredibly easy to react to changes during issue creation, edits, transitions etc. You can follow up this trigger with a condition to check the value of the fields before proceeding, or you can just go ahead with your action. In the example below we are sending an SMS when an issue's priority changes to greater than high.

First, you select the field(s) to monitor for change. You can, instead of selecting individual fields, use a regex to match the field names. If required, you can narrow down which issue operations will trigger this rule (create, edit, transition or assign), or leave it blank to listen to all operations.

Incoming webhook

• Available in Server Lite: No
• Related smart values: {{webhookData}}

A webhook is a way for a third party to trigger an Automation Rule. The webhook can specify specific issues to act on or even provide Automation for Jira with real-time data that you can use to update your issues. We have some great examples on how we have used webhooks in our blog:

• Triage customer feedback and add a slack notification
• How to use Automation for Jira to improve Continuous Delivery
• Integrate Jira and GitHub.

When you configure the webhook trigger, it will give you a unique URL which you either add to the third party application's outgoing webhook configuration or make a HTTP Post request from your custom scripts. The trigger also gives specific details on how to provide issue keys and other data if required.

You can use the {{webhookData}} smart value to reference the custom data provided by the webhook in the rest of your Rule.

Issue assigned

• Available in Server Lite: Yes
• Related smart values: {{assignee}}

This rule runs when there's a change to the Assignee field.

There is no configuration for the trigger.

There are lots of things you can do with this. For example, when an issue is assigned to a specific user, automatically change the issue's status to In Progress and then email the reporter to let them know it's being investigated. The email can even come from the assignee.

Issue commented

• Available in Server Lite: Yes
• Related smart values: {{comment}}

This rule runs when a new comment is added.

There's no configuration for the trigger, it runs when a new comment is added (editing a comment doesn't trigger the rule)

There are many actions you can trigger. For example, you can set the rule so that if a new comment is added to an issue, it will change the status to In Progress.

Or you could trigger the rule if the comment contains specific words (JQL search condition required). For example, if the comment contains the word 'Done', then this rule will change the issue's status to 'Done'.

Issue created

• Available in Server Lite: Yes
• Related smart values: {{issue}}

This rule runs when an issue is created. When used with any of the actions, you can automatically customize the new issue, populate fields, assign it to users, add sub-tasks and tons more.

Issue deleted

• Available in Server Lite: Yes
• Related smart values: {{issue}}

This rule runs when an issue is deleted.

You could use this, for example, to send an email notification that an issue has been deleted. You can use a condition to refine exactly what issue you are looking out for.

Issue linked

• Available in Server Lite: No
• Available for version: Jira 7.5+
• Related smart values: {{destinationIssue}}, {{linkType}}

This rule runs when an issue is linked to another issue. Linking issues is a great way to keep things organized. You can keep track of duplicates, related issues, issue blockers and more.

You can configure the trigger based upon any link type. For example, you could automatically close off an issue that is Linked as a “Duplicate”.

Issue link deleted

• Available in Server Lite: No
• Available for version: Jira 7.5+
• Related smart values: {{destinationIssue}}, {{linkType}}

This rule runs when an issue is unlinked from another issue (e.g. the issue link is deleted).

You can configure the trigger to only execute for specified link types, or for all issue links.

Issue moved

• Available in Server Lite: No
• Related smart values: {{issue}}

This trigger reacts when an issue is moved from one project to another. Using conditions and actions, you can ensure that all settings (values, fields, etc) are copied across to the new project.

Issue property updated

• Available in Server Lite: Yes
• Related smart values: {{issueProperty}}

Use this trigger to react to changes made to an issue's properties in Jira Server. You can listen to changes for specific properties or all properties.

Issue transitioned

• Available in Server Lite: Yes

This trigger reacts when an issue transitions from one status to another. You can configure it so it listens for a specific transition (to a status of your choice) or simply any transition in your workflow.

Considerations:

• If you run into any trouble with the 'Issue Transitioned' trigger, take a look at our knowledge base article which explains the most common errors.

Issue updated

• Available in Server Lite: Yes
• Related smart values: {{issue}}

This trigger will kick off a rule when:

• Any details on an issue are updated (exceptions are issue linked, assignee, and workflow)
• Jira 8.17 and earlier: Comment on an issue is deleted (but not added or updated)

In Jira 8.18 and later, the rule won't be triggered when a comment is deleted. This is due to the change in events in Jira that affected this rule.

It is a broad trigger but you can refine it using conditions.

Manual

• Available in Server Lite: No
• Related smart values: {{issue}}

This trigger adds the ability to manually kick-off a rule from your Jira 'view issue' page. You can refine which groups can manually trigger a rule.

This is great for automating common tasks or testing and debugging a rule.

For how to run these in Cloud and Server see our detailed Manual trigger instructions

Multiple issue events

• Available in Server Lite: Yes
• Related smart values: {{issue}}

With this trigger you can select one or more issue events that will trigger this rule to run. It is easier (and more efficient) than creating several rules. For example, send a Slack message when an issue is updated, transitioned or assigned. 

Scheduled

• Available in Server Lite: Yes
• Related smart values: {{issue}}

This executes a rule on a specified schedule. You can run the rule at a fixed rate or use a Cron expression for more complex schedules. You can choose to either run a JQL query or simply run the rule if you're trying to create issues on a schedule.

One example use case might be to find stale issues. Take a look at this rule of the week that shows how.

Service limit breached

• Available in Server Lite: Yes
• Related smart values: {{breachedSummary}}, {{breachedRules}}

You can use this trigger to setup a rule to be notified when you are about to breach the processing time limits defined in your Jira instance. 

SLA threshold breached

• Available in Server Lite: No
• Available for version: Jira 7.5+ and Service Desk 3.3+
• Related smart values: {{issue}}
  
  

The SLA trigger allows you to respond to Jira Service Desk SLAs that have breached, or are about to breach - a threshold determined by you. It allows you to give timely feedback to your customers, alert agents and automatically prioritize requests accordingly. You will need SLAs already set up in Jira. From there, you choose the SLA you want to monitor then set the time before or after it has passed. 

In the example below we use this trigger to keep the team notified via slack when an issue is due to breach SLA in an hour.

Sprint created, started or completed

• Available in Server Lite: No
• Related smart values: {{sprint}}

These triggers run when a sprint is created, started or completed on the selected scrum board. It will execute for every sprint on that board or you can narrow this down using a Regular Expression

You can also loop through all issues available in a sprint by using the related issue's branch "Issues in the sprint".

Version created, updated, released

• Available in Server Lite: No
• Related smart values: {{version}}

These triggers run when a version is created, updated or released. You can restrict which versions will trigger this rule using a Regular Expression

Note: The version updated trigger listens for versions being created and released as well as being amended (it's recommended to only use it if you need to listen for all events around a version).

With the version released trigger, you can loop through all issues fixed in this version by using the related issue's branch "Issue fixed in version"

Work logged

• Available in Server Lite: No
• Related smart values: {{worklog}}

This rule runs when a work log is created, updated and/or deleted.