Key concepts

Still need help?

The Atlassian Community is here for you.

Ask the community

Here are some key concepts that you might find useful when working with Jira automation.

What are automation rules?

Rules allow you to automate actions within your system based on criteria that you set. Automation rules are made up of three parts: triggers that kick off the rule, conditions that refine the rule, and actions that perform tasks in your site.

  1. Trigger that kicks off the rule
  2. Jira automation conditions that refine the rule
  3. Jira automation actions that perform tasks in your Jira instance.

What are smart values?

Smart values are placeholders that let you pull in dynamic data. You can use them to access and manipulate almost any issue data from Jira. 

For example:

  1. {{reporter.displayName}}: Inserts the name of issue's reporter.
  2. {{issue.summary}}: Inserts the issue's summary.
  3. {{reporter.displayName}}: Inserts the name of issue's assignee.

Smart values allow you to access and manipulate pretty much any issue data from Jira. While they do take a little bit of learning, they add significant power and personality to your rules.

Learn more about smart values

What is a rule actor?

By default, any actions performed by Jira automation are seen as being performed by the “user” called Automation for Jira . For example, if an automation rule transitions an issue to Done, in that issue’s History tab it will show as having been transitioned by Automation for Jira. We call this user the rule actor.

When configuring a rule, project admins and site admins have the option to change the rule actor, so that automation rules can be seen as being run by a real member of the team. For example, if an automation rule adds a comment to all issues in a sprint, a team lead may want to configure it so that the comment is added by them, instead of by the Automation for Jira user.

To learn more about changing a rule's actor, see Run Jira rules as another user.

What is rule branching?

When configuring automation rules, it's possible to create a separate section of the rule and perform actions on related issues - this is referred to as branching. This is in reference to the rule no longer executing in a linear fashion, but instead expanding out to multiple paths.

For example, a rule that’s triggered when an issue transitions to Done could also have a branch that performs separate actions on that issue’s subtasks.

In the screenshot above, we have an automation rule consisting of a trigger, an action, and a branch.

  • The Scheduled trigger and Create a new task action are the main line of the rule.

  • The For all created issues branch allows the rule to add a comment on the task that was just created. Without this branch, we wouldn’t be able to add a comment on the new task.

Learn more about rule branching

What is the audit log?

Each of your rules will have an audit log that you can review to see when the rule was triggered, the final result of the execution, and any actions that may have been performed in the last 90 days.

For each rule execution, the audit log will display:

  • Date: the date and time that the rule was triggered.

  • Rule: the name of the rule.

  • Status: the status of the rule execution.

  • Duration: the length of time the rule took to execute.

  • Operations: the actions that the rule performed and any associated items.

You can view the audit log of an individual rule, project-wide or at a global level. 

Learn more about the audit log

Last modified on Jun 21, 2022

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.