Features used to implement the example
Example: Triage Jira Service Desk email requests
The use of email requests in Jira Service Desk has one decisive disadvantage: only one request type (and therefore only one issue type) can be configured on a per email channel or per project basis.
In this example, a triage mechanism is configured for issues created via email, that are configured as request type Email request and issue type IT Help. If the summary contains the keyword "Incident" the request gets moved to issue type Incident and request type Email incident.
The recommended approach consists of two steps:
Add a global reflexive transition (from any status to itself) named Incident Triage.
In order to hide this transition from Jira users, add a Transition is triggered by Jira Workflow Toolbox post-function condition. Additionally, add a Move issues post function, with the following options:
- Project → Retain the project
- Issue type → Selected issue type → Incident
- Status → Selected status → Open must be a valid status present in the Incident's workflow
- Additional fields, e.g.
- Priority → Standard → Blocker
- Customer Request Type → Standard → Email incident
Additional fields aren't required, but at least Customer Request Type should definitely be set to ensure customers retain request visibility.
Once configured, the transition will look like this:
All the remaining post functions in this transitions are superfluous for this example and therefore can be deleted.
Next, add a Transition issues to the Create issue transition of the workflow attached to email requests - in this example IT Help - with the following options:
- Target issue → Current issue
- Execute transition → Incident Triage
- Conditional execution
%{nnnnn} = "move/b52566f1-6353-404a-98de-04e9a2a351a1" AND %{00000} ~ "Incident"
The field code nnnnn has to be replaced with the corresponding one for Customer Request Type (Customer Request Type Custom Field). To receive the exact value to match against, the easiest way would be to set this request type on an issue and evaluate with the help of our Expression Parser Test page.
In the latest versions of Jira Service Desk, those request types consist of the project key, a forward slash and a hash value.
Once configured, the transition will look like this:
Ensure that Transition issues is placed after the Create the issue originally post function.
Once those two transitions are configured, requests created via email with the keyword "Incident" in its summary - which is the email subject - will be moved to the new issue and request type.
Other examples of that function
- Automatic work log with start and stop work transitions
- Automatically log work time when the user uses a "Stop Progress" transition
- Calculate the time elapsed between 2 transition executions
- Getting the number of selected values in a custom field of type Multi Select
- Implement a form with a series of questions and calculate a numeric value based on the answers
- Increment a field or set to 1 if it's not set
- Set "Date-Time Picker" custom field with current date-time
- Set "Due date" 6 natural days (or work days) earlier than a "Date Picker" custom field
- Set "Due date" to a specific day of next week no matter of date of creation this week
- Set "Due date" with certain time offset from current date
- Set "Total time spent" to "Current date and time - date and time of last update"
- Set a custom field "Urgency" depending on a combined value of issue's priority and "Impact" custom field
- Sum "Time Spent" in all sub-tasks of issues linked with issue link types "LinkA", "LinkB", "LinkC"
- Triage Jira Service Desk email requests (Move issues)
- Using project properties to calculate custom sequence numbers