🚀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
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.
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.
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:
Create a transition (e.g., Any → Status) in your workflow.
Add a condition to the transition: Restrict from all users.
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.
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.
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.
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