Study guide
8.1 Jira Events, System Events & Notification Schemes
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
8.1 Jira Events, System Events & Notification Schemes
Key Takeaways Explain This Topic AI
Jira fires events for issue activity, and a company-managed project's notification scheme maps each event to recipients.
System events can't be added or deleted (only made inactive); custom events are created by Jira admins and fired only by workflow transitions.
Only inactive custom events can be deleted; an event is active while any notification scheme or workflow post function uses it.
New transitions fire the Generic Event by default, so map Generic Event (or a custom event) to recipients if a transition should send email.
Team-managed projects don't use notification schemes; project admins set notifications per project from a fixed list of events.
Last updated: September 2026
8.1 Jira Events, System Events & Notification Schemes
Quick Summary: In Jira Cloud, notifications are powered by an event-driven subsystem. Whenever a user creates an issue, edits a field, adds a comment, or executes a workflow transition, Jira fires an Event . A project's Notification Scheme intercepts these events and routes email alerts to configured recipient types. Understanding the distinction between built-in system events and custom events, the mechanics of workflow post functions, and scheme association is essential for enterprise Jira administration.
Jira Cloud Event-Driven Notification Architecture
Atlassian Cloud utilizes an asynchronous event bus to handle system and issue lifecycle changes. When a state change occurs in Jira, the application does not directly dispatch an email to hardcoded users. Instead, it publishes an event record containing the issue context, the initiating actor, and the updated field metadata.
The notification lifecycle follows four sequential stages:
Event Trigger: An action occurs via the web interface, mobile app, REST API, or workflow transition (e.g., a developer transitions an issue to In Review ).
Event Bus Publication: Jira publishes a specific event (such as Issue Updated or a custom Ready for Code Review event).
Notification Scheme Evaluation: Jira consults the Notification Scheme associated with the issue's project, identifying all recipient types subscribed to that event.
Security & Deduplication Pipeline: Jira checks issue-level security and project browse permissions, filters out unauthorized accounts, resolves deduplicated recipient sets, and submits outgoing messages to the email batching queue. +-------------------------------------------------------------------------+
- | JIRA EVENT & NOTIFICATION PIPELINE |
- +-------------------------------------------------------------------------+
- | |
- | [ User Action / Workflow Transition ] |
- | | |
- | v |
- | [ Jira Event Bus: Fired Event (System or Custom) ] |
- | | |
- | v |
- | [ Project Notification Scheme Lookup ] |
- | - Maps Event -> Recipient Definitions (Assignee, Roles, Groups) |
- | | |
- | v |
- | [ Access & Permission Filtering ] |
- | - Verify 'Browse Projects' Permission |
- | - Verify Issue Security Level Containment |
- | | |
- | v |
- | [ Deduplication & Batching Engine ] |
- | - Deduplicate overlapping recipient criteria |
- | - Batch updates (3-min idle, 10-min max; mentions go now) |
- | | |
- | v |
- | [ Outgoing Mail Service (Atlassian SMTP / Custom SPF & DKIM) ] |
- +-------------------------------------------------------------------------+
- System Events in Jira Cloud
Jira Cloud ships with a fixed set of system events . Atlassian's rules for them: system events can't be added or deleted , but they can be made inactive (an event is active when a notification scheme or a workflow post function uses it). The built-in system events are:
- System Event What Fires It Default Notification Scheme Recipients
- Issue Created Creating an issue (the create transition fires it) Current assignee, reporter, all watchers
- Issue Updated Editing issue details Current assignee, reporter, all watchers
- Issue Assigned Assigning the issue to a new user Current assignee, reporter, all watchers
- Issue Resolved A workflow transition configured to fire it Current assignee, reporter, all watchers
Issue Closed A workflow transition configured to fire it (an issue can be closed without being resolved) Current assignee, reporter, all watchers
- Issue Commented Adding a comment Current assignee, reporter, all watchers
- Issue Comment Edited Editing a comment Current assignee, reporter, all watchers
- Issue Reopened A reopen transition configured to fire it Current assignee, reporter, all watchers
- Issue Deleted Deleting an issue Current assignee, reporter, all watchers
- Issue Moved Moving an issue into the project Current assignee, reporter, all watchers
- Work Logged On Issue Adding a worklog Current assignee, reporter, all watchers
Work Started On Issue / Work Stopped On Issue Start and stop progress transitions Current assignee, reporter, all watchers
Issue Worklog Updated / Issue Worklog Deleted Editing or deleting a worklog Current assignee, reporter, all watchers
Generic Event Any transition that isn't set to fire a more specific event Current assignee, reporter, all watchers
Some events are fired by Jira internally (Issue Updated, Issue Moved). Others, such as Issue Resolved or a custom event, are fired only because a workflow transition is configured to fire them.
The Role of the Generic Event
When an administrator creates a new workflow transition, Jira sets it to fire the Generic Event by default. If the administrator does not explicitly change this to a specific event (or a custom event), any notification sent as a result of that transition will use the Generic Event mapping in the project's Notification Scheme. If the Generic Event has no recipients configured in the Notification Scheme, no email will be sent.
Custom Events: Purpose, Creation & Lifecycle
While system events cover standard CRUD operations, complex business processes require targeted notifications for specific workflow milestones—such as Escalated to Tier 3 , Awaiting Legal Approval , or QA Build Ready . This is achieved through Custom Events .
Creating a Custom Event in Jira Cloud
Custom events are defined globally across the Jira Cloud site:
Go to Settings > System , then Advanced > Events .
Scroll to the Add New Event form at the bottom of the page.
Enter the required parameters:
Name: A descriptive label (e.g., Issue Escalated to Executive Team ).
Description: Context detailing when and where this event is fired.
Template: The email template the event uses. Atlassian's custom-event procedure uses the Generic event template, which looks much like the Issue Updated email.
Click Add . The new event starts out inactive , because no notification scheme or workflow uses it yet. +-------------------------------------------------------------------------+
- | ADD NEW EVENT INTERFACE |
- +-------------------------------------------------------------------------+
- | Name: [ Issue Escalated to Executive Team ] |
- | Description: [ Fired when an incident transitions to Sev-1 Escalated] |
- | Template: [ Issue Updated v ] |
- | | Issue Created | |
- | | Issue Updated | |
- | | Issue Commented | |
- | | Generic Event | |
- | +----------------------------------------------------+ |
- | |
- | [ Add Event ] |
- +-------------------------------------------------------------------------+
- Event Templates Explained
Every custom event must be linked to an underlying system event template. In Jira Cloud, the template controls the visual presentation and subject formatting of outgoing emails:
Issue Created Template: Formats the email as a newly spawned item, emphasizing creation metadata, project key, and initial description.
Issue Updated Template: Highlights field-level diffs, changes between previous and new values, and status movements.
Generic Event Template: Provides a standard, neutral notification envelope displaying issue attributes and comments.
Custom Event Deletion Rules & Constraints
An event is active when it's associated with at least one notification scheme or workflow post function , and inactive otherwise. Only inactive custom events can be deleted. To retire a custom event:
Remove it from every workflow transition that fires it (change those transitions back to the Generic Event or another event), and update the workflows.
Remove its entries from every notification scheme that references it.
Return to Settings > System > Advanced > Events . Once the event shows as inactive, delete it.
System events can never be deleted, although they can be inactive. Also remember that an active status doesn't mean an event will fire. A custom event fires only when a transition in an active workflow is configured to fire it.
Firing Events from Workflow Transitions
Custom events can't be fired from ordinary edit or assign actions. They're fired by workflow transitions in company-managed projects. Atlassian's procedure has three parts:
Add the custom event (Settings > System > Advanced > Events).
Map recipients in the notification scheme: open the scheme (Settings > Issues > Notification schemes), find the custom event at the bottom of the list, and add recipients.
Configure the transition to fire it: edit the workflow, select the transition, and choose the custom event in the transition's Event setting (in the legacy editor, edit the "Fire a … event" post function). Select Update workflow to publish. Every project that uses the workflow now sends the email on that transition. +-------------------------------------------------------------------------+
- | WORKFLOW TRANSITION POST FUNCTION CONFIGURATION |
- +-------------------------------------------------------------------------+
- | Transition: Escalate (from [In Progress] to [Escalated]) |
- | |
- | Standard Post Functions Execution Sequence: |
- | 1. Set issue status to the linked status of destination node. |
- | 2. Update Issue Field: Priority = Critical. |
- | 3. Update Issue Field: Escalation Date = now. |
- | 4. Update change history and store the issue. |
- | 5. Fire an event that can be processed by the listeners: |
- | --> [ Issue Escalated to Executive Team ] |
- +-------------------------------------------------------------------------+
- The Critical Importance of Post Function Execution Order
A frequent source of exam scenario questions involves the execution sequence of workflow transition post functions. In Jira workflows, post functions execute sequentially from top to bottom:
Exam Trap — Stale Notification Data: In an ordered post-function list, if Fire an event that can be processed by the listeners is positioned before an Update Issue Field post function (or before setting the Resolution field), the notification listener processes the issue in its pre-update state. Recipient emails will display the old field values or omit the newly assigned resolution. To ensure outgoing emails reflect accurate, committed data, the event-firing post function should always be placed at or near the very end of the post function execution chain, immediately following the step that stores the issue revision to the database.
Notification Schemes in Company-Managed Projects
A Notification Scheme is a centralized, reusable administrative scheme that dictates which individuals, groups, or roles receive email notifications when specific events fire within Company-Managed Projects (CMP).
Navigating and Structuring Notification Schemes
Administrators manage notification schemes via Cog > Jira settings > Issues > Notification schemes .
Each scheme contains an itemized table listing all active events (System Events and site-wide Custom Events).
For each event, administrators define one or more Notification Types / Recipients (such as Current Assignee, Reporter, Project Lead, Project Role, or User Custom Field Value).
A single event can have multiple recipient rules attached. For example, the Issue Created event might be mapped to Current Assignee , Project Role (Developers) , and User Custom Field Value (QA Lead) . +-------------------------------------------------------------------------+
- | NOTIFICATION SCHEME CONFIGURATION MATRIX |
- +-------------------------------------------------------------------------+
- | Event Name | Notified Recipients |
- | :-------------------- | :---------------------------------------------- |
- | Issue Created | Current Assignee, Reporter, Project Lead |
- | Issue Updated | Current Assignee, Reporter, All Watchers |
- | Issue Assigned | Current Assignee |
- | Issue Resolved | Reporter, All Watchers |
- | Generic Event | Project Role (Stakeholders) |
- | Incident Escalated | Project Role (Incident Commanders), |
- | (Custom Event) | User Custom Field Value (Executive Sponsor) |
- +-------------------------------------------------------------------------+
- The Default Notification Scheme
Jira Cloud provides a system-generated Default Notification Scheme with every new instance:
When a new company-managed project is created, Jira automatically associates it with the Default Notification Scheme unless a project template specifies a different scheme.
In the Default Notification Scheme, standard events ( Issue Created , Issue Updated , Issue Assigned , Issue Commented , etc.) are mapped to Current Assignee , Reporter , and All Watchers .
Editing the Default Notification Scheme alters notification behavior across all projects that remain linked to it.
Associating a Scheme with a Project
To change or assign a notification scheme for a company-managed project (select None to stop the project sending scheme-based emails):
Open the target project and select Project settings from the left-hand sidebar.
Navigate to Notifications .
In the top-right corner, open the Actions dropdown menu and select Use a different scheme .
Select the desired scheme from the list of available notification schemes.
- Click Associate . +-------------------------------------------------------------------------+
- | ASSOCIATING NOTIFICATION SCHEME TO PROJECT |
- +-------------------------------------------------------------------------+
- | Project Settings > Notifications > Actions > Use a different scheme |
- | |
- | Available Schemes: |
- | ( ) Default Notification Scheme (Associated with 14 projects) |
- | (o) High-Security Incident Notification Scheme (Associated with 2 proj)|
- | ( ) Software Development Notification Scheme (Associated with 8 proj) |
- | |
- | [ Associate ] [ Cancel ] |
- +-------------------------------------------------------------------------+
- Modifying Shared Notification Schemes: Governance Best Practice
In enterprise environments, multiple projects frequently share a single Notification Scheme. A common administrative error occurs when a Project Administrator requests a change—for example, removing All Watchers from the Issue Updated event to decrease email noise:
If a Jira Administrator navigates to Issues > Notification schemes and removes All Watchers directly from that shared scheme, the change instantly applies to every single project linked to that scheme .
Recommended Administrative Workflow:
Check how many projects are associated with the target scheme.
If the scheme is shared and only one project requires customized routing, click Copy next to the scheme in the global Notification Schemes repository.
Rename the copy (e.g., Core Banking Project Notification Scheme ).
Edit the event-recipient mappings in the newly created scheme.
Navigate to the requesting project's Project settings > Notifications , select Actions > Use a different scheme , and switch the project to the new scheme.
This isolates the change without disrupting other organizational teams.
Company-Managed vs. Team-Managed Notification Architecture
A clear distinction exists between project types in Jira Cloud:
Architectural Attribute Company-Managed Projects (CMP) Team-Managed Projects (TMP)
Configuration Model Reusable global schemes managed by Jira Administrators Localized settings managed by Project Administrators
Scheme Support Full support for shared Notification Schemes No global Notification Schemes ; completely isolated
Custom Events Supported (fired from workflow transitions) Not available; you choose from a fixed list of issue events
Recipient Options 11 recipient types, including project roles, groups, and user or group custom fields All watchers, current assignee, current user, reporter, project lead, or a project role
Who Configures Jira admin (scheme is shared across projects) Project admin (Administer Projects), for that project only
In team-managed projects, notifications are set per project in Project settings > Notifications . A notification scheme can't be applied to a team-managed project. Section 8.3 covers team-managed notifications in detail.