Inbound email actions are most commonly used to process emails. For example, if an incoming email contains "Incident" in the subject line, the system creates an incident record.
Inbound email actions are similar to business rules in the usage of scripts and conditions that perform actions on the target table. Emails are checked by inbound email actions for defined conditions and some watermarks that associate the email with a task. If the conditions are met, the inbound email action performs the pre-configured activities. There are two type of them:
Use a script to define how the system will respond to certain triggers – this could be a specific email topic, keywords in its body, or more complex conditions. Unlike Notification Rules, inbound email actions enable the user to interact with the records in the system.
For example, while processing an incident in the Information Needed state, the system inserts the body of this email to the Additional Comment field in the Activity Feed when the caller sends their response. The condition is that the caller's email contains a specific text in its subject, and the task number it includes matches the one in the incident record. That is, the inbound email action defines what happens in the system after receiving an email.
For inbound email processing, the default email account must be configured preliminary. See the Email Accounts article to learn more about email accounts configuring. |
Inbound Action includes three major groups of parameters:
The third group of parameters is required to organize multiple Inbound Actions in a way that they check an incoming email to match the condition defined in each of them, in a certain order. The less is the value in the Order field of an Inbound Action, the earlier this Inbound Action checks if a received email matches its execution condition. As a result, each email goes through an ordered chain of condition checks, from the Inbound Action with the least Order value to the one with the biggest, with the following processing logic:
As a result, one inbound email can trigger execution of none, one or several action scripts in a row, depending on the values of the Active, Order and Stop processing when complete fields in each Inbound Action defined in the system.
Role required: admin. |
Field | Mandatory | Description | ||
---|---|---|---|---|
Name | N | A displayed name of an inbound action | ||
Action Type | N | The action type. Available options:
When the Reply Email option is chosen, the action behavior is to send a response email when triggered. When the Record Action option is chosen, the script runs (it should be specified in the Script field).
| ||
Message type | N | The message type required to run the action. Available choice options:
| ||
DSN | N | Select this checkbox to trigger the action in response to Delivery Status Notification emails.
| ||
Invitation | N | Select this checkbox to trigger the action in response to Invitation emails.
| ||
Description | N | Enter the detailed description of what this email action does (optionally). | ||
Reply Email | N | Compose the email message. It will be sent to the source address that triggered the inbound action. | ||
From | Y | Reference to the user, on behalf of which the script is executed, or the response email is sent. | ||
Script | N | Enter a script that will trigger the inbound email action. You can use all methods of server-side API classes here.
| ||
Table | N | Select the table where the action adds or updates records. | ||
Active | N | Select this checkbox to activate the action. | ||
Order | N | Enter the number to define the order of action processing. Actions are processed in ascending order (lower numbers are processed first). | ||
Stop processing when complete | N | Select this checkbox to terminate other inbound actions after the current action runs. |
We need to configure an inbound action implementing the following logic:
When the system receives an email with topic containing keyword "access", a new incident is created and assigned to the group responsible for security and access to the system and data.
We create an inbound action as below:
Field | Value | |
---|---|---|
Name | Create incident (access issue) | |
Action Type | Record Action | |
Message Type | New | |
Active | True | |
Script |
|
Every inbound action triggering is logged in the Script Log table. These logs can be filtered using the criteria below:
The Essence Document field is responsible for email processed by inbound action. You can enter full address or a part of it, and you can use precision or imprecision condition operators, respectively. |
Use the Condition Builder to build filters that fit your needs.
The incoming mail parsing returns the address value for the From field of a record from the Email (sys_email) table in lower case.
When searching for a user by the email in the Script column, you should not use the IS operator because the value of email can be entered with uppercase letters. For example, J.Doe@mail.com.
user.get('email', 'j.doe@mail.com'); |
Also, do not use the LIKE operator when searching for a user by email because the search will find a user with a similar email, for example, 'raj.doe@mail.com'.
user.get('email', 'like', 'j.doe@mail.com') |
The following example shows the script with the userIDbyEmail() method that search a user by email value:
class MyEmailHelper extends EmailHelper { userIDbyEmail(email) { const user = new SimpleRecord('user'); user.addQuery('email', 'startswith', email); user.addQuery('email', 'endswith', email); user.selectAttributes('sys_id'); user.setLimit(1); user.query(); if (user.next()) { return user.sys_id; } return this.searchGuest(); } } |