6.3 Post Functions, Execution Order & Resolution Management

6.3 Post Functions, Execution Order & Resolution Management

Quick Summary: In Jira Cloud workflows, Post Functions carry out automated backstage operations immediately after a transition's conditions and validators have succeeded. They perform automated field updates, assign issues, write change history, and dispatch system events. Understanding the strict execution order of post functions is critical: moving an event ahead of a field update causes notifications to broadcast stale data. Furthermore, proper management of the Resolution system field is paramount. Jira determines issue completion exclusively through the Resolution field, not status names. Omitting resolution management corrupts agile burndowns, velocity metrics, and service level agreements (SLAs).

---

Post Functions Architecture

A Post Function is an automated backstage action executed by the Jira workflow engine during the final phase of a transition transaction. Unlike conditions (which hide buttons) or validators (which reject submissions), post functions always execute when a transition is successfully committed to the database.

Built-in Standard Post Functions in Jira Cloud

Every transition carries essential system post functions that Jira adds automatically. In the legacy editor's post-function list they appear as:

1. Set issue status to the linked status of the destination step.
2. Add a comment to the issue if one was entered during the transition.
3. Update change history for an issue and store the issue in the database.
4. Re-index the issue so search results stay in sync.
5. Fire an event (for example, Generic Event or Issue Resolved) that notification schemes and other listeners process.

The create transition also includes Create the issue originally. The current workflow editor manages these system steps for you. You choose the transition's event in the transition details, and add your own actions under Perform actions.

Administrators can add further actions (classic names in brackets):

• Update a work item's field [Update Issue Field, Clear Field Value]: set a field to a value (for example, Resolution = Fixed) or clear it (for example, clear Resolution when reopening).
• Assign a work item [Assign to Current User / Reporter / Lead Developer].
• Copy the value of one field to another [Copy Value From Other Field].
• Set a work item's security level [Set issue security level based on user's project role].
• Trigger a webhook.

---

Post Function Execution Order and Critical Sequence Rules

In workflows maintained with the legacy editor's ordered post-function list, post functions run top to bottom, and their order affects data integrity, notification accuracy, and integrations. The same principle explains stale-data symptoms in any workflow: the event must fire after the fields it reports have been set.

+-------------------------------------------------------------------------+
|                POST FUNCTION EXECUTION LIFECYCLE ORDER                  |
+-------------------------------------------------------------------------+
| Step 1: Set issue status to the linked status                           |
| Step 2: Custom Post Function: Update Field (e.g., Resolution = 'Fixed') |
| Step 3: Custom Post Function: Set 'Actual Resolution Date' = now()      |
| Step 4: Update issue details & Store issue on database                  |
| Step 5: Generate change history for issue and re-index                  |
| Step 6: Fire an event that can be processed by listeners (LAST!)        |
+-------------------------------------------------------------------------+

The "Fire Event Last" Cardinal Rule

The built-in post function "Fire an event that can be processed by the listeners" (e.g., firing Issue Resolved or Issue Updated) must almost always remain the final post function in the execution list.

What happens if you move "Fire an Event" above a field update?

1. The transition begins.
2. Jira fires the Issue Resolved event.
3. The Notification Scheme intercepts the event and immediately generates notification emails to stakeholders.
4. Jira executes webhooks and automation rules listening for Issue Resolved.
5. After the emails and webhooks have been dispatched, Jira executes the subsequent post function that sets Resolution = Fixed and Actual End Date = 2026-09-26.
6. The Consequence: Notification emails display Resolution: Unresolved and a blank end date. Automation rules evaluating {{issue.resolution.name}} fail because the field was empty at the exact millisecond the event fired.

The "Store Issue" Sequence Rule

Any custom post function that modifies an issue field must be placed before the "Update issue details / Store issue" and "Generate change history and re-index" post functions. If a post function updates a field value after the issue has already been stored and re-indexed, the new value may reside only in volatile memory, failing to persist to the database or register in JQL search indexes until a subsequent edit occurs.

---

Resolution Management: The Single Source of Truth

One of the most heavily tested concepts on the ACP-120 exam is the behavioral difference between Status and Resolution.

[!IMPORTANT] Jira treats any issue with a value in Resolution as resolved and any issue without one as unresolved, whatever its status is called. Atlassian lists what depends on it:

• strikethrough of resolved issue keys on boards and timelines;
• the Created vs. Resolved report and other resolved-series reports;
• system filters such as Open work items (issues without a resolution);
• the Resolved date, which Jira sets when Resolution goes from empty to a value;
• the "unresolved issues" prompt when you release a version.

Scrum sprint completion is different. Burndown, velocity, and the Complete sprint dialog count an issue as done when it's in the board's rightmost column, not because it has a resolution.

+-------------------------------------------------------------------------+
|               STATUS VS. RESOLUTION ARCHITECTURAL REALITY               |
+-------------------------------------------------------------------------+
| Field       | Purpose                               | Visual Representation     |
+-------------+---------------------------------------+---------------------------+
| Status      | Indicates where an issue sits in its  | Lozenge badge             |
|             | operational lifecycle (To Do / In     | (e.g., 'Done', 'Resolved',|
|             | Progress / Done).                     | 'In Development')         |
+-------------+---------------------------------------+---------------------------+
| Resolution  | Explains HOW and WHY an issue was     | Strikethrough text on     |
|             | concluded (Fixed, Won't Do, Duplicate,| issue key:                |
|             | Done, Incomplete).                    | ~~PROJ-1234~~             |
+-------------------------------------------------------------------------+

Setting Resolution on "Done" Transitions

Every workflow transition leading into a status belonging to the Done status category must explicitly populate the Resolution field. There are two approved architectural patterns:

1. Via Transition Screen (User Choice): Associate the transition with a Transition Screen that includes the Resolution field. When the user clicks Resolve or Close, the popup dialog forces them to select an appropriate resolution reason (such as Done, Fixed, Duplicate, or Cannot Reproduce).
2. Via Automated Post Function (Zero-Click): If the workflow requires a streamlined, single-click completion without prompting the user, add an Update Issue Field Post Function on the transition that automatically sets Resolution = Done.

Mandatory Clearing of Resolution on "Reopen" Transitions

Whenever an issue moves from a Done status back into an active status (such as To Do or In Progress via a Reopen, Reject, or Rework transition), the administrator must configure a post function that explicitly clears the Resolution field (Update Issue Field: Resolution = None).

If the administrator omits this post function, the issue returns to an active status while retaining its historical resolution value, creating severe data corruption.

---

The Operational Disasters of Mismanaged Resolutions

Diagnosing Resolution Issues via JQL

Administrators can immediately identify resolution discrepancies across their instance using two targeted diagnostic JQL queries:

• Find closed issues with missing resolutions: statusCategory = Done AND resolution is EMPTY
• Find active issues with lingering resolutions: statusCategory != Done AND resolution is not EMPTY

If either query returns results, the underlying workflow transitions suffer from missing resolution post functions.