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:

1.2.1 Requests with Aging Status = Scheduled

1.2.2. Requests with Aging Status = Due

1.2.3. Limit Date Alert from the Request Processor

The alert will be sent for the requests that go from Scheduled to Due.

In this step, all the following requests will be processed:

    • Aging Status = Scheduled;

    • Date next action > current date (including hours, minutes, etc.);

    • unprocessed (non-completed/not closed);

  • filtered by the Request Type from the Request Processor definition - only if this field has been completed.

You must do the following for each separate request:

  • Update the Aging Status if the Date next action field has been completed, as such:

    • calculate the Limit Date to be the Date next action + Due Date Tolerance from the Request Type;

    • if the current date < Date next action then Aging Status = Scheduled;

    • if the current date is between the Date next action and Limit Date then Aging Status = Due;

    • if the current date > Limit Date then Aging Status = Overdue;

  • Verify if the Aging Status = Due and if the Request Type has the EMail when Due checkbox. If so:

    • an alert will be sent that will contain the “RequestDue” message (configured in AD_Message) according to the rules described at 1.6.

    • Request {0} - at solving due date;

    • update the Last Alert field on the request;

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

    • New Due # - the number of the request with Aging Status = Due;

    • (n Email) - n = number of sent e-mails.

The alert will be sent for the requests that go from Due to Overdue.

In this step, all the following requests will be processed:

    • Aging Status = Due;

    • Limit Date (= Date next action + Due Date Tolerance from the Request Type) > current date (including hours, minutes, etc.);

  • unprocessed (non-completed/not closed);

  • filtered by the Request Type from the Request Processor definition - only if this field has been completed.

You must do the following for each separate request:

  • Update the Aging Status if the Date next action field has been completed, as such:

    • calculate the Limit Date to be the Date next action + Due Date Tolerance from the Request Type;

    • if the current date < Date next action then Aging Status = Scheduled;

    • if the current date is between the Date next action and Limit Date then Aging Status = Due;

    • if the current date > Limit Date then Aging Status = Overdue;

  • Verify if the Aging Status = Overdue, if the Request Type has the EMail when Overdue checkbox, and if no other alert has been sent in that day. If so:

    • an alert will be sent that will contain the “RequestOverDue” message (configured in AD_Message) according to the rules described at 1.6.

      • update the Last Alert field on the request;

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

    • New OverDue # - the number of the request with Aging Status = Overdue;

    • (n Email) - n = number of sent e-mails.

This will only work if you have enter a value different from 0 in the Alert after Days Due field (expressed in days).

In this step, all the following requests will be processed:

  • Limit Date (= Date next action + Alert after Days Due from the Request Type) < current date (including hours, minutes, etc.);

    • and:

      • no alert;

      • or, with Last Alert (to which we add the number of days in the Reminder Days field in the Request Processor window, if the Reminder Days > current date (including hours, minutes, etc.));

  • unprocessed (non-completed/not closed);

  • filtered by the Request Type from the Request Processor definition - only if this field has been completed.

You must do the following for each separate request:

  • Update the Aging Status if the Date next action field has been completed, as such:

    • calculate the Limit Date to be the Date next action + Due Date Tolerance from the Request Type;

    • if the current date < Date next action then Aging Status = Scheduled;

    • if the current date is between the Date next action and Limit Date then Aging Status = Due;

    • if the current date > Limit Date then Aging Status = Overdue;

  • Verify if the Request Type has the EMail when Overdue checkbox, and if no other alert has been sent in that day. If so:

    • an alert will be sent that will contain the “RequestAlert” message (configured in AD_Message) according to the rules described at 1.6.

    • Alert: Request {0} has surpassed the waiting time.

    • update the Last Alert field on the request;

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

    • Alerts # - the number of processed requests;

    • (n Email) - n = number of sent e-mails.

1.2.4. Escalation towards the Supervisor of the Request Representative

1.2.5. Deactivated alerts

This will only work if you have enter a value different from 0 in the Escalate after Days Due field (expressed in days).

In this step, all the following requests will be processed:

  • Limit Date (= Date next action + Escalate after Days Due from the Request Type) < current date (including hours, minutes, etc.);

    • unprocessed (non-completed/not closed);

    • without the Escalated checkbox;

  • filtered by the Request Type from the Request Processor definition - only if this field has been completed.

