Study guide
7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
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.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
Key Takeaways Explain This Topic AI
Rule scopes are single project, multiple projects, project type, or global; project admins manage single-project rules, and the other scopes need the Administer Jira permission.
Atlassian now meters automation in steps pooled across the organization; each trigger, condition, action, branch, and loop iteration is a step.
Jira step allowances are 150 per subscription on Free, 400 per user on Standard, 750 per user on Premium, and 1,000 per user on Enterprise; extra-usage billing starts 3 December 2026.
Runs that end in NO_ACTIONS_PERFORMED or NO_MATCH still use steps; only throttled runs with no executed step and system-side errors don't count.
The automation audit log shows each run's status; a FAILED permission error usually means the rule actor lacks a permission in the target project.
Last updated: September 2026
7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
Quick Summary: Governing Jira Cloud automation means understanding rule scopes (who can create which rules), usage (Atlassian now meters automation in steps pooled across the organization), and the audit log (how to read execution statuses and diagnose failures, especially rule-actor permission errors).
Automation Rule Scopes and Administrative Boundaries
When creating an automation rule, an administrator defines its Rule Scope in the Rule Details configuration panel. The scope determines which projects the rule evaluates, where it can be managed, and who possesses the authority to create, edit, or delete it. +-------------------------------------------------------------------------+
- | AUTOMATION RULE SCOPES |
- +-------------------------------------------------------------------------+
- | |
- | +-------------------------------------------------------------------+ |
- | | 1. SINGLE-PROJECT SCOPE | |
- | | Managed under: Project Settings > Automation | |
- | | Permission Required: 'Administer Projects' in target project | |
- | | Evaluates issues strictly within that single designated project| |
- | +-------------------------------------------------------------------+ |
- | |
- | +-------------------------------------------------------------------+ |
- | | 2. MULTI-PROJECT SCOPE | |
- | | Managed under: Jira Settings > System > Automation rules | |
- | | Permission Required: Global 'Administer Jira' permission | |
- | | Applies to an explicit list of 2 or more selected projects | |
- | +-------------------------------------------------------------------+ |
- | |
- | +-------------------------------------------------------------------+ |
- | | 3. GLOBAL (ALL PROJECTS) SCOPE | |
- | | Managed under: Jira Settings > System > Automation rules | |
- | | Permission Required: Global 'Administer Jira' permission | |
- | | Applies universally across all current and future projects | |
- | +-------------------------------------------------------------------+ |
- | |
- | +-------------------------------------------------------------------+ |
- | | 4. PROJECT TYPE SCOPE | |
- | | Managed under: Jira Settings > System > Automation rules | |
- | | Permission Required: Global 'Administer Jira' permission | |
- | | Applies to all Jira Software, Service Management, or Work Mgmt | |
- | +-------------------------------------------------------------------+ |
- +-------------------------------------------------------------------------+
- Delegated Administration vs. Global Governance
Project Administrator Autonomy: Jira Cloud empowers project administrators (users holding the Administer Projects project permission) to build and maintain Single-project automation rules directly inside their project. This eliminates administrative bottlenecks, allowing individual teams to automate issue triage, default values, and notifications without logging tickets for central Jira admins.
Global Administrative Control: Only users with the global Administer Jira permission can manage rules scoped to Multiple projects , Global (all projects) , or Project Type . Furthermore, if a single-project rule needs to be converted into a multi-project rule to standardize workflows across three engineering projects, a Jira Administrator must perform the scope change in Jira Settings.
- Scope Level Configuration UI Path Minimum Required Permission Projects Evaluated
- Single-project Project Settings > Automation Administer Projects (Project Admin) One designated project only
Multi-project Jira Settings > System > Automation rules Administer Jira (Jira Admin) Explicit list of 2+ projects
Global Jira Settings > System > Automation rules Administer Jira (Jira Admin) All projects across the site
Project Type Jira Settings > System > Automation rules Administer Jira (Jira Admin) All Software, JSM, or Business projects
Automation Usage: Steps Pooled Across the Organization
Automation usage has changed several times, so older prep material often quotes figures that no longer apply. Atlassian's current documentation says automation has moved from per-app monthly rule-run limits to usage-based automation steps pooled at the organization level . Extra-usage billing takes effect on 3 December 2026 .
What Counts as a Step
A step is one executed component of a rule:
- the trigger (the event that starts the rule);
- each condition that runs;
- each action ;
- each branch (if/else path); and
each loop iteration (for each).
A step is charged when its result is SUCCESS , NO_ACTIONS_PERFORMED , SOME_ERRORS , ABORTED , or NO_MATCH . Even a trigger that finds nothing to act on counts as one step. THROTTLED runs where no step executes, system-side errors, and components Atlassian runs on your behalf don't count.
Monthly Step Allowances (Jira)
- Jira Plan Automation Steps per Month
- Free 150 per subscription
- Standard 400 per user
- Premium 750 per user
- Enterprise 1,000 per user
Allowances from every app in the organization are added together into one pool . For example, 100 Jira Premium users (100 × 750 = 75,000) plus 100 Confluence Standard users (100 × 100 = 10,000) gives 85,000 steps shared by both apps.
Monitoring and Overages
Where to look: Organization admins track usage in Atlassian Administration > Insights > Platform usage .
Warnings: Organization and billing admins are notified at 80% and 100% of the allowance.
With extra usage enabled: rules keep running, and extra steps are billed ($0.50 per 1,000 additional steps).
With extra usage disabled: at 100% of the allowance, rules stop running until usage resets.
Designing Rules That Use Fewer Steps
Use the most specific trigger. A Field value changed trigger on one field fires far less often than a generic Issue updated trigger.
Put selective conditions first so rules stop early, although the trigger and conditions that run still count.
Scope JQL tightly in scheduled triggers and branches, so loops process fewer issues.
Avoid chains of rules triggering rules unless you need them, because every hop adds steps.
The Automation Audit Log & Diagnostics
The Audit Log is the primary troubleshooting and forensic interface for Jira Cloud Automation. It is accessible per-rule (via the Audit log tab in the rule editor) and globally across all rules (under Jira Settings > System > Automation rules > Audit log ). +-------------------------------------------------------------------------+
- | AUTOMATION AUDIT LOG VIEW |
- +-------------------------------------------------------------------------+
- | Date / Time | Rule Name | Status | Duration |
- | ------------------- | -------------------- | ------------ | ----------- |
- | 2026-09-26 10:14:02 | Auto-Assign P1 Bugs | SUCCESS | 342 ms |
- | 2026-09-26 10:12:18 | Close Stale Epics | NO ACTIONS | 45 ms |
- | 2026-09-26 10:08:55 | Sync Customer Portal | SOME ERRORS | 812 ms |
- | 2026-09-26 09:55:01 | Git Webhook Sync | FAILED | 120 ms |
- | 2026-09-26 09:40:12 | High Volume Poller | THROTTLED | -- |
- +-------------------------------------------------------------------------+
- Audit Log Execution Statuses
SUCCESS : The trigger fired, all conditions evaluated to true, and all configured actions and branch operations completed without error.
NO ACTIONS PERFORMED : The trigger fired, but a condition early in the rule evaluated to false, or a scheduled JQL search returned zero issues. The rule stopped safely, but the steps that ran still count toward usage.
SOME ERRORS : Typically occurs in branched rules. For example, a rule branches to update 5 linked issues; 4 update successfully, but 1 fails due to a missing mandatory field. The parent rule completes with partial success.
FAILED : A fatal execution error occurred. Common causes include:
Syntax errors in smart value expressions.
Rule Actor missing required project permissions (e.g., trying to assign an unassignable issue).
Workflow transition screen enforcing a mandatory field that the rule did not supply.
External webhook destination returning HTTP 4xx or 5xx errors.
THROTTLED : The rule hit automation service limits (for example, triggering far too often in a loop), so Atlassian paused it. Throttled runs where no step executed don't count toward usage.
Diagnostic Tools: The "Log action"
When debugging complex smart value manipulations or regular expression parsing, administrators should utilize the Log action component. The Log action evaluates any string or smart value expression and writes the output directly to the rule's audit log entry without modifying any issue data: # Log action expression:
Debug Info: Assignee is {{issue.assignee.displayName}}, Days Open is {{issue.created.diff(now).days}}
# Audit Log Result:
- Debug Info: Assignee is Sarah Jenkins, Days Open is 14
- Rule Actor Permission Troubleshooting
A high-frequency troubleshooting scenario on the ACP-120 exam involves automation rules that fail with permission errors. When inspecting the audit log, the administrator sees: Failed to transition issue: The user does not have permission to transition this issue.
Root Cause Analysis & Resolution Steps
Identify the Rule Actor: Check Rule Details > Actor . By default, this is set to the system user Automation for Jira .
Inspect Permission Schemes: Navigate to Project Settings > Permissions in the target project. Verify whether Automation for Jira has the required permission (e.g., Transition Issues , Assign Issues , Modify Reporter ). In Jira Cloud, the Automation for Jira user is typically a member of the default atlassian-addons-project-access project role. If a project admin customizes the permission scheme and removes this role from the Transition Issues permission, all automation rules in that project attempting to transition issues will immediately fail.
Inspect Issue Security Schemes: If the issue has an Issue Security Level applied, verify that the Rule Actor is a member of a group or role granted access in the Issue Security Scheme . If the rule actor cannot view the issue, the rule cannot execute actions against it.
Inspect Workflow Validators: If a workflow transition has a permission validator or field-required validator, ensure the rule actor satisfies the validator criteria during transition execution.