7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling

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.

---

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)

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

1. Use the most specific trigger. A Field value changed trigger on one field fires far less often than a generic Issue updated trigger.
2. Put selective conditions first so rules stop early, although the trigger and conditions that run still count.
3. Scope JQL tightly in scheduled triggers and branches, so loops process fewer issues.
4. 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

1. SUCCESS: The trigger fired, all conditions evaluated to true, and all configured actions and branch operations completed without error.
2. 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.
3. 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.
4. 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.
5. 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

1. Identify the Rule Actor: Check Rule Details > Actor. By default, this is set to the system user Automation for Jira.
2. 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.
3. 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.
4. 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.