7.2 Automation Conditions, Smart Values & String/Date Expressions

7.2 Automation Conditions, Smart Values & String/Date Expressions

Quick Summary: In Jira Cloud Automation, Conditions determine whether a rule continues to execute, while Smart Values provide the dynamic data engine that injects contextual issue, user, and system information into conditions, actions, and messages. Mastering condition types—such as Issue Fields, Advanced Compare, User, and JQL conditions—combined with deep fluency in date manipulation arithmetic and string transformation functions is a primary focus of the ACP-120 certification.

---

Automation Condition Types in Depth

Conditions evaluate the runtime state of an issue or its surrounding environment. When a condition evaluates to False, the rule immediately stops executing for that specific issue. If the failure occurs before any action has run, the audit log records NO ACTIONS PERFORMED. Under Atlassian's current usage model, the trigger and the conditions that ran still count as automation steps, so put your cheapest, most selective conditions first.

+-------------------------------------------------------------------------+
|                     AUTOMATION CONDITION SPECTRUM                       |
+-------------------------------------------------------------------------+
|  Fastest & Most Performant                                              |
|  [ Issue Fields Condition ]  --> Checks 1 field against static value    |
|  [ User Condition ]          --> Checks user identity, role, or group   |
|  [ Advanced Compare ]        --> Evaluates 2 smart values with regex/ops|
|  [ JQL Condition ]           --> Runs search query against current item |
|  Heavy / Highest Resource Cost                                          |
+-------------------------------------------------------------------------+

1. Issue Fields Condition

The simplest, fastest, and most resource-efficient condition in the engine. It inspects a single field on the current issue against a defined value or another field:

• Supported Comparisons: equals, does not equal, is empty, is not empty, contains any of, contains all of.
• Performance Advantage: Because it evaluates the in-memory representation of the issue already loaded by the trigger, it incurs zero database query overhead. Atlassian recommends using this condition whenever evaluating straightforward field states (e.g., Status equals In Progress or Priority equals High).

2. Advanced Compare Condition

The Advanced Compare Condition evaluates two dynamic values using Smart Values:

• Structure: First value [Operator] Second value.
• Supported Operators: equals, does not equal, starts with, ends with, contains, does not contain, matches regex, does not match regex, greater than, less than, greater than or equals, less than or equals.
• Example Use Case: Checking whether the issue reporter is the same person as the assignee: First value: {{issue.reporter.accountId}}, Operator: equals, Second value: {{issue.assignee.accountId}}.
• Regex Matching: Supports full regular expressions to validate complex field formatting, such as verifying an asset tag matches ^[A-Z]{3}-\d{5}$.

3. User Condition

Validates attributes and group/role memberships of a specified user associated with the issue (Assignee, Reporter, Creator, Current Rule Actor, or a Custom User Picker field):

• Evaluation Checks:
  • User exists / does not exist (checks if unassigned or empty).
  • User is in group (e.g., jira-administrators, security-operations).
  • User has project role (e.g., Developers, Service Desk Customers).
  • User is / is not member of a specific organization (in Jira Service Management).

4. JQL Condition

Evaluates whether the current issue satisfies a full JQL query (e.g., project = "SEC" AND (labels in ("audit", "hipaa") OR priority = Highest)).

• When to Use: Use when evaluating compound Boolean logic (AND / OR combinations), hierarchical relationships, or history operators (WAS, CHANGED) that cannot be expressed in a single Issue Fields Condition.
• Performance Impact: The JQL Condition requires a database index query. In high-frequency rules (such as rules triggering on every issue edit), excessive JQL conditions can slow down rule execution. Best practice dictates placing fast Issue Fields Conditions before JQL Conditions to filter out irrelevant issues early.

5. If / Else Block Condition

Allows procedural, multi-branch conditional routing within a single automation rule. Instead of creating three separate rules to handle low, medium, and high priority issues, an administrator can structure an If / Else block:

• If: Condition 1 passes -> Execute Action Set A
• Else If: Condition 2 passes -> Execute Action Set B
• Else: All above conditions fail -> Execute Action Set C

---

Smart Values: The Dynamic Runtime Syntax Engine

Smart Values are dynamic placeholders modeled on the Mustache templating syntax. Wrapped in double curly braces ({{...}}), they resolve at runtime into real issue data, user metadata, system dates, or environmental parameters.

