overview servicely can receive inbound messages, and these can be used for common operations such as create an interaction or incident update comments against an existing request, incident, case, etc create records based on events from a monitoring system basic 2 way integration with another system for each matching inbound message configuration, a script is run that can perform the creates, updates, or any other server scripted actions in servicely to access this functionality, navigate to administration > messaging > inbound messages the following image shows the configuration form configuration the keys parts of the configuration are best thought of as two main concepts match rules, which are used to select an inbound message to execute the processing script, to perform the required actions note only the first inbound message that matches the given conditions will be executed field type example entries notes / description general fields name string "incident commented" the logical name used for identification of the configuration only matching rule fields table table incident for reply messages (see details on watermark below), match only if this configuration matches the table associated with the watermark type choice new/forward/reply used to match if the message is a new message, a forward, or a reply to string service\@company com match only if the to address matches if not set, matches all to addresses from string alerts\@company com match only if the from address matches if not set, matches all from addresses active boolean true only active configurations are candidates for processing priority order integer 10 the priority order in which an attempt to match for processing the lower the number, the higher the priority once a match is found, no further matches are attempted for any recipients who received it, send to initiator boolean false this determines whether or not the person who caused this notification to trigger (normally the updated by person) will receive the notification if they are a recipient user script code server script that allows you to script what user is associated to the email processing this can be useful in situations where you have multiple users with the same email address in the system, or need an inbound message to process emails from multiple addresses to with a certain user to utilise this feature your instance needs to be on version 1 10 or later condition code server script to use as a condition on the mail for this notification to match "email" object has body, reply body (the body stripped of all previous replies), subject, to, from, matched (boolean field set to true if matching watermark found, and hence a record update), type (new, reply, forward) as fields i e email subject, email to, etc processing fields send individually boolean false determines if the notification should be sent individually, as opposed to including all recipients in the same email processing script code this is a server script that is executed when a match (per configuration of above fields) is made typically this would be to date comments in an existing incident, request, etc , or the creation of a new interaction, incident, etc processing script will be run against the incoming email (email), matched record (current), and the matched user (user) to perform the required action available elements of the email object are subject body (full) no html body (full with no html) body reply (stripped to just the current reply part) no html body reply (full with no html) from to recipients to (array of email addresses) recipients cc (array of email addresses) matched (matched with a record from an outbound email) type (new, reply, forward) examples user firstname(), email subject, current number() see example below for more detail processing script example the following shows a worked example of creating a new interaction from an inbound message // create new record let interactionrec = table("interaction") newrecord() shortdescription(email subject) clientjournal(email body) description(email body) source("email") email(email from); // if it's from a user that exists in the system, query the user and set fields accordingly if (user) { let userrec = table("user", equal("id", user getid())); if (userrec mobile()) { interactionrec phone(userrec mobile()); } if (userrec location()) { interactionrec location(userrec location() getid()); } interactionrec requestor(user getid()) requestedfor(user getid()); } interactionrec create(); update record matching all outbound messages from servicely have a watermark added, such as sbx\ msg0000023 when such a message is replied to, the inbound message processing will match this watermark with the record that triggered to outbound message, opens that records, and makes available as current, in the same way as other scripting in servicely this allows for comments to be added to the client journal, say, of the same record and allow that to be updated note the processing script will require current update(); to be performed after all other updated have need done, to take affect in the underlying record user matching inbound messages attempt to match the email sender with a user configured in the system this may be used for setting fields such as requestor, etc the user object is available processing script for setting fields / other decisions the user is determined first by searching the user records for a match; if one is found, that user is used in the case of no matching records in the user table directly, the system will search user email alias records for a match (more details below) if not match is found the user object will not be set email aliases there are situations where a user may be identified by one of numerous email addresses for instance, a company may have merged, and users are configured primarily under the new company name, but still are using acquired company email address user email aliases are provided for this situation, where any number of email addresses can configured against a user outbound emails for a user will always use the primary email configured in the user record, but for inbound messages, any of the primary or email aliases can be used, and still match to that user the email aliases are configured in the related list on the user record (see image below), or may be imported into the useremailalias table handling attachments within the processing script, you can determine exactly how attachments are handled