Every rule starts with a trigger. They kick off the execution of your rules. Triggers will listen for events in Jira, such as when an issue is created or when a field value is changed.

Triggers can be set to run on a schedule, and can be customized before being applied to a rule. You can use the following triggers:

General triggers

These triggers can be used across all Jira products.

Field value changed

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

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. 

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 archived

Related smart values: {{issue}}

This rule runs when an issue is archived. This rule won’t run if a project is already archived.

You can use this rule to send an email notification when an issue is archived. You can also use a condition to specify the exact issue you’re looking out for.

Issue assigned

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

Related smart values: {{comment}}

This rule runs when a new comment is added. This will not run if the project is archived.

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

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

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

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 duplicate.

Issue link deleted

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

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

Related smart values: {{issueProperty}}

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

Issue restored

Related smart values: {{issue}}

This rule runs when an issue is restored. This rule won’t run if a project is already restored.

You can use this rule to send an email notification when an issue is restored. You can also use a condition to specify the exact issue you’re looking out for.

Issue transitioned

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.

Issue updated

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

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, see our detailed Manual trigger instructions.

Multiple issue events

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

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.

Jira Service Management triggers

The following triggers are only available for Jira Service Management.

Service limit breached

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

Related smart values: {{issue}}

The SLA trigger allows you to respond to Jira Service Management 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.

Jira Software triggers

The following triggers are only available for Jira Software.

Sprint created, started or completed

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

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

Related smart values: {{worklog}}

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