Automation basics
Understand the general concepts and best practices of automation in Atlassian cloud products.
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.
See how to use all of these triggers in our Jira automation template library.
These triggers can be used across all Jira Cloud products.
Related smart values: {{fieldChange}}
The rule will run when a field value is changed. All system and custom fields are supported by this trigger.
You can use this trigger together with conditions to check the value of fields before performing actions. For example, send an SMS when an issue’s priority changes to greater than high.
When configuring this rule, you can select the fields to monitor for change, or use a regex to match the field names. You can narrow down the fields to monitor by specifying a change type: Value added, value deleted or any changes to the field value. You can also narrow down the issue operations that will trigger this rule – create, edit, transition or assign – or leave it blank to listen to all operations.
The rule will run when forms attached to an issue are submitted. When configuring the trigger, you can select any number of forms, which will change how the trigger will act:
If no forms are selected: the rule will run when any form is submitted.
If one form is selected: the rule will run when that form is submitted.
If multiple forms are selected: the rule will only run when all of the selected forms on an issue are submitted.
Related smart values: {{webhookData}}
The rule will run when a HTTP POST is sent to a specified webhook URL.
A webhook is a way for a third-party to trigger an automation rule. The webhook can specify issues to act on, or even provide real-time data you can use to update an issue.
When configuring this trigger, you’ll receive a unique URL that you can either add to the third-party application’s outgoing webhook configuration, or make a HTTP POST request from your custom scripts. The trigger also provides details on how to provide issue keys and other data.
You can use the {{webhookData}} smart value to reference the custom XML data provided by the webhook in your rule.
Related smart values: {{assignee}}
The rule will run when the Assignee of an issue is changed. For example, when an issue is assigned to a specific user, change the issue’s status to In progress and send an email to the reporter to let them know it’s being investigated.
Related smart values: {{comment}}
The rule will run when a new comment is added. For example, change the status to In progress when a new comment is added on an issue.
Choosing a comment type allows you to distinguish if a comment was added stand-alone, or as part of a transition. For example, you may want to set an automation rule where a comment added to a closed issue re-opens, or a comment added transitions the status of the issue. The available comment types are:
All Comments (default): All comments that are added to an issue.
Comment is the main action: New comment is added as a message in the comments section.
Comment added during status transition: Comment is added when you change the status of an issue.
Comment added while editing issue fields: Comment added while editing one or more issue fields.
Editing a comment will not trigger this rule.
Related smart values: {{comment}}
This rule will run when a comment is edited. Can be used with the Edit comment action.
Related smart values: {{issue}}
The rule will run when an issue is created.
You can use this trigger with actions to customize the new issue, including populating fields, assigning to users, and adding sub-tasks.
Related smart values: {{issue}}
The rule will run when an issue is deleted. For example, send an email notification that an issue has been deleted.
You can use conditions to refine exactly the issue you are monitoring.
Related smart values: {{destinationIssue}}, {{linkType}}
The rule will run when an issue is linked to another issue.
You can configure this trigger based on any link type.
Related smart values: {{destinationIssue}}, {{linkType}}
The rule will run when an issue is unlinked from another issue.
You can configure the trigger to only execute for specified link types, or for all issue links.
Related smart values: {{issue}}
The rule will run when an issue is move from one project to another.
You can use this trigger together with conditions and actions to ensure all values, fields and settings are copied across to the new project.
Related smart values: {{issue}}, {{changelog}}
The rule will run when an issue transitions from one status to another.
You can configure this trigger so it listens to the status of your choice, or simply any transition in your workflow.
Learn more about transitioning an issue with automation
Related smart values: {{issue}}
The rule will run when the details on an issue are updated.
Exceptions on this trigger include changes made by the Link issue, Assign issue and Log work actions.
To trigger a rule when an issue’s status is updated, please use the Issue transitioned trigger instead
Related smart values: {{issue}}
The rule will run when it is manually triggered by a user. This trigger is useful for automating common tasks, or testing or debugging a rule. Learn more about using the Manual trigger to test rules
Once a rule is created with a Manual trigger, anyone with access will be able to trigger it by going to an issue and selecting Actions. You can refine which users can manually trigger a rule by selecting a permissions group in the Groups that can run trigger dropdown. Learn more about permission groups
You can also request input before a rule is run by selecting Get input from users. This allows you to set up some fields that will display to users when they trigger the rule. You can choose to make each field mandatory by selecting Required field. If a user chooses not to enter any information and selects Cancel, this won’t count as an execution towards your monthly limits.
Related smart values: {{issue}}
The rule will run when one or more selected issue events occur. For example, send a Slack message when an issue is updated, transitioned or assigned.
Using this trigger may be easier and more efficient than creating several different rules.
Related smart values: Jira smart values - projects
Rule will run when a project is created. For example, this could be useful if you want to create a set of default issues that should be included in all Jira projects.
Related smart values: {{issue}}
This rule runs on a specified schedule. You can run the rule at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules.
You can also choose to enter a JQL query. If you do, actions in this rule will execute on the issues included in the query.
Scheduled rules that reach a Failure status for 10 consecutive executions will disable automatically.
Related smart values: {{worklog}}
This rule will run when a work log is created, updated and/or deleted.
The following triggers are only available for Jira Software.
Related smart values: {{sprint}}
The rule will run when a sprint is created, started or completed on the selected scrum board.
This trigger will either run for every sprint on that board, or you can narrow this down using a regular expression.
You can use this trigger together with the related issues branch Issue fixed in version to loop through all issues fixed in this version.
Related smart values: {{version}}
The rule will run when a version is created, updated or released.
You can restrict which versions will trigger this rule using a regular expression.
The Version updated trigger listens for versions being created and released, as well as being amended. Use this trigger if you need to listen for all events around a version.
You can use the Version released trigger together with the related issues branch Issue fixed in version to loop through all issues fixed in this version.
These triggers are only available for Jira Software Cloud when integrated with a source code management tool. Check out the list of compatible tools
Self-hosted or On-Premise tools (e.g. Bitbucket Server, Gitlab On-Premise, Github Enterprise) aren't supported. Though they can still be integrated with Jira Software Cloud and you'll still get the benefits of integrating in other parts of your software project.
Related smart values: {{branch}}
Connect your source code management tool to use this trigger. Learn how to integrate your development tools with Jira Cloud.
You can use conditions to refine the branches you are monitoring with this trigger. The rule will run when a branch is created. For example, when a branch is created that includes an issue key, transition that issue to In progress.
Related smart values: Smart values - development
Connect your source code management tool to use this trigger. Visit the marketplace to integrate your build tool with Jira Cloud.
Rule executes when a build fails. You can configure this rule to only trigger on certain build names, or builds associated with certain branches or tags.
Related smart values: Smart values - development
Connect your source code management tool to use this trigger. Visit the marketplace to integrate your build tool with Jira Cloud.
Rule executes when the status of a build changes. You can configure this rule to only trigger on certain build names or builds associated with certain branches or tags.
Related smart values: Smart values - development
Connect your source code management tool to use this trigger. Visit the marketplace to integrate your build tool with Jira Cloud.
Rule executes when a build succeeds. You can configure this rule to only trigger on certain build names or builds associated with certain branches or tags.
Related smart values: {{commit}}
Connect your source code management tool to use this trigger. Learn how to integrate your development tools with Jira Cloud.
The rule executes when a commit is created. You can use conditions to refine the commits you are monitoring with this trigger.
Related smart values: Smart values - development
Connect your source code management tool to use this trigger. Visit the marketplace to integrate your deployment tool with Jira Cloud.
Rule executes when a deployment fails.
Related smart values: Smart values - development
Connect your source code management tool to use this trigger. Visit the marketplace to integrate your deployment tool with Jira Cloud.
Rule executes when the status of a deployment changes.
Related smart values: Smart values - development
Connect your source code management tool to use this trigger. Visit the marketplace to integrate your deployment tool with Jira Cloud.
Rule executes when a deployment succeeds.
Related smart values: {{pullRequest}}
Connect your source code management tool to use this trigger. Learn how to integrate your development tools with Jira Cloud.
The rule executes when a pull request is created. You can use conditions to refine the pull requests you are monitoring with this trigger. For example, when a pull request is created that includes an issue key, transition that issue to In review.
Related smart values: {{pullRequest}}
Connect your source code management tool to use this trigger. Learn how to integrate your development tools with Jira Cloud.
The rule executes when a pull request is declined. You can use conditions to refine the pull requests you are monitoring with this trigger.
Related smart values: {{pullRequest}}
Connect your source code management tool to use this trigger. Learn how to integrate your development tools with Jira Cloud.
The rule executes when a pull request is merged. You can use conditions to refine the pull requests you are monitoring with this trigger.
Related smart values: {{vulnerability}}
Connect a security tool to your project to use this trigger. Learn more about integrating security tools
Rule is run when a vulnerability in one of your connected security containers is found by your security tool and sent to Jira Software.
Only vulnerabilities that match a severity you choose will activate the rule, you can choose one one or more severities in the trigger.
For Jira Service Management only. Rule is run when an object from a specific Assets schema is created, updated, or deleted. This can only be used for global automation rules.
Learn more about Assets in Jira Service Management
Related smart values: {{breachedSummary}}, {{breachedRules}}
The rule will run when the daily or hourly processing time service limit is about to be breached (note that it doesn’t monitor other types of services limits, such as the “Items queued globally” limit). Read more about automation service limits
Related smart values: {{issue}}
The rule will run when a Jira Service Management SLA has breached or is about to breach.
This trigger allows you to provide timely feedback to customers, alert agents, and automatically prioritize requests accordingly. You can select the SLA to monitor, and the time before or after it has breached to trigger.
Rules using this trigger fail to run as expected in some rare cases, for example:
if an SLA breaches exactly when the SLA’s calendar ends for the day
if an SLA is set to breach within 6 minutes
when there are many SLA-based rules configured in various projects
You can track this bug at JSDCLOUD-10146.
If you’re blocked and if you absolutely have to, you may use the ‘SLA time remaining’ trigger in Legacy automation. Learn more about the SLA time remaining trigger
For Jira Service Management only. Rule is run when an issue that requires approval is created or updated, or when new approvers are added to an issue. Learn more about approvals in Jira Service Management.
For Jira Service Management only. Rule is run when an approval step on an issue is accepted or declined. Learn more about approvals in Jira Service Management.
Rule is run when a user reacts with an emoji to the issue created by Assist in Slack.
Currently, the trigger works only with issue messages created by the Atlassian Assist app in Slack channels. Learn more about chat
Since this trigger uses the Slack workspace and channels you set up in chat settings, it won’t work unless you connect this service project to a Slack workspace and channel. Learn how to set up chat in Slack
Was this helpful?