Automation Rules

On this page:

1 Overview
2 What are automation rules
3 Export automation rules
4 Supported components
- 4.1 Triggers
- 4.2 Conditions
- 4.3 Branches
- 4.4 Third-party components
- 4.5 Advanced fields
- 4.6 Smart values
5 Limitations and known behavior
- 5.1 Secret keys
- 5.2 External references
- 5.3 Error handling

Overview

Minimum supported Automation for Jira version: 8.0.5

Configuration Manager for Jira (CMJ) supports automation rules as part of snapshot creation and deployment. This functionality allows teams to confidently migrate and manage automation configurations across environments - just like any other supported Jira configuration.

What are automation rules

Automation rules in Jira allow teams to streamline repetitive tasks by creating flexible if this, then that logic. These rules automate common actions like assigning issues, sending notifications, or updating fields, thus saving time and reducing manual errors.

A typical rule is made up of:

Triggers – Events that start the rule (for example, when an issue is created or transitioned)
Conditions – Criteria that determine whether the rule should proceed (for example, issue type is bug)
Actions – Tasks that are performed when the rule runs (for example, assign the issue or send a Slack message)

Why does CMJ support matter?

With Configuration Manager for Jira, you can now include automation rules in snapshots and deploy them across environments. CMJ takes care of identifying and remapping references (like fields, users, and projects), ensuring your rules remain intact and functional after migration.

Export automation rules

When creating a snapshot, the first page of the export wizard shows the checkbox Include Automation Rules. The box is checked by default.

Screenshot of Select Snapshot Type with the Include Automation Rules option selected.

When checked, CMJ will automatically gather the automation rules based on your current snapshot type:

System snapshot - all automation rules on the system
Project configuration snapshot - all project-specific (related to the included projects) and global automation rules
Project with issues snapshot - all project-specific (related to the included projects) and global automation rules

Supported components

CMJ supports the majority of Automation for Jira rule components, including:

Triggers

Issue transitioned trigger
Field value changed trigger
Incoming webhook trigger
Issue archived trigger
Issue assigned trigger
Issue commented trigger
Issue created trigger
Issue deleted trigger
Issue linked trigger
Issue restored trigger
Issue updated trigger
Issue link deleted trigger
Issue moved trigger
Issue property updated trigger
Manual trigger
Multiple issue events trigger
Scheduled trigger
Service limit breached trigger
Version created trigger
Version released trigger
Version unreleased trigger
Version updated trigger
Work logged trigger
SLA threshold breached trigger
Sprint created trigger
Sprint started trigger
Sprint completed trigger

Conditions

Issue fields condition
If/else container condition
Issue attachments condition
Related issues condition
JQL condition
User condition
Advanced compare condition

Actions

Link issues action
Create issue action
Comment on issue action
Archive issue action
Clone issue action
Edit issue action
Transition issue action
Assign issue action
Create sub-tasks action
Send Slack message action
Send HipChat message action
Delete issue action
Delete comment action
Delete issue links action
Manage watchers action
Log work action
Create variable action
Lookup issues action
Send Microsoft Teams message action
Send email action
Add Service Management Customer action
Create Service Management request action
Create version action
Release version action
Unrelease version action
Delete attachments action
Log action
Publish event action
Re-fetch issue data action
Set entity property action
Send web request action
Send Stride message action
Send Twilio notification action

Branches

Related issues branch

CMJ will resolve and remap any referenced Jira configuration within these rule components, including custom fields, projects, workflows, users, and groups.

Third-party components

All custom components (triggers, actions, conditions) provided by other vendors via the Automation for Jira API are also supported and exported/imported as-is. However, keep in mind that they are not updated during deployment and should be manually reviewed afterward.

Advanced fields

Some actions within automation rules—such as Clone issue, Create issue, Edit issue, Transition issue, and Create Service Management request—support an Advanced fields option. This option allows you to define custom field values and other issue properties using a structured JSON format.

CMJ supports automation rules that use advanced fields. During export and deployment, CMJ automatically detects and remaps all referenced configuration elements (e.g. custom fields, users, groups, issue types) inside the JSON structure.