+-------------------------------------------------------------------------+
|                    CORE SMART VALUE OBJECT PATHS                        |
+-------------------------------------------------------------------------+
|  {{issue.key}}                 --> Primary issue key (e.g., PROJ-101)   |
|  {{issue.summary}}             --> Issue summary text                   |
|  {{issue.description}}         --> Full description content             |
|  {{issue.status.name}}         --> Status label (e.g., In Development)  |
|  {{issue.status.statusCategory.name}} --> Category (To Do, In Prog, Done)|
|  {{issue.priority.name}}       --> Priority name (e.g., High, Critical) |
|  {{issue.issueType.name}}      --> Issue type (e.g., Story, Bug)        |
+-------------------------------------------------------------------------+
|  USER ATTRIBUTES                                                        |
|  {{issue.assignee.displayName}}  --> Full user name (e.g., Jane Doe)    |
|  {{issue.assignee.emailAddress}} --> Email address (privacy dependent)  |
|  {{issue.assignee.accountId}}    --> Unique immutable Atlassian ID      |
|  {{initiator.displayName}}       --> User who fired the event           |
+-------------------------------------------------------------------------+

Custom Field Resolution: Name vs. Field ID (customfield_XXXXX)

Administrators can reference custom fields using two distinct syntaxes:

1. By Name: {{issue.Severity}} or {{issue.Cost Center}}
2. By Immutable System ID: {{issue.customfield_10042}}

[!IMPORTANT] The Enterprise Renaming Trap: Referencing custom fields by name ({{issue.Cost Center}}) is convenient, but introduces severe operational fragility. If a project admin or Jira admin later renames the field to Cost Center Code or fixes a typographical error, every automation rule referencing {{issue.Cost Center}} will silently resolve to null, causing conditions to fail and notifications to output blank text. In enterprise environments and on the ACP-120 exam, the best practice is to reference custom fields by their immutable custom field ID ({{issue.customfield_10042}}). The custom field ID can be found in the URL when viewing the custom field under Jira Settings > Issues > Custom fields.

Multi-Value Collections and List Properties

When referencing fields that contain multiple values (such as labels, components, fixVersions, or multi-select dropdowns), Jira exposes list methods:

• {{issue.labels.size}} — Returns the integer count of labels (e.g., 3).
• {{issue.labels.first}} — Returns the first label in the collection.
• {{issue.labels.last}} — Returns the final label in the collection.
• {{issue.components.name.join(", ")}} — Flattens the array into a comma-delimited string (e.g., "Database, Frontend, Auth").

---

Date and Time Manipulation & Arithmetic

Jira Cloud automation provides an extensive library of date arithmetic, formatting, and time zone manipulation functions. Dates are evaluated against the reference object {{now}} (the current timestamp at rule execution) or date fields on the issue (e.g., {{issue.created}}, {{issue.updated}}, {{issue.dueDate}}).

Practical Date Use Cases

• Auto-setting Due Dates: In an Issue Created rule, an action can set the Due Date field dynamically using: {{now.plusBusinessDays(3).format("yyyy-MM-dd")}}.
• Stale Issue SLA Notifications: In an Advanced Compare Condition, administrators can check if an issue has been untouched for more than 48 hours: {{issue.updated.diff(now).hours}} greater than 48.

---

String Functions & Text Processing

To cleanse, parse, and format text strings from user inputs, incoming webhooks, or descriptions, the automation engine supports chained string transformation methods:

Input String: "  incident-sev1-database-failure  "

{{issue.summary.trim()}}                      --> "incident-sev1-database-failure"
{{issue.summary.toUpperCase()}}               --> "  INCIDENT-SEV1-DATABASE-FAILURE  "
{{issue.summary.toLowerCase()}}               --> "  incident-sev1-database-failure  "
{{issue.summary.substring(0, 8)}}             --> "incident"
{{issue.summary.split("-").get(1)}}           --> "sev1"
{{issue.summary.replaceAll("-", " ")}}         --> "  incident sev1 database failure  "

Essential String Methods Reference

1. .toLowerCase() and .toUpperCase(): Standardizes case for comparison or output.
   • Example: {{issue.summary.toLowerCase()}} prevents casing mismatches in text comparisons.
2. .trim(): Strips leading and trailing whitespace characters.
3. .substring(startIndex, endIndex): Extracts a slice of text between the zero-indexed boundaries. If endIndex is omitted, extracts to the end of the string.
   • Example: If an issue summary begins with an external ticket code like [INC-9821] System Outage, {{issue.summary.substring(1, 9)}} extracts INC-9821.
4. .split(delimiter): Splits a string into an array based on a separator character or regex string.
   • Example: If a webhook sends user@domain.com, {{webhookData.email.split("@").first}} returns user.
5. .replaceAll(regex, replacement): Performs global pattern replacement across the string.
6. Default Fallback Values (| pipe syntax): If a smart value may occasionally be empty or null, appending a pipe followed by a default string prevents blank outputs:
   • {{issue.assignee.displayName|Unassigned}} — Outputs the assignee's name if assigned, or the literal text Unassigned if the field is empty.