Setting up a Service Management with a Next-Gen Mail Handler

📈 Marketplace ❓ Support ❤️ Feedback 🏠 META-INF Apps
Search…
Email This Issue - for Jira Server/Data Center
​
In this guide, we are showcasing how to set up a service management with Email This Issue's next-generation mail handler through the example of a company's HR department who is testing the new handler.
Before you begin
In order to ensure working in the above scenario, a number of settings will need to be configured on both Jira's and Jira Email This Issue app's site. For more information, see the rest of our user documentation.
Note: The following is a test case, only meant as a basic setup to showcase a new functionality. Differing setups will yield different results, please keep that in mind when creating your unique setup.
You should have your Jira-related setup ready before creating the mail handler, such as:
Three custom fields created in Jira:
one multi-user picker field called Internal participant
one single-line text field called External participant
and one select list (single choice) custom field called Customer Category with the options "Regular" and "VIP"
Proper permissions set up for agents and customers, including a technical user who will be your default reporter.
Project-level Customer permissions set up according to your needs.
Workflow configured with the transition property "jeti.on.email.transition" on a re-open transition.
You should have some Email This Issue-related setup ready before creating the mail handler as well, such as:
One template for the "Issue created" notification. We recommend that you create it based on the Theme: Service Management Request Created. Read more about templates here.
One notification set up in Email This Issue for the "Issue created" event with the above template. Read more about notifications here.
One context set up with the above notification (recipient being the reporter). Read more about contexts here.
SMTP server setup and mapped in the context (alternatively use Jira's built-in SMTP connections). Read more about connections here.
Have a Mail Account setup for the mail handler. Read more about mail accounts here.
Use case

HR would like to open requests via email every time a new employee needs to be hired (a new request opened) and comment on those requests when there is a reply in connection to the original email. 
When a request is opened, an email should be sent to the reporter, notifying them of a successful request creation.
If a new request is created from an email with the sender address ending in "@gmail.com", the customer category of the request should be set to "VIP" (as they need to process these requests in a different manner).
When the customers send a reply email, a public comment should be left on the issue, while an agent's reply should always leave an internal comment. Related issues should be found by issues keys appearing in the email subject.
In both cases of new and reply emails, the senders and the recipients should be saved as follows:
By default, email senders are saved as Reporter in newly created issues.
User senders without (create issue and browse) permissions should be saved in a custom field called "Internal participant".
Senders unknown to Jira should be saved in a custom field called "External participant".
SD Customer recipients should be saved as Request participants.
SD Agent recipients should be saved as Watchers.
User recipients with (create issue and browse) permissions should be saved as Watchers.
User recipients without (create issue and browse) permissions should be saved as Internal participants.
Recipients unknown to Jira should be saved as External participants.
If the sender does not have permission to either open a request or leave a comment, a technical user should take action in the name of the sender.
It is also important for them that only relevant emails create requests and that reply emails to the Issue Created notifications are cut. This way, their comments will be short and only include relevant information.
When the request is resolved and it is in "Done" status, it should be re-opened upon a new comment being added to the request.
Procedure
This section only details how to set up the next generation mail handler for your service management project. Its goal is not to detail any Jira-related setup or any Email This Issue-related pre-requisites, but show the setup of a new kind of mail handler. For more information about Next Generation Mail Handlers see here. For Classic Mail handlers, see here.
1. Go to INCOMING EMAILS --> Mail Handlers.
2. Click on Add, and select Add Next Gen Mail Handler from the dropdown list.
3. Fill in the fields with the following information, making sure to add a name and a mail account as well as a technical user for "Default reporter". This user should have all permissions to create issues and add comments on the project. You can always open this dialogue by clicking on the three dots at the end of the handler's row and clicking on Edit.
Important: In order to make the handler fully compatible with Jira Service Management, the default reporter must have Project Administration and Service Management Agent permissions. It is typically achieved by assigning the default reporter to the Administrators and Service Management Team project roles and assigning Service Management application access.
4. Click Save to save the settings or Cancel to exit this configuration without saving. 
Note: Once the handler is saved, it is displayed in the list of Next Gen Mail Handlers as "DISABLED". You will need to click on the three dots and "ENABLE" eventually, to ensure its working, however, you may also carry out this step after having the mail handler configured.
5. Click on the three dots and then choose Configure to open the setup page for your new mail handler. There are four sections presented that need to be configured in a Next Generation Mail Handler:
Filter Emails: set up by default, filtering emails that could be spam messages, large emails or emails of similar nature that you do not want to get processed. Leave it as it is, for now, it will filter emails based on the following attributes:
Find Issues for Email: set up by default as "Find issues by issues key appearing in the email subject". Leave it as it is, for now, it will find related issues based on the issue key in the reply emails.
If Issue found for Email: actions to take when an issue is found based on the issue key in the email's subject.
If Issue not found for Email: actions to take when an issue is NOT found based on the issue key in the email's subject.
6. To configure the actions "If issue found for email", click on the + icon at the end of its row. For our configuration, first, click on Condition to create an IF statement. Define the "Email Sender is" parameter as "Service Management Customer" and click on Save:
7. Click on the + icon at the end of the "If Sender is Service Management Customer" row we just created, then click on Add Comment. Set the "Comment Visibility" to Add public comment, the "Add attachments field" to Filter attachments using the attachment filters, and copy-paste this line in the Split regex section:
1
\s*From:|___.|On|On .wrote:|----Orig.|On .(JIRA).
Copied!
Note: Leave the "Attach original email as .eml file" toggle disabled for this scenario. 
8. Click Save to carry on with the rest of the configuration.
9. Click on the + icon at the end of the "If Sender is Service Management Customer" row we just created, then click on Else to create a condition for when the email sender is not a service management customer. 
10. Click on the three dots at the end of the Else row and select Add comment. Set the "Comment Visibility" to Add internal comment, the "Add attachments field" to Filter attachments using the attachment filters, and copy-paste this line in the Split regex section:
1
\s*From:|___.|On|On .wrote:|----Orig.|On .(JIRA).
Copied!
Note: Leave the "Attach original email as .eml file" toggle disabled for this scenario.
11. Click Save to carry on with the rest of the configuration.
12. Click on the + icon at the end of the "If Issue found for email" row, then click on Update issue to create an action that runs separately from the IF-ELSE conditions we created. This means that this action will be carried out by the handler regardless of the project role of the sender.
13. Click on the three dots at the end of the "Update issue by setting fields" row we just created, then click on Save Senders and Recipients. 
On the Senders tab, set the "User w/o permissions" field's value to the custom field Internal participant and the "Unknown to Jira" field to the custom field's value to External participant.
On the Recipients tab, also set the "User w/o permission" field's value to the custom field Internal participant and the "Unknown to Jira" field to the custom field's value to External participant. Leave other fields as they are, for now. 
14. Click Save to carry on with the rest of the configuration.
15. Click on the + icon at the end of the "If Issue found for email" row, then click on Execute Workflow Transition to create an action that runs separately from the "IF-ELSE" conditions we created earlier. This means that this action will be carried out by the handler regardless of the project role of the sender.
Note: A dialogue is displayed, where only one attribute has to be configured in our use-case: the "Select transition" option has to be set to By transition property. This is selected by default, but if you are editing a handler and this is not the default value, select this option and click Save.

The handler should now look like this:
16. To configure the actions "If issue not found for email", click on the + icon at the end of its row. For our configuration, click on Create issue and define the parameters according to your project and issue type. In our case, the "Project" is New Handler Project, the "Issue Type" is set to Service Request and the "Request Type" is New employee. Set the "Add attachments" field to Always add attachments, leave the split regex field empty and leave the "Attach original email as .eml file" disabled for now:
17. Click Save to carry on with the rest of the configuration.
18. When a Create issue action is created, a Save Senders and Recipients action is automatically created as well. Click on the three dots at the end of the "Save Senders and Recipients" row that just has been created, then click on Edit.
On the Senders tab, set the "User w/o permissions" field's value to the custom field Internal participant and the "Unknown to Jira" field to the custom field's value to External participant.
On the Recipients tab, also set the "User w/o permission" field's value to the custom field Internal participant and the "Unknown to Jira" field to the custom field's value to External participant. Leave other fields as they are, for now. 
19. Click Save to carry on with the rest of the configuration.
20. As a last configuration step, click on the three dots at the end of the "Create Service Request (New employee) in New Handler Project (NHP)" row. For our configuration, click on Set issue field and define the parameters as below:
21. Click on Save to finish configuring your mail handler, which should look like this by now:

Results
If the above procedure has been followed correctly, a request with comments should be created from the incoming email as follows:
It is visible that as per our guide, the issue is created in the New Handler Project with the Service Request issue type and New employee request type.
Because of the field rule, the Customer Category is set to VIP as the reporter's email address ends in the domain "gmail.com".
Two comments are left on the issue:
a public comment from the reporter which is a reply email from the customer to the Issue Created notification
an internal comment from the assignee (who is an agent) that is related to the request and mentions the issue key in the email subject.
Related articles
​Email Templates​
​Event Notifications​
​Service Management Integration​
​Contexts​
​FAQ​
Setting up customized notifications
Next - Misc
Open Source Components
Last modified 3mo ago
Copy link
Contents