On this page
Use case
From time to time employees leave a company. What happens to the respective Jira account? Deactivating could be an option but for data security reasons users might have to be deleted.
To avoid issues when deleting the user from the internal directory, the following rule can come in handy. It replaces all affected assignees and reporters. Otherwise user cannot be deleted! Plus: Issue related users will be informed by a comment!
Manual trigger
Create a new rule and name it appropriately.
Providing a description will help you to identify what the rule does but this step is optional.
Add a Trigger → Manual
No further configuration needed. The rule will only be executed if a user hits the Execute button 
.
We want to update both the assignee and the reporter but the issues might not be identical. This is why we have to set up two selectors and dedicated action.
JQL Selector
Add Selector → JQL Selector
JQL Query*
Use the following Expression:
reporter = john.doe
Replace "john.doe" with the user name of the user that should be deleted.
Update field action
Next to the JQL Selector click on Add → Action → Update field
Field*
Choose Reporter
Update to*
Choose Selected value
Value*
Select the new reporter that should be set.
Add comment action
Underneath the Update field Action click on Add → Action → Add comment
Comment text*
For liability reasons the reporter has been automatically changed.
JQL Selector
Underneath the first SQL Selector click on Add → Selector → JQL Selector
JQL Query*
Use the following Expression:
assignee = john.doe
Replace "john.doe" with the user name of the user that should be deleted.
Assign issue action
Assignee*
Choose one of the given options that fit most for you.
Add comment action
Underneath the Assign issue action click on Add → Action → Add comment
Comment text*
For liability reasons the assignee has been automatically changed.
Screencast
This is how the configuration above should look on your screen
Related use cases
| Title | Automated action | Use case description | Complexity |
|---|---|---|---|
| Bulk edit the issue resolution | Set a specific resolution on all completed issues that miss a resolution value. | BEGINNER | |
| Transition issues when assigned to a developer | Transition issue | When the assignee is changed to a user in the "Developers" project role, the issue is transitioned to IN DEVELOPMENT. | BEGINNER |
| Transition affected issues when releasing a version (manually) | Manually transition all issues related to a specific version to DONE. | BEGINNER | |
| Transition affected issues when releasing a version (automatically) | Automatically transition all unresolved issues with a Fix Version that is being transitioned to DONE. | BEGINNER | |
| Schedule the escalation of overdue issues | Periodically escalate all issues where the due date has been reached. | BEGINNER | |
| Schedule issues for re-submission | Transition Issue | Periodically transition all issues to OPEN when the re-submission date reminder has been reached. | BEGINNER |
| Resolve issues when all options of a checklist are checked | When all options of a custom checkbox field are ticked, the issue is resolved and transitioned to DONE | INTERMEDIATE | |
| Keep the status of parents and sub-tasks in sync | When an issue is being rejected, all sub-tasks will be transitioned to the REJECTED status as well - automatically. | BEGINNER |
