Inbound email processing The system determines which inbound actions to run by comparing the inbound email type and inbound action conditions to the incoming email message. Certain properties are available to set the reply and forwarding prefixes in the email subject lines that your instance recognizes when processing inbound emails. The system follows this processing flow to determine whether to run an inbound action. Figure 1. Inbound action processing work flow The system only runs an inbound action when: The incoming email type matches the inbound action Type. If present, the watermark or record number refers to a record in the Target table. The inbound action Conditions evaluates to true. If any of these criteria are not met, the system skips the current inbound action and evaluates the next active inbound action. The system processes inbound actions from the lowest to highest Order value. If the inbound action has Stop processing enabled, then the system updates the State of the email record to Processed after running the inbound action Script. The following video shows how an inbound action condition prevents an incident from being created. Troubleshooting when inbound email isn't processed Prefixes recognized in email subject lines Email reply prefixes When no watermark is present or the In-Reply-To email header is present, the instance recognizes email containing a prefix from the glide.email.reply_subject_prefix property as reply email. You can use this property to set non-standard reply prefixes in your email system. Property Description glide.email.reply_subject_prefix Specifies the list of prefixes (comma-separated) in the subject line that identify an email reply. Type: string Default value: re:,aw:,r: Location: Add to the System Properties [sys_properties] table Note: Prefixes are case insensitive. Email forward prefixes Emails with certain prefixes trigger the forward type of inbound email action. The instance recognizes any email whose subject line contains a prefix from the glide.email.reply_subject_prefix property as forwarded email. Emails with these prefixes trigger inbound email actions of the type forward. Use this property to set non-standard forward prefixes in your email system or you want email forwards to behave like replies. Property Description glide.email.forward_subject_prefix Specifies the list of prefixes (comma-separated) in the subject line that identify a forwarded email. Type: string Default value: fw:,fwd: Location: Add to the System Properties [sys_properties] table Note: Prefixes are case insensitive. Email forwards as replies Properties are available to force inbound actions to process forwarded mail as replied mail. These properties control the subject prefix that the inbound actions use. Property Value needed glide.email.reply_subject_prefix re:,Re:,RE:,aw:,r:,fw:,fwd:,Fwd:,FWD: glide.email.forward_subject_prefix [any text that is not a forward prefix] These properties cause the Update Incident inbound action to process all forwarded and replied-to mail.Note: The glide.email.forward_subject_prefix property must contain some text so that the forwarded email can be processed as a Reply. It can be any text except a forward prefix (that is, fw:,fwd:,Fwd:,FWD:). Matching a sender email address to a user The instance matches a senders email address to an active user in the User [sys_user] table using inbound actions. Note: The Email Automatic User Creation plugin must be active. When processing an email, the instance sets the current user to the user whose email address matches email.from. Inbound actions can then reference that current user. For example, the base system inbound action Create Incident sets the caller_id of the incident to the value returned by gs.getUserID(). If multiple users have the same email address, the instance first searches for an active user with the email address. The instance does not match inactive users. Note: Each user record must have a unique email address so that the instance can reliably match the email to the correct user.If a unique email address for each user is not possible, assign a shared email address to only one active user so that the instance always matches incoming email from that address to the active user. Matching watermarks in the Subject line or Body The following examples illustrate how the instance matches randomized watermarks in an email subject line or body. Table 1. Examples of matching watermarks in the Subject line or body Subject Line or Body Contents Matching Results Ref:MSG0000008_ aLJc130zDhCVuh3spXmt The instance recognizes this string as a watermark and searches the Email Watermarks [sys_watermarks] table for a record with the number MSG0000008_ aLJc130zDhCVuh3spXmt. If this watermark exists, the instance matches the email to the associated record. If this watermark does not exist, the system processes inbound email messages as described in Criteria for matching email to inbound actions. Ref:MSGWTR0000008_wfLLz42IxCgUvG2JlYnh The instance recognizes this string as a watermark and searches the Email Watermarks [sys_watermarks] table for a record with the number MSGWTR0000008_wfLLz42IxCgUvG2JlYnh. If this watermark exists, the instance matches the email to the associated record. If this watermark does not exist, the system processes inbound email messages as described in Criteria for matching email to inbound actions. Criteria for matching email to inbound actionsThe system matches incoming email to the conditions of the active inbound actions.Create an inbound email actionYou can create inbound email actions to define the actions that the system takes when an email is received.Email object variablesAn inbound email action script contains the email object to access various pieces of an inbound email through variables. You can use the global variable sys_email with inbound email 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 impersonations and inbound actionsWhen the instance receives an email, it can take a variety of actions by impersonating the sender.Enable automatic user creationAn administrator can set an email property to automatically create users from incoming email. The administrator provides a list of trusted domains to prevent untrusted users from being automatically created.User creation from incoming emailAn instance can automatically create users from incoming email. Redirecting email to the instance POP3 accountYou can have other mailboxes forward email to the instance's POP3 account. Setting field values from the email bodyValues in an inbound email can set field values in a task record. Integrate inbound eventsThis exampoe illustrates how to create a notification from an inbound JSON request.