Inbound email actions Inbound email actions enable you to define the actions an instance takes when receiving email. Inbound email actions are similar to business rules: both use conditions and scripts that take action on a target table. An inbound email action checks the email for a watermark that associates it with a task and checks for other conditions. If the conditions are met, the inbound email action takes the action that you configure. The system can take two types of actions: Record action: setting a value for a field in the target table. Email reply: sending an email back to the source that triggered the action. By default, if an email has no identifiable watermark, an inbound email action attempts to create an incident from the message. If the email has a watermark of an existing incident, an inbound email action updates the existing incident according to the action's script. Attachments If an inbound email contains one or more email attachments, the inbound email action adds the attachments to the first record the action produces. Character encoding If the email encoding is ASCII-7 or UTF-8, inbound email actions preserve the character encoding in any associated task records they produce. If the email encoding is ISO-8859-1, the inbound email action attempts to convert the email to Windows 1252. Inbound email actions convert any other encodings (for example, Mac OS Roman) to plain text, which may or may not be readable. See the Email logs for examples of what you might see if a notification or inbound email action is not processed.Note: Starting with the Helsinki release, the state of all incoming emails that have been run against inbound email actions, even if there is no matching action, is changed to Processed. Domain separation The system ignores the domain that the inbound email action record is in when it creates a record based on the inbound email action. Keep inbound actions in the global domain. For example, if your inbound email action creates an incident, the system creates the incident in the same domain as the user in the Caller field. If that user is not in the User [sys_user] table, the incident is in the global domain. Inbound action type criteriaAn instance uses a set of criteria to decide what action to take based on the type of message that is sent to the instance. Create an inbound email actionYou can create inbound email actions to define the actions that the system takes when an email is received.Accessing email objects with variablesAn inbound email action script has access to various pieces of an inbound email through script variables. Example assignment of tasks via emailName:value pairs in an email template can set field values in a record.Locked out users triggering inbound email actionsA property is available to have locked out users trigger inbound actions.Email user matchingWhen the instance receives an email message, the system searches for an existing user record with the same email address as the sender.User creation from incoming emailAn instance can automatically create users from incoming email. Prevent untrusted users from triggering inbound actionsYou can prevent users from untrusted domains from triggering inbound actions.Inbound email recipient processingThe recipients variables allow processing of inbound email based on the email recipients. The sys_email variableYou can use the global variable sys_email with inbound email actions. Email redirection to the instance POP3 accountYou can have other mailboxes forward email to the instance's POP3 account. Field values from the email bodyValues in an inbound email can set field values in a task record. Integrating inbound eventsThis tutorial illustrates how to create a notification from an inbound JSON request.Inbound email action examplesSeveral examples of inbound email actions are available to help you build your own inbound email actions.Ordered email processingThe Ordered Email Processing plugin enables you to configure a processing order for inbound email actions.