You must verify each request and escalate only those with a defined Representative:

  • Determine the Supervisor of the Representative and if not possible, select the Supervisor on the Request Processor;

  • Send an alert containing the message “RequestEscalate” to the Representative, to the Supervisor determined above and to the users that are employees (the Business Partners that have the Employee checkbox);

    • Escalate Request {0} to {1}

  • Update the Aging Status if the Date next action field has been completed, as such:

    • calculate the Limit Date to be the Date next action + Due Date Tolerance from the Request Type;

    • if the current date < Date next action then Aging Status = Scheduled;

    • if the current date is between the Date next action and Limit Date then Aging Status = Due;

    • if the current date > Limit Date then Aging Status = Overdue;

  • Update the Escalated checkbox;

  • Add a new request with the text: Escalated Request;

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

    • Escalated # - the number of escalated requests - irrespective of whether any e-mails have been sent or not.

This will only work if you have enter a value different from 0 in the Inactivity Alert Days field (expressed in days).

In this step, all the following requests will be processed:

    • have had no actions in the inactivity range: Limit Date (= Date next action + Inactivity Alert Days from the Request Type) < current date (including hours, minutes, etc.);

  • unprocessed (non-completed/not closed);

    • with either Date next action or Updated to which we add Due Date Tolerance from the Request Type) < current date (including hours, minutes, etc.);

    • and

      • with no alert;

      • or, with Last Alert (to which we add the number of days in the Reminder Days field in the Request Processor window, if the Reminder Days < current date (including hours, minutes, etc.));

  • filtered by the Request Type from the Request Processor definition - only if this field has been completed.

You must do the following for each separate request:

  • Update the Aging Status if the Date next action field has been completed, as such:

    • calculate the Limit Date to be the Date next action + Due Date Tolerance from the Request Type;

    • if the current date < Date next action then Aging Status = Scheduled;

    • if the current date is between the Date next action and Limit Date then Aging Status = Due;

    • if the current date > Limit Date then Aging Status = Overdue;

  • Verify if no other alert has been sent in that day. If so:

  • an alert will be sent that will contain the “RequestInactive” message (configured in AD_Message) according to the rules described at 1.6.

    • Inactivity Alert: Request {0}

  • update the Last Alert field on the request;

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

    • Inactivity # - the number of processed requests;

    • (n Email) - n = number of sent e-mails.

The alert is sent to the first of the users below (if this has been defined):

    • The representative on the request;

    • The project representative corresponding to the project on the request;

    • The Supervisor from the Organization on the request.

The e-mail will contain:

    • Subject - the text received as entry parameter (the reason for the request) - you can customize this to a certain degree in AD_Message;

    • Content - the Summary of the request;

    • Attachment - you cannot currently send attachments.

The e-mail will only be sent to the users that have had defined:

    • Email Bounced = ‘N’;

    • Notification Type different from "None".

1.3. Request Status Processing (Timeout)

This step should only be covered if you have configured a Request Type for this Request Processor, or if there are any existing Request Types that have not been defined any processor.

In this step, all the following requests will be processed:

    • that have statuses which have had the Timeout in Days and Next Status fields filled in;

    • that have surpassed the Timeout in Days from the last update;

  • unprocessed (non-completed/not closed);

  • filtered by the Request Type from the Request Processor definition - only if this field has been completed; if this field has been left empty, the requests will be filtered by all the request types that have not been defined any processor.

For each request the system will try to determine the next status from the definition of the current status.

If successful, a note of the form "Expired Request Status: Current Status -> Next Status” will be added to the request and the next status will be established for the current request.

In this process you will only notify (via a standard notification mechanism for actions on request) the users that are employees (Business Partners with the Employee checkbox), except for the situation when the request status becomes Final Close.

Add to the Log (Status Timeout #) the number of requests that have had their Status fields modified.

1.4. Update Processing Log

Erase all the records in the Log that do not abide by the "Days to keep Log >= 1" policy.

Add to the Log a record containing the details of the running separated by "-".

1.5. Send E-mail/Alert