Workflow Post Functions
Post functions run automatically after a transition completes. They cannot block a transition — if a post function fails, the issue stays in its new status and the error is logged. Use them for automation: updating fields, creating related issues, sending alerts, and more.
How Post Functions Work
- A user (or automation) triggers a workflow transition
- Any Conditions are checked — if they fail, the transition is blocked
- Any Validators are checked — if they fail, the transition is blocked
- The issue moves to the new status
- Post Functions fire — they run asynchronously after the issue has moved
Because post functions are asynchronous, there may be a short delay (a few seconds) before their effects are visible on the issue.
Configuring a Post Function
- Go to Project Settings → Workflows and open a workflow
- Click on the transition you want to add the post function to
- Click Add perform actions rule (or click an existing rule to edit it)
- Select ScriptForge Post Function from the rule list
- Pick one of the 12 built-in actions below, or choose Run Script for custom logic
- Fill in the configuration fields and click Update
- Click Update workflow to save and publish the change
Built-in Actions Reference
1. Add / Remove from Sprint
What it does: Adds the issue to a sprint, or removes it from the current sprint, when the transition fires.
When to use it: Move items into an active sprint automatically when they are approved, or remove them when rejected.
Configuration:
| Field | Description |
|---|---|
| Action | Add or Remove |
| Board Name | Exact name of the Scrum board |
| Sprint Name | Optional — leave blank to use the active sprint |
Example: When a Bug moves to In Progress, add it to the active sprint on the Support Board.
2. Assign Work Item
What it does: Automatically assigns the issue to a user based on their project role or group membership.
When to use it: Assign issues to the QA lead when they move to Ready for Testing.
Configuration:
| Field | Description |
|---|---|
| Space Role | A project role name — assigns to the last user in that role |
| User Group | A Jira group name — assigns to the last active member |
Example: When a task moves to In Review, assign it to whoever holds the Reviewer project role.
3. Clone Work Item
What it does: Creates a copy of the current issue when the transition fires.
When to use it: Automatically create a follow-up task in another project when an issue is resolved.
Configuration:
| Field | Description |
|---|---|
| Target Project Key | Project key where the clone will be created. Leave blank for same project |
| Issue Type | Issue type for the clone. Leave blank to use the same type |
| Link Name | Link type between original and clone (e.g., Clones, Relates to) |
| Link Direction | Inward or Outward |
Example: When a Story moves to Done, clone it into the Archive project.
4. Create Subtask
What it does: Creates a new sub-task under the current issue when the transition fires.
When to use it: Automatically create a code review sub-task when a Story moves to In Progress.
Configuration:
| Field | Description |
|---|---|
| Sub-task Summary | The title for the new sub-task (required) |
| Issue Type | The sub-task issue type — select from the dropdown |
| Description | Optional description for the sub-task |
Example: When a Story moves to In Review, create a sub-task: "QA sign-off required".
5. Fast-track Transition
What it does: Immediately transitions the same issue to another status right after the current transition completes.
When to use it: Skip an intermediate status automatically, e.g., Resolved → auto-transition to Closed.
Configuration:
| Field | Description |
|---|---|
| Target Transition Name | The name of the next transition to fire |
| Target Transition ID | Numeric ID — more reliable than using the name |
| Comment | Optional comment added on the auto-transition |
Example: When a Bug is marked Won't Fix, automatically fast-track it to Closed.
6. Modify Work Item
What it does: Updates fields on the current issue after transition using a small script.
When to use it: Clear the assignee when moved to backlog, set a priority when escalated.
Configuration:
Use the Additional Code editor. Access issueInput.fields to set values:
// Set priority to High
issueInput.fields.priority = { name: 'High' };
// Add a label
issueInput.fields.labels = ['needs-review'];
// Set resolution
issueInput.fields.resolution = { name: 'Fixed' };
7. Run Script
What it does: Executes any JavaScript code you write, with full access to the Jira REST API. The most flexible option.
Available context variables:
| Variable | What it contains |
|---|---|
issue |
The current issue (key, summary, status, assignee, fields) |
transition |
The transition that just fired |
post, put, get |
Functions to call the Jira REST API |
logger |
Use logger.info(), logger.warn() for logs |
Example: Add a comment when an issue moves to Done:
await post('/rest/api/3/issue/' + issue.key + '/comment', {
body: {
type: 'doc',
version: 1,
content: [{
type: 'paragraph',
content: [{ type: 'text', text: 'Issue completed and ready for deployment.' }]
}]
}
});
8. Send Notification
What it does: Sends an email notification to selected recipients when the transition fires.
Configuration:
| Field | Description |
|---|---|
| Subject | Email subject line |
| Message Body | Email body text |
| Notify Recipients | Checkboxes: Reporter, Assignee, Watchers, Voters |
| Specific Users | Comma-separated Jira account IDs |
| Specific Groups | Comma-separated Jira group names |
Example: When a bug is marked Critical, notify the Reporter and all Watchers.
9. Transition Parent Work Item
What it does: When a sub-task is transitioned, automatically transitions its parent issue to a specified status.
When to use it: When a sub-task is marked Done, automatically move the parent Story to Done as well.
Configuration:
| Field | Description |
|---|---|
| Parent Transition Name | The transition name to fire on the parent (e.g., Done) |
| Transition ID | Optional numeric ID — more reliable than the name |
| Comment | Optional comment added to the parent issue |
Important: This action only works when the current issue is a sub-task with a parent. If the issue has no parent, it is skipped silently.
Example: Configure this on the Done transition of sub-tasks. When any sub-task completes, the parent Story automatically moves to Done.
10. Set Field Value
What it does: Sets one or more Jira fields to specific values when the transition fires. No scripting needed.
When to use it: Set a custom field when a status is reached, update priority on transition.
Configuration: Use the + Add another field button to configure multiple fields.
| Field | Description |
|---|---|
| Field | Select from all Jira fields (system + custom) |
| Value | Enter the value, or select from dropdown for option fields |
Value formats by field type:
| Field Type | Example Value |
|---|---|
| Labels | bugfix |
| Priority | High, Medium, Low |
| Assignee / Reporter | Jira account ID (or leave blank to unassign) |
| Components / Fix Versions | Component Name |
| Number field | 42 |
| Date field | 2025-12-31 |
| Description | Plain text (auto-converted to Jira format) |
Example: When a Bug moves to Done, set Priority to Low and add label resolved.
11. Copy Field from Parent
What it does: Copies a field value from the parent issue to the current child issue.
When to use it: Sync priority from a parent Epic down to a sub-task.
Configuration:
| Field | Description |
|---|---|
| Source Field | Field ID to read from the parent (e.g., priority, customfield_10001) |
| Target Field | Field to write on the child. Leave blank to use the same field |
Example: When a sub-task moves to In Progress, copy priority from the parent Story.
12. Copy Field to Parent
What it does: Copies a field value from the current child issue up to its parent.
When to use it: Roll up a label or fix version from a sub-task to the parent Story.
Configuration:
| Field | Description |
|---|---|
| Source Field | Field ID to read from the current issue |
| Target Field | Field to write on the parent. Leave blank to use the same field |
Example: When a sub-task is marked Done, copy its labels up to the parent Story.
Multiple Post Functions on One Transition
You can add multiple ScriptForge post functions to the same transition. They run in order — if one fails, the others still execute.
Execution History
All executions are recorded in the Activity Log (ScriptForge > Activity Log). Each entry shows:
- Which transition triggered the rule
- Which issue was involved
- Whether it succeeded or failed
- Full error message if it failed
- Execution duration
If a post function is not working, check the Activity Log first.