🚀Transition Work Items - Post Function

Automatically transition the current issue or related issues (parent, child, or linked) to the next available status in the workflow after a transition.

Overview

The Transition Work Items post function automates the progression of the current issue or related work items (parent, children, sub-tasks, or linked issues) by moving them to a chosen destination status automatically after a transition. It’s designed to keep related work in sync and enforce process consistency without scripts—ideal for cross-issue workflows like rolling releases, cascading approvals, or parent/child status alignment.

Key benefits:

  • Choose related items to operate on – Current work, Parent, Children, Sub-tasks, or Linked items.

  • Filter by issue type or link type – Narrow the operation to specific types or link relationships.

  • Choose a destination status – Automatically finds the available transition to the selected status in the workflow.

  • Conditional execution – Execute only when preconditions are met, defined through a visual, no-code interface.

  • Custom actor – Choose the user (actor) who performs the changes, useful when elevated permissions are required.

  • Set fields during the transition – Update fields as part of the transition to keep issue data consistent.

    • Copy values from the Parent or other fields

Transition Work Items Post Function configuration example: On transition to Done, automatically move all child issues to Done and set their resolution to match the parent.
On transition to Done, automatically move all child issues to Done and set their resolution to match the parent.

Use cases

Here are some common scenarios where this feature is useful:

  • Close children when the parent is closed Automatically transition all child work items when the parent work item is moved to Closed.

  • Keep parent in sync with children When a child work item is moved to In Progress, check if the parent is still open. If not, transition the parent to In Progress automatically.

  • Close Epic when the last child is closed Automatically transition the Epic to Closed when its final child work item is resolved.

  • Close parent when the last sub-task is closed Ensure the parent work item is closed automatically once all sub-tasks are resolved.

    • Use Preconditions to check if all other child work items under the same parent are already closed.

    • Select the Siblings source in Preconditions — this allows evaluating the status of all sibling work items.

    • If all siblings are closed, the parent work item is transitioned automatically.

Screenshot showing the Siblings source selected in Preconditions to check the status of all sibling work items before closing the parent work item.
Using the Siblings source in Preconditions to automatically close the parent work item when the last sub-task is closed.

Settings

Select work items to transition

Pick related items to transition:

  • Current work – Transition the work item that have just been transitioned the next selected status automatically.

  • Parent – Transition the parent issue to the next status.

  • Children – Transition direct child issues, including sub-tasks.

  • Sub-tasks – Transition issues at the lowest level in the hierarchy.

  • Linked work – Transition issues linked through relations such as blocks or relates to.

For Children, Sub-tasks, and Linked issues, you can narrow the scope by selecting specific issue types. For Linked issues, you can also filter by link type.

Choose destination status

The post function will search if selected status is reachable from the current status for each item. If there is no available transition between to statuses, it won't execute for that item.

A transition to a status is only possible if your workflow includes a direct transition between the two statuses. If no transition exists, post functions cannot move the issue there. Consider adding a restricted transition from Any → destination status to make this possible without exposing it to users.

If you want a post function to transition an issue to a status, but you don’t want users to do it manually, follow these steps:

  1. Create a transition (e.g., Any → Status) in your workflow.

  2. Add a condition to the transition: Restrict from all users.

  3. In the condition settings, select: All users, but allow APIs.

This ensures that the transition cannot be triggered by users, but can still be executed by post functions or other automation.

Workflow transition settings in Jira showing the condition “Restrict from all users” with the option “All users, but allow APIs” selected.
Restricting a transition from all users while still allowing post functions and APIs to execute it.

Actor

Defines who is recorded as having made the changes:

  • User who transitioned the issue (default)

  • Workflow Building Blocks for Jira (app actor)

The selected actor will appear in the issue’s change history.

  • User who transitioned the issue – Recommended for most cases; changes are attributed to the actual user.

  • Workflow Building Blocks for Jira – Has all permissions needed to evaluate preconditions and edit the issue. Recommended for complex scenarios where permission checks might prevent changes from being applied.

If you would like additional actor options, you can vote for this feature request: More actor options for post functions

Preconditions

Preconditions control whether the post function runs.

  • Configure preconditions using the condition builder known from the Ultimate Validator.

  • The builder generates a Jira expression, evaluated as the selected Actor.

  • The post function runs only if the precondition evaluates to true.

Note: An expression may return different results for different users due to permissions. For example, users may see different comments on the same issue.

Current User option in preconditions

Always represents the actual user who performed the transition, regardless of the Actor setting.

Permission Requirements

  • To see groups other users belong to: Administer Jira global permission is required.

  • To see roles of other users: Administer Projects permission for the project, or Administer Jira global permission is required.

Provide transition fields

This post function supports editing the following Jira fields:

Text & Selection Fields

All text fields, standard select lists (single and multi-select), radio buttons, checkboxes, URL fields, number fields

User & Group Fields

User picker, team picker, group picker

Issue Metadata

Issue type, priority, resolution, parent, labels, components, project picker

Time Tracking

Original estimate, remaining estimate

Versions & Dates

Version pickers, date fields

Agile

Sprint

Jira Service Management Fields

Request type, request participants, organisations

Understanding Post Functions in Jira

Order of Post Functions

Post functions perform additional processing after a workflow transition is executed.

When multiple post functions are added to the same transition, the execution order is not guaranteed.

Our post functions always operate on the current data at the time they run, including when evaluating preconditions. If multiple post functions modify the same fields and those fields are referenced in preconditions, the results may vary due to the asynchronous nature of post function execution.

Last updated