All Usage Examples provided by Jira Workflow Toolbox for Jira Cloud
| Use case | Type | Function | Use case description | Complexity |
|---|---|---|---|---|
| Add a comment with links to attachments that were just added | A comment will be added to the current issue with links to the attachments included recently. | BEGINNER | ||
| Add a sub-task's summary and key to the description of its parent | When a sub-task is created, its summary, issue key and date, and time of creation will be added to the description of the parent issue. | BEGINNER | ||
| Add comment when rejecting an issue | When an issue is rejected, a comment will be added to the current issue mentioning the reporter. | BEGINNER | ||
| Add formatted comments automatically | Add a formatted comment to the current issue. It would be convenient in case that you need to create a table or highlight some important points in the comment. | BEGINNER | ||
| Add three days skipping weekends automatically to a Date Picker | Add three days to a Date Picker field from the current date. | BEGINNER | ||
| Add watchers from another field | ||||
| Alert the assignee of an important issue | Send an email to the current assignee only if the priority is set to "Highest" or "High". | BEGINNER | ||
| Alert the assignee of important issues | Add a comment to an issue mentioning the assignee. The comment will only be added, if the issue priority is set to "High" or "Highest" to ensure that the assignee will only be alerted for the important issue | BEGINNER | ||
| Alert the reporter | Add a simple comment to an issue mentioning the reporter. This use case might come in handy if you don't want to use extra events in your notification schemes to notify specific users - like the reporter. | BEGINNER | ||
| Assign an issue to the project lead, if the issue is unassigned on creation | When an issue is created without an assignee selected, the issue will be assigned to the project lead of the project. | BEGINNER | ||
| Assign an issue to the user who last commented on it | Assign the issue to the user who last commented on the issue. | BEGINNER | ||
| Assign important issues to the project lead | Automatically assign and issue to the project lead. Issues will only be re-assigned if the priority of the issue is set to Highest to make sure that only important issues are being escalated. | BEGINNER | ||
| Automatically create a version when starting the release | ||||
| Automatically link an issue to an external one | ||||
| Automatically log work on a Jira issue | ||||
| Auto-transition when related issues are in a specific status | Automatically transition issue, if all linked issues are in specific status. | INTERMEDIATE | ||
| Block a transition based on issue links | Evaluate issue links and hide transitions based on the outcome. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. | ADVANCED | ||
| Block a transition based on sprint information | Make sure that an issue is not in an active sprint. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
| Block a transition based on the day of the week | Block transitions on weekends or any other day of the week. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
| Block a transition if a predefined field value has not been changed | Evaluate a Date Picker field and block the transition if it has not been updated. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
| Block a transition if some issues under an epic are not in a certain status | Check whether an epic has all issues under it in a certain status. This is particularly important if you want to block an epic as long as work is still being done on related sub-tasks. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | INTERMEDIATE | ||
| Block a transition if the type of the attached files is incorrect | Evaluate the type of files in the Attachments field. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. | INTERMEDIATE | ||
| Check current issue status | Check whether the current issue is in a particular status. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
| Check for at least one component | Require a at least one component. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
| Check for unresolved sub-tasks | Check whether the current issue has any unresolved sub-tasks. This is particularly important if you want to block a parent issue as long as work is still being done on related sub-tasks. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | INTERMEDIATE | ||
| Check if an attachment was added recently | Make sure that the current user has uploaded a attachment during a definite period of time. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
| Check parent issue type | Check whether the parent of the current issue is of a certain issue type. This is particularly important if you want to reuse a workflow for multiple sub-task issue types but only want a transition to be available if the sub-task belongs to a certain user story or a bug. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | INTERMEDIATE | ||
| Check the number of times that a field has changed | Check the number of times that a field has changed. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | INTERMEDIATE | ||
| Copy field values from epic to issues under it after creation | Copy the values of the fields defined in the Update fields post-function to the issues under the epic after their creation. | BEGINNER | ||
| Copy labels of a sub-task to the parent issue upon closing | When a sub-task is closed, the labels of the sub-task will be added to the Labels field of the parent issue. | BEGINNER |
Liste möglicher Use cases:
| Aktuell umsetzbar | perspektivisch  |
|---|---|
| Clear the Fix Version/s field on the reopening of a ticket. - Update fields | On the creation of a Bug assign it to a user only if he is a Product Owner (project role) - Update fields |
A customer using Jira Service Desk should be notified via a comment when someone has started working on their support request. - Add comment | Assign an issue to a member of Support - UTC project role only when the reporter time zone is UTC. - Update fields |
| Add a comment on the Epic when its user stories are resolved. - Add comment | Assign an issue to a member of the QA team (project role) when the issue is transitioned to Ready for testing status - Update fields |
| On the approval of a Story, create two sub-tasks: one for Development and another for QA. - 2x Create issue | When a tester reopens an issue assign the issue to a Developer who last worked on it. - Update fields |
| Copy the labels from each sub-task to its parent when the sub-task is closed. - Update fields in Sub-task WF | After testers have validated an issue, it should be assigned to the last product owner who worked on it for the functional validation. The product owner might either have been explicitly assigned to the issue before, to write the functional specification or have written the specification while creating the issue. - Update fields |
| Issues in our project are fixed in the version they are found . So I want to copy the Affect versions of the issue to the Fix Versions, on resolving the issue. - Update fields | Clear a set of fields on all the linked issues of the current issue when an Abort is triggered on the current issue - Update fields |
| Copy value from a Single Version Picker select list to the Fix Version(s) field if the resolution provided while closing the issue is "Fixed". - Update fields (oder perspektivisch weil offiziell noch keine Custom fields lesend supported ) | On resolving or closing the issue, comment the issue with a summary of the worklog. - Add comment |
| Assign a reopened issue to the last person who last commented it. - Update issue (reicht %{issue.lastComment.author} oder muss da eine AccountID hin?) | An issue is blocking another and you want to ensure the Assignee of the blocked issue is notified when the impediment has been resolved. - Add comment |
| Set the due date to today's date - Update fields | An issue is blocking multiple issues and you want to ensure the Assignees of the blocked issues is notified when the impediment has been resolved. - Add comment / Update fields |
| Assign the issue to the current user when the issue is being self-reviewed. - Update fields | Add a comment on all the sub-tasks when the parent is canceled - Add comment / Update fields |
| Set the priority of the issue to Highest if the issue belongs to the "Customer Portal" component - Update fields | On the Approval of an issue, copy the comment added if any to its sub-tasks. - Add comment / Update fields |
| Assign the issue to the Project lead, if the issue is unassigned on creation - Update fields | The Service Desk Agent responsible for a support request should be notified when the linked Bug is resolved. - Add comment / Update fields (multiple issues?) |
| On the creation of a sub-task add its summary to the description of its parent - Update fields | When a developer transitions an issue to "Customer Feedback" copy the developer's comment on the transition screen to the linked issue. - Add comment / Update fields (multiple issues?) |
| Start the progress on an issue immediately after its creation. - Transition issue | Create a documentation ticket only if "Needed" is selected in the "Documentation ticket" checkboxes field - Create issue |
| Automatically escalate an issue if it is being raised with a "Blocker" priority. - Transition issue | We use Jira Service Desk for support and Jira Software for development. When the support agent's problem analysis identifies a bug, a Bug should be created in the development project. - Create issue |
| Start progress on the parent issue when someone started working on its sub-task. - Transition issue | An Epic has a Story and the Story has a sub-task. When the sub-task is reopened we want to create a bug in another project linking it to the sub-task. On creation of the Bug, set its Epic link to the Story's Epic link - Create issue |
| Copy the Fix Version/s field from the Epic to a Story, while creating a Story. - Create issue | |
| Automatically add the Reporter of an Epic to the watchers of its User Stories while creating a Story. - Create issue | |
| Copy the Fix Version/s field from the Stories to Epic, after resolving a user story. - Update fields | |
| On resolving an issue, copy the Fix Versions to all the linked issues regardless of the link type. - Update fields | |
| When creating a child bug of another bug (i.e. the parent bug), copy the fields Assignee, Component and Affect versions if they are left empty. - Update fields | |
| Set the component of an issue with a value selected from a cascading field that carries the Main and Sub-components in parent and child. - Update fields | |
| Send an Email to the voters of the issue when a new feature is approved. | |
| Send an Email notification when an issue is created but avoid Email notification when the issue is cloned | |
| Track the number of times a bug fix was rejected by the QA team. - Update fields | |
| Link all the Faults in Service desk project to the current issue with "blocks" link type | |
| Automatically add the Reporter of an Epic to the watchers of its User Stories while creating a Story. - Update fields | |
| Capture the developer who resolved an issue in a custom single-user picker field - Update fields | |
| On the reopen of an issue, if a user is selected in the transition screen, verify that the user belongs to the Approvers. If not, assign the issue to the first user of the Approvers field. - Update fields | |
| On the approval of an issue, append the current user to a multi-user picker custom field only when the current user is listed in "Approvers" field list. - Update fields | |
| On creating an issue, add it to the first active Sprint of the board the issue belongs to. - Update fields | |
| Set the due date to issue created plus five days - Update fields | |
| On the creation of an issue assign the issue to the current user only if the user belongs to the Administrators group. - Update fields | |
| Copy Jira service desk customers in a multi-user picker field to Request Participants ignoring the reporter of the issue - Update fields | |
| On creating an issue, pick the component of the issue from a cascading field that carries the Main and Sub-components - Update fields | |
| Set the Original estimate of the issue to the difference of its creation date and Due date - Update fields | |
| Set the Affects Version/s of the issue to Affects Version/s of all its linked issues - Update fields | |
| Set the Component/s of the issue to components whose lead is the current user - Update fields | |
| On the creation of a Story, change its priority to that of the Epic if the Epic's priority is lower than the current priority of the Story - Update fields | |
| On the creation of a Story add the reporter of its Epic to the Watchers - Update fields | |
| On creating an issue, Copy the component leads of the selected components to a Multi-user picker field - Update fields | |
| Add the members of the group selected in a custom Single-Group picker to the Watchers of the issue - Update fields | |
| Identify all comments made between transitions A and B and add them to a custom text field - Update fields | |
| Select the Installation tasks in the Checkboxes/Multi-select type field when all the Installations are done - Update fields | |
| Add the time spent during the rework on an issue in the Rework Hours custom field, every time a rework is performed on the ticket - Update fields | |
| Display the Man hours (a custom Numeric field) of an Epic as the sum of Man hours of all the user stories linked to the Epic. - Update fields | |
| Set the issue's due date to the maximum due date set in its sub-tasks. - Update fields | |
| On the Approval of an issue copy its components to issues linked to it with duplicates link type, only if the linked issue belongs to the same project as the current issue. - Update fields | |
| Set the assignee of the linked issues with the current user only if the user is the Developer of the linked issue. - Update fields | |
| Start the progress on an issue immediately after its creation if the reporter of the issue is a Project Manager. - Transition issue | |
| Transition an issue only when all the Business Approvers approve the request through a comment "Approved" - Transition issue | |
| All the cloned issues of an issue should transition through the workflow in parallel with the current issue. - Transition issue | |
| We use Jira as our internal and external issue tracking system. Every client has his project to log issues into. If the issue is valid, the product owner creates a bug in the internal project and links it to the external issue. I want to automate the closing of external issues when its linked bug in the internal system is closed. - Transition issue | |
| Automatically transition the Epic when all Stories are resolved. - Transition issue | |
| Resolve a support request when the bug blocking it is Resolved. - Transition issue | |
| On rejection of an issue, unlink all its linked issues |