Make sure the JSON structure follows Jira’s format exactly. Malformed JSON may limit CMJ's ability to resolve certain references during deployment.

Smart values

Smart values are dynamic placeholders that can be used in almost any automation rule component - including actions, conditions, and advanced fields. CMJ supports the use of smart values across all supported automation rule components.

During export and deployment, CMJ identifies any custom field references used inside smart values and updates those references to match the IDs and names on the target system.

Smart values can also be used:

inside Advanced fields JSON;
within JQL queries used in conditions or actions;
in third-party components.

Smart values in Advanced fields

When a smart value is embedded inside an Advanced fields JSON object, CMJ behaves as follows:

If the JSON can be parsed, CMJ resolves both standard references and smart value references.

{
    "fields": {
        "user cf 1": { "name": "{{user cf 2.name}}" },
        "user cf 3": { "name": "testcho" }
    }
}

If the JSON cannot be parsed, CMJ resolves only smart value references.

{{#if(equals(issue.assignee.key, "admin"))}}
  {
    "fields": {
      "description" : "test descrp"
    }
  }
{{/}}

Smart values in JQL

Smart values can also be used within JQL strings in rule components (for example, in JQL conditions or Related issues branches). In these cases, CMJ exports only references in the embedded smart values.

Smart values defined by third-party components

Automation for Jira provides API that allows integrated apps to define their own smart values. Such smart values will be migrated as-is.

In rare cases, CMJ might not be aware of a smart value defined by a third-party component and may treat it as a custom field name. As a result, Integrity Check will log a false warning. These warnings don’t prevent deployment and can be safely ignored if the smart value is working as intended.

If you notice false warnings, you can contact our customer support so we can update our list of third-party smart values.

Limitations and known behavior

While most of the automation configuration is supported, the following are not currently migrated:

Global configuration (for example, audit log settings, URL allowlists)
Secret keys stored in Jira's secure storage
Automation audit logs

Secret keys

Some automation actions - such as sending webhooks, Slack messages, or Microsoft Teams notifications - require secure credentials to connect with external services. These credentials are stored in Jira’s secret storage system as secret keys.

CMJ does not export or migrate secret keys, since these values are encrypted and unique to each Jira instance. Instead, during deployment, CMJ attempts to match any secret key references in the automation rule with existing secrets on the target instance. If the same key name is not found, CMJ inserts a placeholder with a dummy value so that the rule can still be deployed.

After deployment, it's important to review any automation rules that use secret keys and update them with the correct values manually. These updates must be made within the Automation for Jira UI on the target system. CMJ logs a warning in the Audit Log whenever a dummy secret is created, making it easier for administrators to track which rules need review.

For example …

If a rule sends a Slack notification but the required secret is missing on the target system, CMJ will generate a dummy webhook URL like https://hooks.slack.com/slack_cmj_webhook. This placeholder allows the rule to be imported, but it won’t function correctly until the secret is replaced.

Deploying a snapshot with an older Automation for Jira version on a destination instance with a newer version

If you deploy a snapshot created on a Jira instance running Automation for Jira version lower than 9.0.1, and the destination instance is on version 9.0.1 or later, CMJ will still create dummy secret values for any notification actions that require them. Once deployment is complete, you’ll need to manually create the necessary secret keys in the destination system and update the affected rules with the correct credentials or tokens.

External references

CMJ handles automation rules similarly to filters. Any references to projects, issue security levels, versions, components, agile boards, sprints, customer organizations, and workflows will not be included in the snapshot if they are referenced only by automation rules.

If the configurations missing from the snapshot are not present on the target system, a warning will be shown during the analysis phases in the deployment wizard. The automation rule will still be deployed, but will not be functional. You can review the affected rules after deployment.

Error handling

Minor configuration issues will not block snapshot creation or deployment. These are logged for review. After the operation is completed, we recommend checking the CMJ audit log for any referenced automation rules and verifying their configuration.

Critical configuration issues are treated as errors. These must be resolved before a snapshot can be successfully created or deployed.