SimpleOne provides two-way interaction via email:

  • sending notification emails about what happens in the system (including announcements, events, and updates of records and tables)
  • automatic execution of actions in the system depending on incoming emails.

In SimpleOne, email processing can be automatic within the system without third-party applications.

In the following article, you will learn:

  • How to configure email accounts.
  • How to create automatic actions in the system (updating or creating records in specified tables) depending on the email you received (its body, topic, addresses, etc.).
  • How to customize automatic email replies depending on values of specific records and received emails.
  • How to notify users about what happened within the system.

Email Accounts


First of all, create necessary email accounts. It can be a pre-configured account with the IMAP protocol (for receiving emails), SMTP protocol (for sending emails), and POP3 protocol (for receiving emails). 

It is better to use IMAP protocol than POP3 to receive emails because POP3 is slower and outdated.

The email account configuration includes the following steps:

  1. Creating an email account
  2. Testing the connection (optional)
  3. Configuring default settings.

Notifications


Notification rules help automatically send emails depending on the state of specific records. Notification rules allow you to define when to send an email, who will receive it, and what the message text will contain.

For example, when an incident changes to the Information Needed state, the system can send an email with a specific subject and body to specific recipients. That is, notifications define who will receive information about specific changes in the system, and the set of that information.

SimpleOne provides some notification rules out-of-the-box. Refer to the Available Notifications article to see the preconfigured notifications that you can use, or copy them as templates for your new ones.


Inbound Email Actions


Inbound Actions are rules that define how the system should react to emails it receives. Available reactions are:

  • send an automatic reply
  • create, update or delete a record in the system.

Use a script to define how the system will respond to certain triggers – this could be a specific email topic, keywords in its body, or more complex conditions. Unlike Notification Rules, inbound email actions provide a way to interact with records in the system.

For example, while processing an incident in the Information Needed state, the system will insert the body of this email to the Additional Comment field in the Activity Feed when the caller sends their response. The condition is that the caller's email contains a specific text in its subject, and the task number it includes matches the one in the incident record. That is, the inbound email action defines what happens in the system after receiving an email.



Refer to the Inbound Email Actions article to find more detailed information about creating and configuring Inbound Actions.

Inbound Action chain


Inbound Action includes three major groups of parameters:

  • Action to execute when an email is received. It is defined with a script.
  • The condition that an email should meet for the action to be executed.
  • Parameters that control the processing flow.

The third group of parameters is required to organize multiple Inbound Actions in a way that they check an incoming email to match the condition defined in each of them, in a certain order. The less is the value in the Order field of an Inbound Action, the earlier this Inbound Action checks if a received email matches its execution condition. As a result, each email goes through an ordered chain of condition checks, from the Inbound Action with the least Order value to the one with the biggest, with the following processing logic: 

  1. If an Inbound Action has the Active checkbox disabled (its value is set to 'false'), this Inbound Action is skipped. Inbound Actions with the Active checkbox enabled (its value is set to 'true') are processed further.
  2. If an email matches no condition of any Inbound Action, it passes all the way down the processing chain.
  3. If the condition of an Inbound Action is matched, the execution of the action script of that Inbound Action starts. The further processing flow depends on the value of the Stop processing checkbox of this Inbound Action:
    • If the checkbox is not selected, the email is checked to match the condition of the next Inbound Action down the chain, and the logic proceeds from Step 2 again.
    • If the checkbox is selected, the rest of the Inbound Actions down the chain are skipped, and the processing chain is terminated. 

As a result, one inbound email can trigger execution of none, one or several action scripts in a row, depending on the values of the Active, Order and Stop processing fields in each Inbound Action defined in the system.