The escalation service allows you to define a process for modifying issues after a certain time has elapsed, useful for business procedures that require that tasks be completed within a certain time (service level agreement). For example, if a task has been opened but not assigned for 7 days you could automatically move it to a "Prioritise" status, or add a comment which will cause an email to be sent.
Or you want to send an email to the QA team if a ticket has been Resolved for 2 weeks but not tested yet.
This is a far easier alternative to jelly escalation.
To get started, navigate to Admin → Built-In Scripts → Escalation Service.
No services will be defined initially, so click on New Service.
Enter the following parameters:
just a note for your own benefit, eg: "Support reminder service"
- JQL Query
You will normally want to specify an "updated" clause, eg
status = Open and project = XYZ and updated < -7d. Test your query in the Issue Navigator first.
- User ID
Enter the ID of the user that the service will run as. You need to provide a user that has permission to transition the issue, or comment on the issue or whatever.
Define a user called automation or similar, give it admin rights and developer rights in every project, and use this for the service user.
Note that admin users typically don’t have permission to transition issues in every project.
How often the service should run. For this there are two options: minute values, or CRON expressions.
Due to an Atlassian Scheduler quirk, a CRON or minute-based value that runs per an interval of time will cause the service to run automatically upon start-up of JIRA.
If you would like to avoid this effect, use a non-interval CRON expression such as:
0 30 12 1/1 * ? *
signifying that the service will run once per day at 12:30, based on a 24-hour clock.
What action do you want to run on the issue? This is optional, you can use Additional Issue Actions instead or as well as
- Additional Issue Actions
Run some additional code as part of the transition. Typically that involves calling methods of the passed in issueInputParameters - see the examples for sample usage.
If the field you are updating does not appear on the screen for the transition, or there is no screen, you should add the following line:
Using IssueService directly, you can only update fields on the issue if there is a screen for that transition, and you can only update those fields that appear on the screen. However, we allow you to update the issue even if there is no screen.
You can always add a comment using
- Transition Options
These options allow you to skip validators, conditions and permissions on transition. For example this is useful when you want to force the transition to happen as a user that does not have the correct permissions, or you want to make use of the standard condition that hides the transition from users.
Clicking Run Now will run the service with the parameters you have entered, but will not install it as a service.
|The service could potentially operate on a large number of issues depending on your query. Make sure you test the query first in the issue navigator.|
|It might be useful to test the service in a copy of your production environment first|
If selecting a transition action you should verify that the particular action is valid for all issues that you are matching on. For instance, although multiple statuses might have a Close Issue transition, it will need to have the same action ID, ie be the same action. If not, you could either modify the workflow or use two different services, with queries that select the two different states.