Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Automation Jira

Download as pdf or txt
Download as pdf or txt
You are on page 1of 129

Welcome to this Atlassian University course on Jira Automation for Admins.

Here, you’ll come to understand how this powerful Jira Cloud feature can make your Jira
projects more efficient and streamlined.
And here is what you will learn:
• First, we will cover the basics of Jira automation and compare and contrast
automation rules versus workflow and other ways to automate Jira
• We will learn to configure all the various rule settings
• Explore plenty of use cases of rules that meet complex and diverse business
requirements.
• Along the way, we will learn many tips and tricks for configuring rules and
troubleshooting runtime errors.
• And finally, we will review global automation settings.
To succeed in this training and understand the use cases presented, you will need the
following:
• Practical experience in project administration
• And especially, a good understanding of project permissions.
• And you need to have mastery of JQL, since a few areas of automation depend upon it.
Here is our agenda.
Let’s begin with the overview of automation within the context of Jira.
Automation is a no-code, “if-this-then-that” rule builder that complements other ways to
automate Jira to make your projects and teams more powerful and efficient.
But don’t we have multiple ways to automate various bits of functionality in Jira? Yes,
we do.
First, we have workflows, of course. With post-functions,
• you can assign an issue to the current user or reporter, for example.
• And you can set, update, or clear various system and custom fields.
And there are bulk operations:
• Including bulk Edit Issues
• bulk Move Issues
• and bulk Transition Issues
You can also automate with various apps from the Marketplace that
• provide additional post-functions to extend workflows as well as ready—made scripts.
And finally,
• you can do some custom scripting through the Jira API.
• There are also email subscriptions which run the results of a saved filter on some set
schedule and send emails to the users or groups subscribed.
One of the great automation-related apps in the Atlassian Marketplace was, and still is,
Automation for Jira from the vendor Code Barrel.
The app was originally available for Cloud, Data Center and Server.
Then, when Atlassian acquired the company, automation became available as a native
Jira Cloud feature for the Jira family of products.
And the original app remains and continues to be sold as an app in the Atlassian
Marketplace for Jira Data Center and Server.

And note that Jira Service Management also has Legacy Automation. In cloud, legacy
automation rules will be eventually migrated to Automation for Jira.
There are various elements to configure in an automation rule. Let’s look at them briefly
in this module and then dive deeper in the next one.
The rule details section includes settings such as:
• the name
• and its scope – for example does the rule run in a single project or globally.
Triggers start the execution of a rule. Triggers can either listen for events or be scheduled
to run. Events include:
• Issue Created
• and Work Logged, among others.
Conditions ensure that actions will only execute if all conditions preceding them pass.
Examples include:
• Issue fields condition which checks whether an issue's field meets a certain criteria
• And User condition which compares a user against specified criteria. And there are
more.
Actions perform changes to a system such as:
• Transitions an issue from one status to another
• Or assign an issue to the user you select. And there are many more actions.
You can also create a separate section of a rule and perform actions and conditions on
other related issues. This includes:
• Sub-tasks of the issue that triggered the rule or
• Linked issues of the issue that triggered the rule.
And there is a on/off toggle setting which is useful during development and testing. A
rule can be
• Enabled or
• Disabled
Here is an example of a configured rule:
1. The trigger event is when an issue is transitioned to Done.
2. The condition checks if it has linked issues.
3. If so, a branch is created for those linked issues
4. And then the rule performs an action on each linked issue; namely, it adds a comment.
5. The rule is enabled
6. And we can see its Rule Details section.
“Holy mackerel! Is Jira automation going to replace my job?”, asks Tim, the newly
certified Jira Cloud Administrator. No, mate. You can keep your job. It’s just going to
make your job easier.
Rules can:
• Extend the out-of-box workflow functionality
• Ease the administrative burden of creating, testing, and maintaining workflows so you
spend less time in the workflow editor.
• And empower project administrators to meet their own business needs
But automation cannot replace workflows entirely. They remain the core engine that
powers Jira.

You need workflows to define the process flow through which issues move from creation
to completion, either through the issue view or via drag-and-drop on agile boards or via
automation.
Workflows allow you to configure conditions. For example, the user must be a member of
a group or role in order to see and execute particular workflow transitions.
And workflows also have validators which determine if a transition will execute
successfully, such as checking if the right value was entered on a transition screen.
Automation rules cannot meet requirements that necessitate the use of workflow
conditions or validators.
So now let’s look at the first use case; choosing ways to automate Jira.

Ted says he is spending too much time on (1) updating issues manually, (2) escalating
them, and (3) searching for them later to follow-up.

He asks for your help to automate his processes. Depending on some additional factors
and requirements, you need to choose the right method or combination of methods to
automate Jira.
In short, Ted could use a workflow post function to update fields during a transition. Or
he could use bulk operations to update or transition issues in bulk. Or he can create an
automation rule to update and transition issues based on various other triggers and
conditions or on a set schedule. He can create a gadget on a dashboard, or better yet, a
filter subscription to email him a list of Escalated issues to follow up later.

For more detail on the considerations and proposed solution, you can read through the
pdf solution guide that we’ve provided.
Now a quick knowledge check.

You received several business requirements. Which requirement must definitely be


satisfied with a workflow change versus an automation rule?
A. clear the assignee when reopening an issue
B. notify the scrum master when transitioning to Blocked
C. prevent the reporter from escalating issues
D. update the epic when all stories are done
Let’s take a closer look.
A. Incorrect. You can use the “Issue transitioned” trigger and the “Edit issue” action in an
automation rule to satisfy this requirement. You can also use a workflow post
function.
B. Incorrect. You can use the “Issue transitioned” trigger and the “Send email” action in
an automation rule to satisfy this requirement. You can also use a workflow post
function with a system or custom notification event.
C. Correct. To prevent a user from using a workflow transition (to escalate an issue), you
must use a workflow condition. Automation rules are not used for this purpose.
D. Incorrect. You can use the “Issue transitioned” trigger, a branch rule on Stories (or
other issues in Epic), and the “Edit issue” action in an automation rule to satisfy this
requirement.
Let’s now look in more detail at each of the areas of configuration, including automation
rule details, components, and smart values.
The Rule Details section contains a number of important settings.
• The name of a rule should be descriptive like “Close Duplicate Requests in ITHD project
” versus just “Jake rule #5”. This helps others to quickly scan rules and understand
what they may be doing. This is especially appreciated by Jira administrators who may
have hundreds of automation rules configured in their instance.
• Although the description field is optional, it is also best practice to enter more detail
here about what the automation does; especially for more complex rules with many
components.
• The Notify on error setting is a dropdown choice of three options. Your selection will
likely depend on whether you are still developing and testing the rule or whether it is
already in production.
• The Owner is the person who will receive emails when the rule fails.
• The Allow rule trigger setting is checked to allow other rule actions to trigger this rule.
Only enable this if you need this rule to execute in response to another rule. We will
come back to this in the final module.
• The scope of the rule is where the rule is running.
• And finally, the Actor is the person who will be “performing” the actions within the rule.
We will expand more on scope and actor in a moment.
• As we have just learned, each rule has a scope
• which specifies where the rule is running.
• “Running” means that the rule is listening for triggers and performing actions within
the project or projects listed in the scope.
• Scope is also related to automation rule execution limits as defined in the pricing plan.
The scope of a rule can be a single project. This is most common, and it is one of the
reasons that automation is so powerful. It empowers project admins to create and
maintain their own rules to perform actions only within their own projects without
adversely affecting others. Let’s say that a rule assigns all newly-created bugs to an
individual named Angie. Do you want this rule to run in every single Jira project or just the
one where Angie is responsible for fixing bugs?

Single project rules are also not counted towards the rule execution limits applied, based
on the pricing plan.
Rules can also run across multiple projects in your instance, for example projects that
share the same workflows.
Rules can also have project type as the scope. This means that they run across all
projects of a specified type like business, software, or service management projects.
And finally, you can write rules that run across all projects in your instance.

Rules that run on more than one project, and especially such global rules, are very
powerful but also potentially very destructive. That is why only Jira administrators can
create and maintain rules that have scope beyond a single project.

Global rules are available in any project. If a project administrator has been given rights
to manage automation rules, they can view global rules and make a copy of a global rule
to run and maintain in their own projects.
• Actor is another very important setting in the Rule Details section. Actions defined in
an automation rule are performed on behalf of the user selected as the actor.
• The rules can not perform any action that the Actor user can’t perform. Jira
administrators can modify the permissions scheme for a project to prevent the Actor
from performing certain actions. This enables a finer-grain control over what the rules
can do.
• Actor shows in the issue history tab as if the action was performed manually. For
example, if an automation rule is configured to edit each issue in a sprint, then the
History tab on those issues will show the rule actor as having made those updates.
• And the Actor will receive emails for each action that is performed on their behalf.
By default, any actions performed by Jira automation are seen as being performed by the
“user” called Automation for Jira. And by default, Automation for Jira has the necessary
permissions to perform all necessary actions within a project.
When configuring a rule, you have the option to change the rule actor, so that
automation rules can be seen as being run by an actual named user, a real member of
the team. For example, if an automation rule adds a comment to all issues in a sprint,
Anne may want to configure the rule so that the comment is added by her, instead of by
the Automation for Jira user.

Actions defined in the rule will be performed by the user that you choose – so you must
ensure that they have the necessary permissions to perform those actions.

If Anne does not have “Add Comment” permission, then that action in her rule will not be
executed. Other actions may still be executed, if Anne has the other required permissions.
You can also set the Actor to be the user who triggered the event, instead of the same
single named user. The rule will perform actions on behalf of the person who performed
the action that triggered the rule.

For example, let’s say there is a rule which adds a comment “Due Date was changed”
whenever a user modifies the Due Date. Then Cindy modifies the Due Date on one of her
assigned issues. The comment that is added to her issue when the rule runs will show her
as having made the comment, as opposed to Automation for Jira, for example. Once
again, you need to ensure that everyone who might trigger the rule has the appropriate
permissions.
Just note that project administrators can only make changes to a rule if they, or the
Automation for Jira user, are the rule actor. If someone else is the rule actor, they must
set the rule actor to be themselves or the Automation for Jira user before making
changes.

Jira admins can select anyone to be the rule actor. They can also change rule actors on
existing rules. If they do, the original actor will be notified.
• Every rule starts with a single trigger. They kick off the execution of your rules.
• A trigger presents the opportunity for an automation rule to be executed.
• There are different types of triggers, and some can be customized when applied to a
rule.
• Most commonly, those that respond to issue events in Jira, like issue created or field
value changed.
• DevOps-related triggers
• Product-specific triggers for Jira Software and Jira Service Management
• One for integrations
• There is also a trigger to run a rule manually from an issue
• Or to run on schedule. This variety in the type of triggers is one of the key reasons that
Jira automation is so powerful. Let’s look at the various types.
Triggers related to issue-based events are the most common. There are many of them, as
you can see, including Field value changed, Issue assigned, and Issue commented and
many others. You can also use a trigger to listen for multiple issue events and execute
actions whenever any of them occur.
DevOps triggers include ones like Branch created, Build failed, and the others listed.
These triggers are only available for Jira Software Cloud when integrated with a source
code management tool like Bitbucket Cloud, GitLab, GitHub, and BigBrassBand. To use
these triggers, you first need to connect your source code management tool to Jira.

As an example, a rule might be configured such that – when a branch is created that
includes an issue key – the rule transitions that issue to In progress. Another rule might
notify the team, when the build succeeds or fails.
All these triggers are only available for Jira Software. The first three are triggers when a
sprint is created, started or completed on the selected scrum board. And this can be set
to either run for every sprint on that board, or you can narrow this down using a regular
expression.

The next set here apply to when a version is created, updated, released or unreleased.
You can also restrict which versions will trigger this rule using a regular expression.
These two are related to Jira Service Management. The SLA threshold breached trigger
checks if the selected SLA has breached or will breach within the selected timeframe.
Object trigger means that the rule is run when an object from a specific Insight schema is
created, updated, or deleted. This can only be used for global automation rules.
The manual trigger can trigger the rule from issue details, so you can see its effects right
away. By default, all logged in users can run the rule, but that can be limited to only
certain groups who can run that trigger.
Scheduled triggers can execute a rule either on a fixed rate or via the advanced CRON
expression. Scheduled trigger also includes a Run rule button, so you can test what it will
do later once it is enabled for production. It is most convenient to use the manual or
scheduled triggers while testing rules.
Incoming webhooks are a simple way to trigger an automation rule from external
sources without requiring any extra authentication. This rule will run when a HTTP POST
is sent to the specified URL.
And the Project created rule can run whenever a new project is created.
• Conditions are optional.
• If you use one, it refines the rule.
• It acts as a check before executing the rule action(s).
• This help to avoid unnecessary action executions.
• Multiple separate conditions may be added.
• All the conditions must pass for the action(s) to be executed.
• The rule stops executing as soon as the first condition fails.
Issue fields condition checks whether an issue field meets a certain criteria. This
condition doesn’t require you to write smart values or JQL, and supports most common
Jira fields. For performance reasons, use this condition ahead of the JQL and Advanced
compare conditions, where possible.
User condition checks whether a user exists or is in a specified group. You can add
additional criteria to this condition, and select the logic of whether all or any of the
criteria must be matched. For example, before reopening an issue, you could check if the
user who added a comment to the issue is the reporter of the issue OR is a member of
the participants custom field.
Issue attachments condition checks if the comment or description fields of an issue
contains attachments. For example, you may want to check whether a customer has
included a screenshot, or if a vendor has included an invoice – if there are no
attachments, you could leave an automated comment requesting more information. We
will see an example of this in one of the use cases.
JQL condition checks to see if an issue matches a specified JQL query. Before getting
started with a JQL condition, check if you can use the Issue fields condition for your rule
instead. It is easier and quicker to set up.
The advanced compare condition compares two values, using smart values and regular
expressions. While the Issue fields condition will meet most needs, this condition
provides extra options, such as the use of regular expressions and functions.

For example, if you wanted to re-open an issue when a customer comments, you would
start with the Issue commented trigger. You could then add this condition to compare
the comment’s author with the issue reporter and add another condition to check if the
issue status is Done. Once these conditions are satisfied, the issue will transition to In
progress.
The If-else block performs alternate actions based on whether certain conditions match
or don’t match. It allows you to add as many if/else conditions as needed. The if block
executes the specified actions within that block when all the set conditions are met. If
the conditions are not met, the else blocks will be evaluated. The else block executes the
actions within the block if the preceding if/else-if blocks failed to match their conditions.
The else block can contain its own conditions, making it an else-if, or it can be left blank if
it is the last else block.
The Related issues condition is very powerful. It checks if related issues exist, or do not
exist, on the trigger issue. These related issues can be the parent of the current issue, or
its sub-tasks, or the epic that the current issue is associated with. Or if the issue itself is
an epic, then the stories or other issues in the epic, or linked issues, etc. It can also be
issues that match a specified JQL query.
This condition is only available on IT Service Management projects, for issues types that
contain an affected services field type. It checks if an issue’s affected services field
matches the set criteria. It can be configured to check against the service tier, services
name or dependent services.
• Actions performs the “work” of the rule
• such as manipulating one or more issues, which is most common.
• It can also send messages through email or Slack, for example,
• or make HTTP requests.
• Rules often have many actions.
Just like with triggers, there are a plenty of automation actions available, so we will
group them.

Issue-related actions include common ones like create issue or create sub-tasks, assign
issue, edit issue, transition issue, and comment on issue, as well as the others shown
here. And there are a few more, including Log work, Manage watchers, Edit comment, and
Delete comment, which are not listed here.
Notification-related actions can send a regular email, a Slack message, a Microsoft
Teams message, or a Twilio notification. We will see an example of Slack in one of the
use cases.
Software-related actions are Create version, Release version, and Unrelease version.
And Service Management-related actions include Create service request, Edit request
type, Approve/Decline request, and Add service project customer.
There are four more special actions which deserve some special attention. The first is
Create variable. This allows you to define a new smart value and use it later in the rule.
For example, you could use a smart value called {{source-key}} to capture the issue key
of the issue that triggered the rule. Then use that smart value later in a comment on
other issues. For example, “{{source-key}} was just escalated. Please review this related
issue.”
Log action is perfect for testing and troubleshooting, especially with complex rules and
when you use smart values. At any point in the execution of a rule, you can add the Log
action to add text to the audit log. You can reference the smart values here such as “The
source issue is {{source-key}}”
Lookup issues allows you to search for up to 100 issues using a JQL query. Then include
the results list in other actions by using the {{lookupIssues}} smart value. You can get
various issue properties from the lookup issues – including Reporter, Assignee, Summary,
Key, Issue Type, Status, Resolution, Story Points, and a few others – but custom fields
aren't available.
The re-fetch issue data action refreshes smart values with the latest field values. The
reason to use this is that by default, the {{issue}} reference is not updated during rule
execution, and contains the same values as when the rule originally triggered.
• Branches are optional in a rule.
• If needed, you can use one or more branches.
• A branch acts as an independent sub-rule.
• It runs conditions and actions on multiple related issues.
• In some ways, a branch is similar to the lookup issues action because it looks for a set
of issues. However, as we have just seen, lookup issues action can only view the data
from certain fields. It cannot manipulate those lookup issues. Let’s look at the various
branches we can create.
We can create branches for
• sub-tasks of the trigger issue
• or its linked issues
• issues fixed in a version
• or issues in a sprint
• or the stories or other issues in an epic.
• Likewise, we can create a branch for the parent of the triggering sub-task
• Or the Epic for the trigger issue
• We can also reference the current issue
• Or the most recently created issue
• Or the destination issue, but this is only applicable when using the Issue Linked trigger
in a rule.
• All issues created within the rule applies further conditions and actions to all issues
that were created by a previous action in the rule
• And a branch can be created for issues with a similar issue description
• Finally, we have the power JQL branch which can find any issues by using an advanced
search query.
• Your automation rule will perform actions on all issues returned by the above query,
and this can't be undone. So you should definitely ensure that your JQL is correct and
that you understand the actions that will be performed.
• Smart values are placeholders in conditions and actions.
• They allow you to access and manipulate issue data. Here are some examples.
• {{issue.key}} returns the issue key
• {{issue.summary}} returns the issue's summary
• {{issue.created}} returns the issue's creation date
• {{reporter.displayName}} returns the name of the reporter
• {{issue.issueType}} returns the issue's type, for example Story or Bug
• {{now.plusDays(5)}} references current time and adds 5 days to it
• {{now.plusDays(3).toBusinessDay()}} references current time and adds 3 business days
to it
• {{triggerIssue.comment.body}} references the comment of the trigger issue. And we
will see a few more examples in our use cases.
So, let’s look at a use case for conditional notifications.

Miss Moneypenny is the project administrator of MI6 project for UK’s Secret Intelligence
Service. It’s a company-managed project. Mission tasks are often escalated and everyone
in the service is notified. Agents complain that this interrupts them from saving the
world. So, Moneypenny has these business requirements. If the issue label is “global-
threat” then alert only James Bond. If the issue label is “routine-espionage” then alert
only members of the MI6-agents group.
In short, this is easily accomplished with an automation rule; using the Issue Transitioned
trigger, the “If-else block” condition evaluating the value of the Labels field (either
“global-threat” or “routine-espionage”), and the Send Email actions appropriately
sending a notification to either James Bond or to MI6-agents group, depending on the
label.

It’s as simple as that and Miss Moneypenny can do it herself, without involving the Jira
administrator.

You could also meet these requirements through workflow configuration, but it is a lot
more complicated. To see more detail on both solutions, you can read through the pdf
solution guide that we’ve provided.
We covered a lot of ground, so let’s see if you remember what you learned.

Which statement is true about configuring automation rules?

A. All triggers, conditions, and actions are available for all Jira products.
B. All automation rules require a trigger, a condition, and an action.
C. Each rule can only have one branch.
D. Each rule can only have one trigger.
E. Rules are always performed on behalf of the Automation user.
F. Rules are always performed in response to issue events.
The answer is D. Let’s go through each one to see why.

A. Incorrect. Some triggers are product-specific; for example, the “Sprint created” trigger
in Jira Software or the “SLA threshold breached” trigger in Jira Service Management.
B. Incorrect. Conditions are optional in automation rules.
C. Incorrect. Rules can have multiple branches.
D. Correct. Each automation rule can only have one trigger. “Multiple issue events” can
listen for multiple issue events, but it is still just a single trigger.
E. Incorrect. Rules are always performed on behalf of the actor, which could be
Automation for Jira, a named user, or the user who triggered the event.
F. Incorrect. Rules can also be performed manually, on schedule, or in response to
events in external systems.
Let’s move on to various use cases for automation. On each slide, we will show you the
configured automation rule and talk through the various components.
This first rule will auto-create sub-tasks.
• It is triggered manually from a particular issue by any member of the “certdevteam”
group. It has three actions, one for each sub-task.
• The first action creates the first sub-task and sets the Summary and Priority.
• The second action creates the second sub-task and sets the Summary and Assignee.
• The third action creates the final sub-task and sets the Summary and Due Date. Note
that you can use a single action to create multiple sub-tasks but only if you don’t have
to set any other fields besides Summary (which is always required).
This second rule will create a clone on transition.
• The trigger is when an issue is transitioned to In progress
• The condition checks if the issue is a Bug. If it is not, then the rule stops executing.
• If that condition passes, then the first action clones the issue as a Task issue type into
a different project (MI6NG).
• And the second action Links the two issues together.
This third example closes an epic when all its associated stories are done. The interesting
part is that it is triggered on the transition of any of the Epic’s issues, not the Epic itself.
Let’s see why.
• The trigger is Issue transitioned. When an issue is transitioned to Done
• Then use the Branch component to check if the current issue (which kicked off the rule)
is associated with an Epic. If it is not, then the rule will not go into the branch.
• Within the branch for the Epic, if the status of the Epic is not already Done (this is the
first condition)
• and all of the Stories on the Epic are Done (this is the second condition called “Related
issues condition”) then
• The action transitions the Epic itself to Done. With five simple components, you have
one very powerful rule.
Example 4: Validate after transitioning. We mentioned before that automation rules do
not perform validations, at least not in the way in which workflow validators do.
Workflow validators might check if a user filled out a particular field during the transition
(via the transition screen). If not, then the execution stops, and the workflow does not
transition to the next status. In this example, we can achieve something similar, though
not identical. Let’s assume that we are using this rule to check if the user who is
submitting an expense report added any attachments.
• The rule is triggered when an issue is transitioned to Submitted.
• The if condition checks if the issue does not have attachments. If it does not…
• then the action transitions the issue back to In Progress. And by the way, it might be
nice to add another action to add a comment for the user, letting them know that they
must attach receipts, for example.
• Then there is an else-if condition. This means that the first condition did not pass,
meaning it’s false that it doesn’t have attachments, meaning that it does in fact have
them. Yes, you might have to think about that double negative. So, the rule proceeds
to the else part. This checks if the Reporter is a member of some group; in this case,
MI6-agents.
• If yes, then it automatically transitions the issue from Submitted to Approved. The end
result is that everyone must attach documents when submitting expense reports. And
if MI6 agents submit issues with attachments, they get auto-approved. Which means
that fictional British spies get reimbursed for charred cars and torn trousers
so long as they provide receipts :-).
Now that you’re getting the hang of this, we will stop emphasizing whether a particular
component of a rule is a trigger, a condition, an action or a branch. For one, you might
have noticed by now that each component is appropriately color-coded. triggers are
green, conditions are yellow, etc. Secondly, you can easily follow the flow when you
actually see the configured rule. So let’s review this example number 5. Auto-assign
based on custom field.
• When an issue is created
• If the Region custom field is AMER
• Then assign the issue to the AMER Support person
• Else-if the value in the Region custom field is EMEA
• Then assign to the EMEA Support person
• Else-if the region custom field is APAC
• Then assign to APAC Support person. There are multiple other ways to assign issues
through automation, including Balanced workload method, Round-robin method, or
random. They make triaging and assigning incoming tickets a snap.
Example 6. Add labels based on Summary. This is a quick one.
• When an issue is created
• If the Summary contains the word “iPhone”
• Then add the label “mobile” to the newly-created issue.
Example 7. Tally Story Points after a sprint is completed. This rule uses a special action
called Lookup issues. It allows you to search for up to 100 issues using JQL and include
the results list in other actions by using the {{lookupIssues}} smart value. Let’s see how
it’s used here.
• When a sprint is completed in the MI6 board
• Use Lookup issues using the JQL query shown which is “sprint = {{sprint.ID}}”. This query
returns all issues in the sprint.
• And then send an email to someone (perhaps the product owner) with the Sprint
Name and total number of Story Points in the subject line. The way we tallied the Story
Points is by using that smart value {{lookupIssues.Story Points.sum}}. Does it look
right? Do you see anything that might be improved here?
• You might have guessed that the JQL could use a second clause like “AND status =
Done”. As it is written now, the JQL will return all issues in the sprint, regardless of
whether they were actually completed. The product owner probably prefers to see the
total number of completed story points instead. In either case, you should ensure that
your JQL is returning the right set of issues.
Example 8. Send a slack message about newly-created bugs.
• When an issue is created
• If it’s a bug
• And if the priority is greater than Medium (which would be High or Highest in a default
cloud instance)
• Then send a slack message to the designated workspace that includes some details
about the issue.
This integration involves just a bit of easy configuration.
• You need to configure an incoming webhook in your Slack account and then copy and
paste the Webhook URL into the appropriate field in the action component. That way,
Jira knows which Slack workspace to send the message to. By default, messages are
sent to the default channel specified in your webhook, but you can override this by
specifying another channel or a specific user.
• Also note the use of several smart values from the issue within the body of the slack
message.
Example 9. Issue links are great but not everyone uses them. Sometimes, users just
mention an issue within the body of a comment. Wouldn’t it be nice if the issue link was
added automatically whenever they do that? Well, there’s an automation rule for that.
• When an issue is commented
• If the comment body contains the regular expression that represents an issue key
• Then link the current issue to that other issue which matches the key that was entered
into the comment, using the specified link type. This rule seems a bit tricky but only
because you must get the correct syntax for parsing regular expressions. Don’t worry,
there’s a pre-configured sample in the rule library. We will talk about that in the use
case at the end of this module.
Example 10. Assign issues on schedule. 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 enter a JQL query and actions in this rule will execute
on the issues included in the query.
• This particular rule is triggered on schedule daily at 8pm using a JQL search that finds
issues whose priority changed to Highest after the start of day.
• For each issue in the result set, if the issue is unassigned
• then assign the issue to a member of the certdevteam group, using round-robin
assignment. From an earlier example, recall that we mentioned there is also Random
assignment and Balanced workload assignment – whereby work is balanced among
team.
• And once again, ensure your JQL is returning the right issues first in Issue Navigator
before you start running the rule.
Example 11. You can also have Jira communicate with other external systems. The
combination of incoming webhook and the ability to send web requests means that you
can do things like creating a Jira issue with a call from an external system without using
Jira. The reply from the automation rule – sent via the Send web request action – can
include the newly created issue key. This key can then be displayed in the external
system.

In this quick example, we are sending information between one Jira cloud site and
another.
1. When an issue is created in one of the sites
2. Then send a web request to the other Jira site
3. When the other site receives the incoming webhook
4. Then it creates an issue, presumably with some of the information that was sent over.
Here is an example of chained rules.
• Rule 1 is called “Update the Due Date on an Epic”.
• Runs on schedule (using a JQL query that finds escalated Epics)
• And Edits the Due Date on the Epics
• Rule 2 is called “Copy the Due date from Epic to Stories”
• When a Due Date changes
• If the issue is an Epic
• Then it creates a branch for all the Stories (or other issues) in the Epic
• And edits their Due Dates by copying the date from the Epic.
It’s this second rule that has the box checked to “Allow rule trigger”. When checked, it
allows other rule actions (those from Rule 1) to trigger this rule (Rule 2).

The net result is that whenever the Due Date changes on an epic – whether it’s done
manually by a user or on schedule by Rule 1 – then the Due Dates on its associated issues
are updated to match.
lf you are like project manager Tanya, you might be thinking to yourself, “That’s a lot of
examples; are there more?” and “How can I get started quickly writing my own
automation rules?”
You are both in luck. You can add a pre-configured rule in project settings and then
customize it or head to the rule library to see more examples.

The pdf solution guide contains plenty of links to various resources.


Now time for a knowledge check. You need to create a rule that checks if an issue that
was just closed is a parent and if it has sub-tasks, and if it does, then it comments on the
sub-tasks. Which rule component is definitely needed?
A. Condition
B. Branch
C. Lookup issues action
D. Smart value

Before we look at the answer, let’s pause to re-read the question. Notice there are three
“if” words in the question. Does this mean that you definitely need conditions?
No. If you phrase the question in another way, you might see that’s not the case.
Translating requirements is often the hardest part of the solution. Here, they are actually
simpler than they first appear. Trigger the rule when an issue is transitioned to closed.
Create a branch for related issues (sub-tasks). The branch itself determines if there are
any sub-tasks or not, so you don’t need a condition. For any sub-tasks that exist,
comment on them.

A. A is incorrect. You don’t actually need a condition.


B. Is Correct. You do need the branch.
C. Is incorrect because lookup issues action cannot manipulate the issues.
D. Is incorrect. While you may need a smart value in the rule, it is not definitely needed,
based on this scenario.
Let’s move on to tips, tricks, and techniques for configuring and troubleshooting
automation rules.
First, where do you go to unlock the power of Jira automation? There are multiple ways
to navigate to the area where you can create and manage automation rules. And it can
be confusing depending on whether you are only a project administrator or also a Jira
administrator.
• First, you will see the Automation icon (which is the lightening bolt) in several places:
• on the top-right of project boards.
• and on bottom-right when you have an issue open in view. If there are enabled manual
rules, you can run them. Otherwise, if you are a project administrator, you can go to
manage rules or create a new one.
• Alternatively, project administrators can head straight to Automation under Project
Settings.
• And Global Jira Administrators can always go to the system menu, and then find
Automation and Automation rules.
How will I know if a rule fails?
• The “Notify on error” setting is found in Rule Details. It is a dropdown choice of three
options
• While you are developing and testing a rule, it’s best to set it to Don’t notify otherwise
you will be flooded with email.
• After the rule is successfully enabled, you should switch to either “E-mail rule owner
once when rule starts failing after success” or "E-mail rule owner every time this rule
fails”.
What’s the best way to build and test rules?
• First, it’s best to test rules away from production; which might be a test cloud site or
at least a test project.
• Second, build the rule slowly step-by-step and check that each component is working
as expected.
• Use “Log action” to test and troubleshoot rules. It adds a text value to the audit log at
the location in the rule where you enter it. “Log action” actions are especially useful
when debugging smart values. To test what a smart value returns, you can use the
Manual trigger with Log action. The result displays in the audit log.
So, make the audit log your best friend. Each of your rules will have an entry each time
the rule was triggered. It will show the final result of the execution and any actions that
may have been performed. You can view the audit log of an individual rule, project-wide
or at a global level. Reviewing your audit logs is an effective way of debugging your rules.
Take note of what the different statuses mean at the bottom of the audit log.
So now let’s move on to some common rule problems and the right questions to ask in
order to troubleshoot and fix them. But of course, the best way to handle errors is to
prevent them in the first place. Here is the first problem. My rule isn’t running at all.
• Is it enabled?
• Is it configured to respond to the correct trigger?
• Is the trigger event happening?
• Is it configured to run in your project?
Why is my rule running but not performing the actions?
• What is the status of the rule execution?
• Did you check the audit log?
• Is the condition being met?
• Are you using multiple conditions or an if-else block condition? It might be failing at
the first condition.
• Does the rule actor have the correct permissions to execute the actions? Especially if
it’s not Automation for Jira but a named user or the user who triggered the event.
What if some, but not all, of the expected issues are being processed?
• Do all of them meet the conditions of the rule?
• Does your rule use JQL and is it returning the right set of issues?
• You can click Validate query to check that your JQL query is working correctly.
However, if you’re using smart values, you won’t be able to check if your JQL is valid.
That’s a good opportunity to use Log Action to check the contents of your smart
values.
In this use case, we will help Tara troubleshoot and fix some problems with her rule.
The short answer is

If you would like to see more detail and a virtual walkthrough of the solution, you can
read through the pdf solution guide that we’ve provided.
It’s time for a knowledge check. When Anne triggers a particular manual rule, it performs
all the actions. But when Bob triggers it, it does not. Identify a possible reason for this
behavior.

A. Anne is the rule actor.


B. Anne is the rule owner.
C. Bob does not have access to the project.
D. Bob does not have a global permission.
E. Bob does not have a project permission.
The problem here is related to permissions. If the rule were running as Automation for
Jira, then it would either perform or not perform all the actions for all the users who
trigger the rule. The rule actor must be the “User who triggered the event” and Anne must
have some project permissions that Bob does not.
A. Incorrect. If Anne was the rule actor, then it would run in the same way for both Anne
and Bob.
B. Incorrect. The rule owner is irrelevant.
C. Incorrect. If Bob does not have access to the project, then he couldn’t have triggered
the rule manually from a project issue.
D. Incorrect. There are no global permissions needed.
E. Correct. As explained above, the rule actor must be the “User who triggered the
event” and Bob must be missing some permissions that Anne has.
Global administration provides rule management across the site and is only available to
Jira administrators.
Jira administrators can get to global automation administration from the System menu
or from project administration by clicking on the Global administration link.

1. Here, they can create, view, and edit rules across the entire site.

2. They can add labels to organize rules.

3. Disable and remove rules. This is especially handy if they want to remove rules
created by others that are no longer needed.

4. They can also copy rules, so the core is the same but then they can customize it.

5. And finally, they can export one or more rules from one site (in JSON format) and then
import all of them, or just some of them, into another.
They can also check the performance insights which is a great way to see and
troubleshoot performance issues.
1. You can see excessive usage.
2. As well as execution counts and duration, so you can see which rules are throwing
errors and which rules are taking a long time to execute.
1. Via the usage link, Jira administrators can monitor the number of rule executions used
and still available.
2. Rule executions count as any rule that has been triggered, even if no action is
performed. The number of executions gets reset at the beginning of each month.
3. Rules will trigger until you reach your monthly limit.
4. Single project rules are not counted towards your limit.
5. And enterprise users can have unlimited automation rules across as many Jira
projects as needed.
6. For the rest, execution limits apply based on pricing plan and licensed products.
You might also consider who can create and manage rules.
• Global Jira administrators
• can always manage rules with any scope (multiple projects, global, etc.)
• They can also limit if and which project administrators can create and manage rules,
as well. But remember that project admins can only ever manage single-project rules.
• They can do so by default in a freshly configured cloud site.
• But Jira admins can limit this to only those within a specific group or groups.
• Or they can restrict project admins from creating and managing rules altogether by
unchecking the appropriate box in global configuration.
And finally, Jira administrators can use the Transfer user feature. This replaces all
references to a user in all rules. This is especially useful when team members change or
when migrating projects. You can preview your changes before executing.
Let’s look at a typical use case for Jira administrators. Hakeem says, “We sometimes run
into rule execution limits on our cloud site. What can I do to prevent this?” Hakeem
needs help monitoring and optimizing rules across the organization.
As we saw in this module, Jira provides a number of great tools to monitor usage, view
performance insights, and control rule scope and permissions.

The pdf solution guide provides more detail on how to use these tools to prevent
breaching execution limits.
Now for a knowledge check. Review information about the four customers below. Which
customer is most likely to exceed their rule execution limit?

Is it Customer 1, 2, 3, or 4.
It’s Customer 2. Let’s review why.

A. Incorrect. Customers on Free and Standard plans have access to a limited monthly
trial allotment of global and multi project rule executions (100 and 500 per month,
respectively). However, regardless of anything else, project administrators can only
create and manage single project rules and these rules do not count towards the
execution limit. Since only project admins create rules for customer 1, they are not
likely to breach their limit.
B. Correct. Premium users have 1000 global and multi-project rule executions per paid
user per month. So, 10 users in Jira Cloud Premium will have 10,000 monthly
global/multi-project rule executions per month. But this is pooled across all Jira tools
and all users. Customer 2 has 3 products, and 5 Jira administrators are creating rules,
which means there could be a lot of rules needed and those rules could be multi-
project or global rules. There is some likelihood they may reach their execution limit.
C. Incorrect. 400 users in Jira Cloud Premium will have 400,000 monthly global/multi-
project rule executions per month. But they use only 1 product and only 1 Jira
administrator is occasionally creating rules. The rest are project administrators. So,
although there is also some likelihood they may reach their execution limit, that
likelihood is lower than Customer 2. Because they have a much higher limit and a
lesser chance of having multi-project and global rules.
D. Incorrect. This is an enterprise customer. And Enterprise users have access to
unlimited automation executions.
So here are your takeaways:
• Automation replaces manual and repetitive work to make your projects and teams
more powerful and efficient.
• Automation rules are flexible and highly configurable.
• They empower global Jira administrators and project administrators.
• Automation is easier to implement than complicated workflow configurations and
comes with plenty of pre-configured examples to help you get started quickly.
Congratulations on completing this course!
We hope you enjoyed this course and learned useful things that will help you in your
daily job as a Jira project administrator.

For further information, visit our online resources including Atlassian University, Atlassian
Community and Atlassian's product documentation.

For more in-depth help, contact Atlassian Support or locate one of the Atlassian Solution
Partners near you.

You might also like