Inbound Messaging

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 true unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type 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 attachmentmanager copyemailattachmentstojournal(email id, interactionrec clientjournal, email body);