Triggers

Field value changed

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, or checkout another example on our blog

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.

Field value changed trigger

Incoming webhook

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:

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.

Incoming webhook url

Issue assigned

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

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

Issue assignee field

There is no configuration for the trigger.

Issue assigned 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 assigned send an email

Issue commented

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

This rule runs when a new comment is added.

Issue comment field

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

Issue commented trigger

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.

Issue commented - change status

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 commented with

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 created trigger

Issue deleted

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

This rule runs when an issue is deleted.

Issue deleted trigger

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.

Send email when issue deleted

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.

Issue linked trigger

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 linked trigger

  • 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 link deleted trigger

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 moved trigger

Issue property updated (server only)

  • 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 property updated

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.

Issue transitioned

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 whenever any details on an issue are updated (exceptions are issue linked, assignee and worklog). It is a broad trigger but you can refine it using conditions.

Issue updated

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.

Manual trigger

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. You can read more on the Multi-Triggers blog post.

Note that the available events may differ between Server and Cloud.

Multiple Issue Events

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.

Scheduled

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. This is a great way to help you monitor your limits.

Service limit breached

SLA threshold breached

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

TIP

This trigger is only available in Jira Service Desk projects.

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. You can read more about how we can help manage your SLA's here.

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.

SLA threshold breached

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

Sprint Started

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

Sprint Related Issues

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

Version Related

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"

Version Related Issues

Work logged

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

This rule runs when a work log is created, updated and/or deleted. Read more on how work logged is supported in Automation for Jira

work logged