# Create Work Item - Post Function

## **Overview**

The **Create Work Item** post function allows you to automatically generate new work items during a workflow transition. It provides a powerful way to standardize processes, reduce repetitive manual work, and ensure that required follow-up items are always created—and correctly linked—at the right moment. With flexible value handling, hierarchy awareness, and no-code conditional logic, this post function adapts to simple and advanced workflow automation needs.

#### **Key Benefits:**

**Automate work creation** – Automatically create new work items when a transition occurs, ensuring consistent process execution without relying on users to manually generate follow-up tasks.

**Smart linking options** – Link the created work item to the trigger, its parent, or a chosen work item by key. Supports both hierarchy links and regular issue links for maximum flexibility.

**Flexible value handling** – Populate fields with static values or automatically copy values from the trigger work item, allowing you to create consistent, prefilled work items every time.

**Hierarchy support** – When creating parent–child relationships, copy field values from the parent work item, including support for up to two hierarchy levels above.

**Conditional execution** – Run the post function only when defined preconditions are met, using an intuitive, visual, no-code rule builder.

**Custom actor** – Choose which user performs the creation, enabling the action to run under elevated permissions when needed.

## Settings

### **Links**

The **Links** setting defines how the newly created work item will be connected to the triggering work item. The configuration uses two dropdowns:

**Link type** → **Link to**

This allows you to choose **what kind of relationship to create** and **which work item it should target**.

#### **1. Link type**

Choose the relationship you want to create for the newly created work item. The list is divided into two groups:

**Hierarchy**

Use this option when you want to place the new work item directly in the issue hierarchy.

* **Child of**\
  Makes the new work item a child of the selected target.\
  When selected, hierarchy features such as value copying from parent or grandparent become available.

**Link types**

These are standard Jira link types:

* **blocks**
* **is blocked by**
* **clones**
* **is cloned by**
* **duplicates**
* **is duplicated by**
* **relates to**
* plus any custom link types configured in your Jira instance.

#### **2. Link to**

Choose which work item the new item should be linked to:

* **Trigger work item**\
  The work item that executed the workflow transition.
* **Parent of trigger**\
  Useful when adding additional child items under the same parent hierarchy.
* **Select work item**\
  Allows manual selection of any work item.\
  When selected, a **Work Item Picker** appears where you can enter or search for the key.

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

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