Issue Summary

Customers reported that conditional post function weren’t executing correctly after making changes to a workflow in the new workflow editor. When looking into the old editor they noticed that there had been a change in the order, where these app functions were placed in front of the default system functions. Customers re-ordered these transitions to place them at the end and they observed that they starting working.

The root of this is that work item data in Jira Cloud is eventually consistent. Immediately after a write (like a transition), an immediate read may return an old value for a short time. Apps often do this to fetch information needed to make decisions or perform updates. As such if they pick up old data they might not execute as intended.

Placing an app post function after built-in system functions can sometimes add a small delay, which makes a successful read-after-write more likely. While this can look like the order is the fix, it only changes timing—it is not a guarantee.

Steps to Reproduce

1. Create a workflow transition that shows a transition screen with a field the user can set (e.g., Priority or Resolution).

1. On that transition, configure post functions in this order in the classic editor:

Post function 1: Fire Issue Resolved

Post function 2: JMWE conditional action that only runs if the field set on the transition screen meets a condition (e.g., Priority = High or Resolution = Done).

Post function 3: Another JMWE action (optional).

1. Publish the workflow and execute the transition, setting the field on the transition screen (e.g., set Priority = High).

1. Observe that the JMWE conditional post function immediately reads the issue via REST after the transition event is fired.

1. Because issue updates are eventually consistent, the REST read can return the pre-transition value of the field (stale), causing the condition to evaluate incorrectly (Note this can be difficult to reproduce because other factors like, load, contention and even how long it takes for the post functions themselves to trigger).

1. Reorder or republish the workflow in the new editor and repeat. Timing shifts can change whether the conditional function sees the updated field value, making it appear that function order is the cause.

Expected Results

• The conditional JMWE function evaluates against the actual, most recent field value set on the transition screen (e.g., Priority = High), not a stale value.

Actual Results

• Immediately after the transition, the JMWE function REST-reads the issue and can receive the pre-transition field value, so the condition may evaluate as false when it should be true (or vice versa).

• Apparent differences in behavior after reordering/publishing are due to timing/read-after-write consistency, not a strict guarantee of post function order for third-party app execution.

Workaround

If possible, add a short delay in the app function before evaluating the condition using feature of the application, or design the workflow functions to avoid depending on immediate read-after-write of fields. 

Also consider that other applications, automations, and users/processes may update or transition the same issue concurrently. Design workflows and app logic to be resilient to concurrent updates (e.g., idempotent operations, retries, and re-checking state before acting).