You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 33 Next »
Inbound email actions allow defining the actions an instance takes when receiving an email. They allow to process inbound email as either an automatic reply or as a record in the system. The processing takes into account the type of incoming mail and other attributes.
They are similar to business-rules in the usage of scripts and conditions that perform actions on the target table. Inbound email actions check the email for some watermark that associates it with a task and checks for other conditions. If the conditions are met, then the inbound email action performs the pre-configured activities. They may be of two types:
- Record action: setting a value for a field in the target table.
- Email reply: sending a reply email to the source that triggered the action.
For inbound email processing, the default email account must be configured preliminary. Email accounts configuring is described in the referenced article.
Inbound email actions are most commonly used for processing emails (for example, create a new Incident when received an incoming email containing "Incident" in the subject line).
How to create an inbound email action
- Navigate to System Notification → Inbound Email Actions.
- Click New and fill in the form.
- Click Save or Save and Exit to apply changes.
Role required: admin
Inbound Email Actions form fields
| Field | Mandatory | Description |
|---|---|---|
| Name | N | The displayed name of the action. |
| Type | N | The message type required to run the action. Available choice options:
|
| Action type | N | The action type. Available options:
When the "Reply Email" option is chosen, then the action behavior is to send an email in reply when triggered. When the "Record Action" option is chosen, then the script is running (it should be specified in the Script field). |
| 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 | N | Select this checkbox to terminate other inbound actions after the current action runs. |
| Reply email | N | Compose the email message to send to the source that was the trigger of the inbound action |
| From | N | Reference to the user, on behalf of which the script is executed, or the reply letter is sent. |
| Filter conditions | N | Specify the condition that must be met to trigger the inbound action. Use the Condition Builder to build a filter that fits your needs. You can create complex AND and OR filters, more than one condition in one filter. Once the condition is met and the action is triggered, the email will be processed and/or an event may be created. So the record of the table specified in the Table field is not accessible. |
| Script | N | Enter the script that the inbound email action runs. You can use all methods of server-side API classes here, |
| Table | N | Select the table where the action adds or updates records. |
| Description | N | Enter the detailed description of what this email action does (this is optional). |
Inbound actions logging
Every inbound action triggering is logged in the Script Log table. Trigger logs can be filtered using the criteria below:
- Source IS InboundAction
- Essence Document IS (or CONTAINS, or STARTS WITH, or ENDS WITH) Email
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.
- No labels
