This post shares information on how simple it is to create an incident via email or just to update work info entries. There are situations where in you receive issue information in email which you want to record in the issue. The feature here makes it as simple as just two clicks to create incidents.
Believe me, if implemented properly it would certainly reduce the number of calls to the service desk and it’s a faster way of creating incidents. The key objective of setting up the ‘Email engine rule’ is to be able to create new Incident requests and/or add work information to existing Incidents, Problems, Known Errors, Work Orders or Tasks.
When you have rules to send email and create Incidents, the user would also receive an acknowledgement saying the incident was created and provide the Incident number. Therefore, once an incident is created the user can reply to the acknowledgement email to add some more information to Incident. Those updates are added to Work Info of the respective record. For example. If the email subject has the incident ID then it would add to the Incident work info. Similarly, you can update Problem ticket, known error, work order and Task.
The diagram below depicts an outline of the ‘Email Engine Rule’:
Please ensure pre-requisites are met prior to successful setup of ‘Email Engine Rule’:
Start here: Go to Administrator Console > Application Administration Console > Custom Configuration > Foundation > Email Engine Rules > Configure Rules.
Above link displays configuration page, here please note the ‘- Global –‘rules. Explore Base Configuration tab, Rule Configuration tab etc.
Separately you can outline company specific rules, as per your requirement and preference. An important point is company specific rules are prioritized over Global rules. Also, remember that Global rules are not ignored; they are looked up if there are no company specific rules.
Glimpse that ‘Inbound Email Status’ is ‘Active’.
Let’s get familiar with how to configure a company specific email rule. There are only two segments you would configure, first is ‘Excluded Subject’ and second is ‘Use Case’. Let’s move to details:
1. Configure ‘Excluded Subject’:
Excluded subjects are words or phrases that, if they appear in the subject line of an incoming email message, cause the Email Engine Rule to reject the message. It would benefit, for example if the phrase ‘Out of Office’ is in the excluded subject list, so the Email Engine Rule rejects any incoming message that contains this phrase.
You should check out existing out-of-the-box ‘Excluded subjects’ which are associated with the Global Company setting and apply to all companies in your environment.
If your company's email environment generates other subjects that you need to exclude, you can create company specific excluded subjects.
Please follow below link to know more on, how to create company specific excluded subjects
2. Configure ‘Use Case’:
You create the use case record from the Base Configuration tab of the Inbound Email Rule Configuration form. The Email Engine Rule determines what action to take according to the rules that you define in the use cases. The basic types of use cases are Create and Update. For example, you can define the following use cases:
- Tell the Email Engine Rule to create an incident request that uses a specified incident request template, based on the content
of the email subject line.
- Update an existing incident request with work information notes.
If the Email Engine Rule cannot match an email message to a use case, it rejects the email message.
You complete use cases by following 2 steps:
A. Create the use case record.
Please follow below link to know how to create an Email Engine Rule use case.
B. Define the use case rules.
Once you create the Use Case record, go to ‘Rule Configuration’ tab of the Inbound Email Rule Configuration form. Here, choose the ‘Form Name’ and ‘Use Case’ for which you are going to define the rule. Now, define ‘Rule qualification’ and ‘Actions’ as per the requirement. In the ‘Actions’ pane, you specify the type of action that occurs when the ‘Rule Qualification’ is met.
There are a few check boxes or options available that you can use to complete your rule.
Please follow below link to become familiar on what these check boxes/options mean. Kindly look for section ‘Functional panes on the Rule Configuration tab‘
You can also use an ‘Incident Template’ in the Use Case. Having this, it carries all benefits such as you would be able to define assignments or have tasks in-build. Follow the below guidelines when you are drafting your ‘Use Case’.
- In the Option field (located in above picture), select Incident Template Name/ID.
- Select the Value as ‘Incident Template Name’ from the dropdown. And then select the arrow to the right.
- Click Save.
- Run a test of the rule by sending an email message that satisfies this rule to the inbox.
Now, as you have configured email engine rule, let’s get in to the way of creating new incident or updating work info entries.
CREATE an email generated incident request?
- Draft an outlook email with Subject field and the body text according to the rules configured and send it to email id registered with the BMC Remedy Email Engine to receive and generate incident requests.
- If there are any attachments in email, the system adds attachments to the respective Work Information.
ADD work information by using email?
You can add work info to existing records mentioned at the beginning. The system would identify the request based on your preference in ‘Use Case’ field ‘Find Request in fields’’.
- You need to specify work information text in the body of the email message. Also, attachments can be added to the email.
Once user sends emails, here is where you monitor outcome. As seen in below picture, ‘Messages’ tab of Email Rule configuration form display messages created. Click on ‘Transactions’ to review transaction data. And click on ‘View Request’ to open the request generated.
What’s more, you are now good to use this valuable feature. Certainly it would add value to your work and business.
Before I end, I would like to show some light on basic checks in case you face issues and also introduce you to first two tabs: -
- First, you would definitely want to refer to the ‘User Requisites’ and ‘System Requisites’ mentioned at the beginning of this blog.
- Check if email is reaches Remedy by reviewing if ‘AR System Email Messages’ form has it or not.
- Check if the subject of the email message is valid and not part of Global and Company Specific ‘Excluded Subject’
- Check “RBE:Transaction” and filter logs for error.
- For comparison, the ‘AR Email Messages’ tab below shows the message arrived in ‘AR System Email Messages’ form.
In this post, I covered the high points and suggestions for implementing Rule Based Email, and how that can be useful in Remedy Service Desk. I hope it was helpful. I would like to hear from you. Are there other ways the feature has been particularly helpful, or limitations that prevented it from meeting your needs? If so, please add comments below.