# Transition Work Items - Post Function

## 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 

<figure><img src="https://4067441311-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh6orV4J25NOSJvrMyLKk%2Fuploads%2FBM39US0TxVwSIYXCETxH%2Ftransition_pf_1_full.png?alt=media&#x26;token=fd9c1e37-9bf1-4590-aa9f-f744d3df7b26" alt="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."><figcaption><p>On transition to <em>Done</em>, automatically move all child issues to <em>Done</em> and set their resolution to match the parent.</p></figcaption></figure>

## 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.

<figure><img src="https://4067441311-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh6orV4J25NOSJvrMyLKk%2Fuploads%2FX0wjzY8bWLypPhl03UX6%2Ftransition-close_parent_when_last_item_closed.png?alt=media&#x26;token=f7cac24c-393b-4d87-905e-6c36fc14a954" alt="Screenshot showing the Siblings source selected in Preconditions to check the status of all sibling work items before closing the parent work item."><figcaption><p>Using the Siblings source in Preconditions to automatically close the parent work item when the last sub-task is closed.</p></figcaption></figure>

## 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.&#x20;

{% hint style="info" %}
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&#x20;*****Any*****&#x20;→ destination status** to make this possible without exposing it to users.
{% endhint %}

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.

<figure><img src="https://4067441311-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh6orV4J25NOSJvrMyLKk%2Fuploads%2FUBbaWqFZW5t9ZskVjFg5%2FOnly_api_transition.png?alt=media&#x26;token=07ab18ee-6fee-4624-9181-ae4fa47da7a3" alt="Workflow transition settings in Jira showing the condition “Restrict from all users” with the option “All users, but allow APIs” selected."><figcaption><p>Restricting a transition from all users while still allowing post functions and APIs to execute it.</p></figcaption></figure>

### **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.

{% hint style="info" %}
If you would like additional actor options, you can vote for this feature request: [More actor options for post functions](https://forgappify.canny.io/workflow-building-blocks/p/more-actor-options-for-post-functions)
{% endhint %}

### **Preconditions**

Preconditions control whether the post function runs.

* Configure preconditions using the **condition builder** known from the [**Ultimate Validator**](https://docs.forgappify.com/workflow-building-blocks-for-jira/conditions-validators/ultimate).
* The builder generates a Jira expression, evaluated as the selected **Actor**.
* The post function runs only if the precondition evaluates to `true`.

{% hint style="info" %}
**Note:** An expression may return different results for different users due to permissions. For example, users may see different comments on the same issue.
{% endhint %}

#### 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.