The list below contains some use cases that can be realized using JWT 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 |
