20.4. Inbound Email and Requests Processor

Inbound Email Processor Setup

The Inbound Email Processor allows you to automatically intercept email messages and convert them into requests. The Inbound Email Processor window, located in the System Admin -> Email Services menu is used to make the necessary configurations. The following data is required:

• Schedule - desired frequency for automatic processing;

• Days to keep log - number of days for which the log is kept. The log records can be viewed in the Log tab;

• Email Inbound Account - the email account that will be scanned by the processor. The account needs to be defined in the Inbound Email Account window:

  • • Name;

    • Account Type (the functionality is only available for Gmail accounts);

    • Folder = gmail label name - only emails with this label will be processed;

    • Email - email address for the account regardless of the associated user;

    • the details should contain a record used for access to the email account:

      • User ID

      • Password

• • Organization, Request Group, Request Type - mandatory information that will be used for the generated requests.

  • Request Category, Request Status - optional information that will be used for the generated request request;

  • Details in Request Setup;

  • Project Type - will be used to determine the project that will be used for the generated request. The project is determined using the following rules:

  • uses the project type specified on the request processor;

    • the business partner contact has the same email address as the one in the From email address from the notification;

    • must be active;

    • must be open (not processed);

    • must be valid for the current date;

  • If there are multiple projects that follow the rules above, the one with a higher ID value will be used.

• Email Address - destination email for notifications that will be sent when the inbound email processor fails to process email messages;

Inbound Email Processor Functionality

Once defined, the processor can be activated by accessing the Service Monitor window and pressing the Start All button.

The request processor will access the inbound email account and read all the email messages (read and unread). For every email the processor will do the following:

• Verifies if for the From email address there is a corresponding user (at tenant level). If not the message is not processed.

  • starting v15.09 the possibility to manage failed messages has been added, in order to successfully be able to convert them into requests;

  • all failed messages can be found in the not processed inbound email window, from where the user can view and fix the cause of processing failure and attempt to reprocess the messages individually;

  • below is a list of common causes of processing failure and their respective fix:

    • address not found among st SocrateCLoud users ->

      • define a contact with the respective address;

      • reset cache server+client;

      • reprocess the message.

    • uale to determine mandatory request properties ->

      • verify the inbound email processor parameters;

      • check for a active project for the respective business partner, of project type indicated in the inbound email processor (as described above for project type field);

      • check the necessary settings for operating the corresponding request type;

• Verifies if the message is a reply or not:

  • If the message is a not a reply, a request is created using the following values:

    • Organization, Request Group, Request Type, Request Category, Request State - according to the values specified when defining the request processor.

      • Business Partner - corresponding to the contact using the From email address

    • Subject - message subject

    • Summary - message text

    • Attachments - email attachments

    • PB Notification Email - adds all the addresses from the source message, from "To:" and "Cc:" (v15.09) - request action notifications will be sent to the emails when using the "Partner"confidentiality level;

    • Project - is determined using the following rules:

      • uses the project type specified on the request processor;

        • the business partner contact has the same email address as the one in the From email address from the notification;

        • must be active;

        • must be open (not processed);

        • must be valid for the current date;

      • If there are multiple projects that follow the rules above, the one with a higher ID value will be used.

    • The system will generate email notifications for the request creation according the standard rules.

  • If the message is a reply, the first email ID from the reference is used to identify the request. If no corresponding request is found the message is not processed. If found a an action will be added with the following values:

    • • Result - message text;

      • Action date - current date;

      • Created By - contact in the From address;

      • Attachment - any email attachments are added to the request

    • The system will generate email notifications for the action according the standard rules.

  • If successful the message will be moved to a folder called "Processed". If the processing was unsuccessful the message will be moved to a folder called "Failed". The folders will be created automatically.

Request Processor Setup

Request Processors are required to generate allocations, escalations and alerting rules based on specific events or request data.

The Request Processor window, located in the System Admin -> General Rules -> Server menu, can be used to define multiple "processing models", each with their own separate running parameters (request type, frequency, etc.). Depending on the parameter values used to define a processor, you need to follow the steps described in 1.1-1.4 for each of the defined processors.

Once defined, the processor can be activated by accessing the Service Monitor window and pressing the Start All button.

Processing Rules

1.1. Update/Allocate Representative

This step is where all the requests are processed:

• without a representative;

• unprocessed (non-completed/not closed);

• filtered by Request Type from the Request Processor definition (only if this field has been filled in).

For each separate request, you need to try to determine the representative by one of the two methods:

1.1.1. Based on Routing Rules

These rules can be defined in the Routing tab of the Request Processor window.

The rules should be gone through in the sequence order for each separate rule.

• If the Request Type on the routing rule is the one of the processed request, then the representative for the request will be the user configured on the respective rule.

• If the Request Type on the routing rule is different from the one of the processed request, or the Request Type has not been defined, you will retrieve the list of keywords (the list is defined in the Keyword field and may contain multiple words delimited by " ,;\t\n\r\f" ). If you can identify a keyword in the request summary (without taking into account the CASE in the summary or the keyword) then the representative for the request will be the user configured on the respective rule.

1.1.2. From the Request Processor

The representative for the request will be set to be Supervisor on the Request Processor.

This will be saved in the request processor log (the Log tab in the Request Processor window).

• • No unallocated Requests = if there have been no requests without a representative;

  • Allocated SalesRep = the number of requests you have managed to set the representative for;

  • Not = the number of requests without a representative and for which it was not possible to determine the representative.

1.2. Request Processing

In this step the processor generates and sends alerts based on the aging statuses of the requests, as such: