Study guide
7.2 Automation Conditions, Smart Values & String/Date Expressions
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
7.2 Automation Conditions, Smart Values & String/Date Expressions
Key Takeaways Explain This Topic AI
Automation conditions act as gatekeepers; if an evaluated condition fails, rule processing immediately terminates (short-circuits) for that branch or issue without executing downstream actions.
The four primary condition types serve distinct operational roles: Issue Fields Condition (fast, single field checks), Advanced Compare Condition (evaluates dynamic smart values and regex), User Condition (evaluates user identities, roles, and groups), and JQL Condition (evaluates multi-field criteria).
Smart Values use double curly brace syntax {{...}} to dynamically inject runtime issue properties, contextual actor data, and custom field values into strings, emails, comments, and condition comparisons.
Custom field smart values should reference the immutable system identifier {{issue.customfield_XXXXX}} rather than human-readable names to safeguard enterprise rules against breaking changes when fields are renamed.
Date and string transformation functions (such as .plusDays(n), .format(), .toLowerCase(), .split(), and .substring()) provide powerful text manipulation and SLA date arithmetic directly within automation rules.
Last updated: September 2026
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:
- By Name: {{issue.Severity}} or {{issue.Cost Center}}
- 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}} ).
Function / Syntax Operational Purpose & Evaluation Behavior
{{now}} Returns the current timestamp in ISO-8601 UTC format.
{{now.plusDays(7)}} Adds 7 calendar days to the current timestamp.
{{now.minusHours(4)}} Subtracts 4 hours from the current timestamp.
{{now.plusBusinessDays(5)}} Adds 5 business days, skipping Saturdays and Sundays.
{{issue.dueDate.format("yyyy-MM-dd")}} Formats the issue's due date into standard ISO format (e.g., 2026-10-15 ).
{{now.format("EEEE, MMMM d, yyyy")}} Formats date into long text (e.g., Monday, September 28, 2026 ).
{{now.setTimeZone("America/Chicago")}} Converts the timestamp to the specified time zone identifier.
{{issue.created.diff(now).days}} Calculates the numeric difference in full days between issue creation and now.
{{issue.created.diff(now).hours}} Calculates the numeric difference in hours between issue creation and now.
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
.toLowerCase() and .toUpperCase() : Standardizes case for comparison or output.
Example: {{issue.summary.toLowerCase()}} prevents casing mismatches in text comparisons.
.trim() : Strips leading and trailing whitespace characters.
.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 .
.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 .
.replaceAll(regex, replacement) : Performs global pattern replacement across the string.
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.