Email typical flow

Last Updated : Jun 05, 2026 |

Inbound message with reply

The flow of a typical incoming email consists of the following steps:

  • The incoming email message is routed through the Internet to an email server. For example, Microsoft Exchange.

  • Email Processor monitors the mailbox on the email server and detects a new message.

  • Email Processor launches the Orchestration Designer email application on an application web server based on To, Subject, or Header as specified in the application configuration on the EPM.

  • The email application can gain access to the details of the incoming message by examining a variable called Message that has fields related to the email message: To, From, Subject, Body, and Attachments. The Message variable is similar to the Session variable, but only contains fields related to a message, such as email and SMS messages.

  • The Orchestration Designer application can generate a reply using the Prompt tag mechanism or generate a new outbound email by using the Orchestration Designer notification connector. Both methods trigger the Orchestration Designer runtime to send an email message to Email Processor.

Note:

Experience Portal supports two types of inbound email messages:

  • Regular

  • Delivery Status Notification (DSN): This type of message might be generated by any email server that processes the message before reaching the final destination.

Outbound message

The Application Interface Web service is enhanced to provide a launchEmail method and a sendEmail method.

The launchEmail method is a web services request that calls an email application. The launchEmail web service request succeeds when the Orchestration Designer application begins to run. The launched Orchestration Designer application sends an email message by invoking the notification connector. After the message is sent, a sendEmail web service call is created.

The sendEmail method enables an application that can make web service calls to send an email message to an email server through Email Processor. The web service call succeeds when the Email Processor has accepted the message. An email application can be notified when an email message is delivered to the email server. This status is sent to the Notification URL that is specified when configuring the email application on the EPM. An application can be further notified of any errors that occur after the email server has accepted the message. These email DSN message types are sent to the application if the application was configured to support either Delivery or Regular and Delivery message types. Voice applications that call sendEmail must specify the name of a configured email application in order to receive error notifications.

Note:

An Email Notification Connector is a pluggable data connector that is used to send an email message from a speech application or a message application that is created for a channel other than the email channel.

Notifications are done through the configured applications. An application can be configured by short code that can have an application URL which is launched by Email Browser when notifications are received. The email server relies on the SMTP delivery status notification mechanism to support the registered delivery of email messages. The Email Processor submits the SMTP delivery notifications as requested by the client. On receiving the delivery receipt from SMTP, Email Processor stores all the information from the message in the delivery receipt record so that Email Browser can make that information available to the delivery receipt application, see the Orchestration Designer documentation.

For more information on these new web service methods, see: