You can specify conditions that must be met for your rule to continue running. For example, your rule will only escalate an issue if it is high priority.
Conditions can be placed anywhere in the rule chain. If a condition fails, no actions following it will be performed. The exception is with the If/else block condition. Not all rules need to have conditions.
Issue fields condition
- Use smart values here: No
- Available in Server Lite: No
This condition allows you to quickly put a condition together without needing to write smart values or JQL. You just click what you want from our populated dropdowns and fill in the blanks. It supports most common Jira fields. Use this condition ahead of JQL and Advanced Compare Condition, where possible.
Advanced compare condition
- Use smart values here: Yes
- Available in Server Lite: No
This powerful condition allows you to compare objects using using smart values and regular expressions.
In most cases, you should use the Issue Fields Condition, but the Advanced Compare Condition can give you some extra options (regular expressions, functions etc.).
Let's look a real life use case as per the screenshot below. If you wanted to re-open a Jira issue when a customer comments, you would start with the Issue Commented trigger, add a condition that compares the comment's author with who the reporter is, add lastly add another condition to check if the issue's status is 'Done.' Once these conditions are satisfied, transition the issue to 'In Progress'
Comparison methods:
- Equals (the assignee is Bob)
- Does not equal (the assignee is not Bob)
- Starts with (the reporters name starts with A)
- Contains (the summary contains Beer)
- Does not contain (the summary does not contain Beer)
Comparing using regular expressions
You can use regular expressions to test for a pattern. For example, check whether a field value contains, exactly matches or doesn't contain what is in the regular expression field:
If/Else block
- Use smart values here: Yes
- Available in Server Lite: No
The 'If else' block allows for alternate actions to be executed based on whether certain conditions match or don't match. It is a really powerful condition and you can add as many if/else conditions as you want.
Issue attachments
- Use smart values here: No
- Available in Server Lite: No
This condition runs a simple check: does the comment or description field have any attachments? For example, you may want to check whether a customer has included a screenshot, a vendor has included an invoice, or your lawyer has attached your divorce papers.
When an issue is created, if there are no attachments, then you can leave an automated comment for the customer requesting more info.
To get more granular, you could combine this condition with a JQL search condition to see if the filename is a specific format. You can also include a conditional compare on some of the properties of your attachments (list not exhaustive):
- filename {{attachment.filetype}}: the filename of the attachment
- mimeType {{attachment.mimeType}}: the file format of the attachment
- author {{attachment.author}}: the user who added the attachment
- accountId {{attachment.author.accountId}}: the ID associated with the user name
- emailAddress {{attachment.author.emailAddress}}: the email address associated with the user name
- displayName {{attachment.author.displayName}}: the name displayed in your Jira instance
- active {{attachment.author.active}}: Is the user an active user or has their account been deactivated
- timeZone {{attachment.author.timeZone}}: what timezone the user is registered being in (this does not change dynamically based upon where the user logs in from, it is the timeZone registered in their user account)
- created {{attachment.created}}: the date and time the attachment was added to the issue
- size {{attachment.size}}: the attachment file size in bytes
JQL
- Use smart values here: Yes
- Available in Server Lite: Yes
Tip
Before you get started with a JQL condition, check to see whether the Issue Condition can do the same job as it will be easier and quicker.
JQL is the most powerful and flexible way to search for your issues in Jira. Naturally, we provided this same functionality as a condition for Automation for Jira. This condition checks to see if an issue matches a specified JQL query and, if it does, the rule is allowed to continue running. If the condition doesn't pass, the rule stops running.
Mistakes can be made when putting together JQL but we provide a handy validation button within the condition so you can check that it works (if you use Smart Values, we can't check whether the JQL is valid though).
The example below is checking that the status category of the status for a given issue is Done.
There is lots of information on how you can use JQL to search for issues from Atlassian.
Related issues
- Use smart values here: No
- Available in Server Lite: No
This condition goes through issues that are linked to the trigger issue (parent, sub-tasks, epics, stories, etc.) and checks if the related issue exists, does not exist, or if it matches a JQL query or not.
User
- Use smart values here: Yes (use in Criteria)
- Available in Server Lite: Yes
This condition allows you to check whether a specified user exists or is in a specified group. You can add multiple criteria for checking users in a single condition and you have the option to match all of them or just some of them.
So if you want to check if the user who added a comment to an issue was the reporter of the issue OR is a member of the ‘participants’ custom field before re-opening an issue, you can! Check out this article that explains how you can use the user condition for different tiers of support in an organisation and working out if a user commenting is the customer
Watch out for the default limit
By default, Automation for Jira can only check the first 50 users that belong to a role. If the role has more than that, you might get inaccurate results—your user can still belong to this role, but the limit doesn’t allow us to find them. You can increase the default limit by setting the following property:
user.condition.get.users.limit