Understanding ERMS

This chapter discusses:

• Email handling.

• Unstructured and structured email.

• Email response interfaces.

• Email management response system (ERMS) processes.

• How to run and monitor processes.

Email Handling

ERMS helps you process and manage large volumes of inbound emails by:

• Moving emails from an external mail server into the PeopleSoft Customer Relationship Management (CRM) database tables.

• Identifying the sender for each email and creating an interaction so that the email is visible in the sender's 360-degree view.

• Routing each email to an agent, a worklist, or an automated process that can respond.

• Enabling agents to reroute or respond to emails that require manual handling.

• Enabling agents to associate email with other CRM objects, such as cases or leads.

• Notifying a designated person when an email has not been handled within standard response time.

Remember, email is a channel for communication; the email object in the PeopleSoft system does not duplicate CRM transactions such as cases and leads. For example, if a customer sends an email related to a product support issue, you need to associate the email with a case to access case-specific functionality such as troubleshooting scripts, solution searches, and case note tracking.

See Also

ERMS Processes

Managing Email

Unstructured and Structured Email

This section discusses:

• Unstructured email.

• Structured email.

Unstructured Email

Unstructured emails are messages that customers send using their own email clients. The email is unstructured because the body of the email is completely free-form. Unstructured email handling consists of two phases:

1. An automated routing phase, during which an application engine process analyzes the email and performs automated actions on the email if applicable, or routes it to a group worklist.

2. An email management phase, during which agents who accept emails from their group worklists or the Multichannel Toolbar work on email response.

Automated Mail Processing and Routing

When an email arrives, the ERMS system performs some automated action on it or routes it to a proper group worklist depending on the information provided in the email and the availability of a third-party application that performs natural language processing.

Specifically, the system can route unstructured emails based on:

• A thread ID that is embedded in the email body.

  If you license PeopleSoft Multichannel Communications, all emails sent from the PeopleSoft system include a thread ID, also known as a context tag If a customer replies to such an email, and if the context ID appears in the reply, the system uses that ID to route the new email to the group worklist associated with the original email or its sender.

• The email address or domain from which the email was sent.

  You can define system-wide settings to ensure that emails from specific addresses or domains are handled appropriately. For example, you might configure the system so that it routes all emails from the domain ImportantCustomer.com to a worklist for priority customers.

• The email content.

  You can set up keywords, and the system scores each email based on occurrences of those keywords within the email subject and body. You associate different worklists with different sets of keywords so that the system can calculate a score for each of those worklists and route the email to the one with the highest score.

  If you license a third-party product that enables natural language processing (NLP), you can set up the system to perform actions on emails automatically based on their intentions. Automated mail processing enables you to define rules that associate the course of actions for each email intention (represented as categories). When the system sends an email to the NLP server for content analysis, the server analyzes the email content and comes up with a suggested category to return to the ERMS system. The system finds the rule that is associated with the suggested category and triggers the action from that rule to process the email accordingly.

• The sender of the email.

  The system attempts to associate each inbound email with a business object ID by comparing the sender's email address to email addresses of customers and workers in the system. If there is a match, the routing process calls your custom code, which performs the customer-based routing. PeopleSoft does not deliver any customer-based routing processing, only the infrastructure for plugging in the custom code.

Note. The system always routes the email to a group worklist rather than to an individual's worklist. This practice ensures that an individual's unavailability does not prevent the email from receiving prompt attention.

There is also a default worklist for each mailbox. The system sends email there when none of the other routing processes produce a valid worklist, when the email is oversized (and therefore cannot be analyzed), or when you configure the mailbox to bypass the other routing processes and always go directly to the default worklist.

Email Management and Worklist Integration

Only an agent who has accepted ownership of an email can modify or reply to the email. Email can be reassigned as many times as necessary. Emails are assigned to individuals only when the individual accepts ownership (either explicitly or because the system forces auto-acceptance of emails that agents view). All other assignment operations involve assignment to a group worklist.

ERMS is tightly integrated with PeopleSoft CRM worklists. When a group member accepts ownership of an email, the system moves the corresponding worklist entry from the group worklist to the individual's worklist. Similarly, if an email is sent to a group worklist (the original worklist or any other one), the system moves the corresponding worklist entry to that group worklist. Users cannot mark the worklist entries complete until the corresponding email has been closed.

Every inbound email has a status; you can track which emails require work and which are complete. Until an email is closed, an agent who accepts ownership of an email can:

• Review the email and access additional customer information by opening the 360-degree view directly from the email workspace.

• Modify email information, such as the email contact, the email's parent in a thread, the email subject, and the email status.

• Create and remove relationships between the email and other transactions.

• Write a reply, optionally using a predefined correspondence template as the basis for the email text.

See Also

Understanding Unstructured Email Routing

Managing Email

Structured Email

Structured emails are sent when a customer submits information through a web page by using a form called a webform. The body text of a structured email is formatted in XML then plain text, which enables the NLP system to analyze content and the rules engine to perform automated mail processing, including sending an automated response or creating a case.

Your organization is responsible for constructing webforms that gather the appropriate data. You must also ensure that the webform formats the resulting email appropriately and sends it to an ERMS mailbox. To process the structured email, the rules engine of automated mail processing (AMP) finds a rule for the email with matching category and trigger actions of this rule to process the email automatically.

These webforms are not part of the PeopleSoft environment, so you must deploy them separately (for example, by setting up web servers and so on).

Note. PeopleSoft self-service pages are not webforms; they provide a direct interface with CRM tables, and they do not use email to transmit information.

See Also

Understanding Structured Email

Email Response Interfaces

An email response is a reply to a customer's email. To send the reply, the system leverages correspondence management features that are common to all PeopleSoft CRM applications. This enables you to use correspondence templates to streamline the response process and standardize the text of responses.

Automated responses (those sent in response to structured email) are always based on correspondence templates that you define.

Manual responses (those that a user writes in response to unstructured email) can be either free-form or template-based. There are several interfaces for creating a manual response:

• If you initiate a reply from the context of a specific email in the email workspace, the Response page of the same email workspace component is used.

• If you initiate a reply from the context of a transaction (such as a case), one of the following occurs:

  • If you open a transaction and click the Email button (in some cases it is the Send Email button) on the toolbar, the Outbound Email page appears, and it displays information about the transaction on the left of the page.

  • If you open a transaction from an email and click the Email button on the toolbar of that transaction, the Outbound Email page appears if the user selects to create an email with no association with any email (start a new thread).

  • If you open a transaction from an email and click the Email button on the toolbar of that transaction, the Response page appears if the user selects to create an email in relation to an email (either the email that the transaction was navigated from, or any email that's associated with the transaction).

  • If you click the Notification button (in some cases it is the Notify button) on the toolbar, the Send Notification page appears.

    The user can send worklist notification to internal recipients or email to both internal and external recipients.

The interfaces of the Outbound Email component and email workspace are similar. The Outbound Email page functions the same as the Response page in the email workspace, except that you cannot search for solutions or documents and therefore cannot attach them in the email reply. The Thread and Note pages in these two components are the same. The email workspace provides a complete solution to manage email, which ranges from reviewing the inbound email, doing research to resolve the issue, responding to the inbound email, as well as reassociating email to another email thread. The Outbound Email component focuses on the response aspect of email management. You use it to send emails that typically don't have relation with other emails. Access the component to review a list of emails that are sent from the system.

See Also

Sending Manual Notifications

Understanding Correspondence and Notifications

Email Replies

ERMS Processes

ERMS uses application engine processes to fetch, route, and monitor inbound email.

This section discusses:

• High-level process flow.

• The mail reader process.

• The mail route process.

• The scheduler process.

• The email alert process.

• Process instantiation.

• Email process states and incompletely processed email.

• Processing statuses for the unstructured email process.

High-Level Process Flow

The ERMS system comprises of these processes:

• The mail reader process.

  The mail reader process (RB_MAIL_READ) does all of the basic email handling that is common to both structured and unstructured email. Among other things, it fetches emails from external mail servers, saves the data in the PeopleSoft system, identifies email senders, associates relevant mailbox data with emails, and classifies emails as structured or unstructured.

• The mail route process.

  The mail route process (RB_MAILROUTE) is responsible for analyzing and routing emails. It checks emails' eligibility for address or domain-based routing, customer-based routing, and thread-based routing. It carries out necessary email processing based on the email type (structured or unstructured) and the availability of NLP (natural language processing). At the end, either some actions are preformed on emails automatically or they are routed to appropriate group worklists to be processed by agents.

• The scheduler process.

  The scheduler process (RB_CHECKUQ) determines whether any emails are awaiting further processing. If there are unstructured emails and NLP is unavailable, it schedules the unstructured content analysis job (PRCEMAIL), which includes the following two processes.

  • The build collection process (RB_SRCH_BLD), which builds a Verity search collection that contains the unstructured emails awaiting processing. The collection is used for content-based routing that Verity uses.

    This process also updates the email tables to identify the emails that it builds into the collection.

  • The mail route process, which analyzes and routes emails.

  If there are structured emails waiting to be processed, only the mail route process is scheduled because these emails don't go through content-based routing using Verity.

• Email alert process.

  Two application engine processes make up the email alert process. Together, these processes monitor email due dates and send notifications when emails are not closed in time. The two processes are:

  • The time out process handler process (RB_SLA_SCHDR), which evaluates email due dates and statuses and schedules future notifications as necessary.

  • The time out notification process (RB_SLA_NOTIFY), which confirms email due dates and statuses for each notification and sends immediate notifications.

The following process flow illustrates how these processes work together to handle email sent to an organization:

ERMS high-level process flow

See Also

ERMS Processes

The Mail Reader Process

The mail reader process performs the following operations:

1. Schedules its own next instance.

   Because this is the first operation performed, the next instance runs even if the current instance fails.

2. Determines whether the last instance of the mail scheduler process was able to schedule its own next instance, and if it wasn't, the mail reader process schedules an immediate instance for it.

   Unlike all other ERMS processes, the scheduler process does not schedule its own next instance until the mail route process is complete. Therefore, a process failure could prevent future instances from being scheduled, if the mail reader process didn't check for this condition.

   You can also use standard PeopleSoft Process Scheduler functionality to set up process-related notifications to alert an administrator of process failures.

3. Identifies the mailboxes to be polled.

4. Fetches emails from the external mail server.

   The number of emails that the system fetches depends on the commit frequency that you set on the System Installations page.

5. Identifies exception emails and discards them.

   Exception email is any email, structured or unstructured, that meets the mail-filtering criteria. When you set up ERMS, you can define addresses and domains to be automatically filtered. You can also create application classes to perform additional mail filtering.

   Summary information about filtered email is stored in the exception email tables; your filter definitions determine whether the body text of the email is stored as well.

   Note. Because no further processing is performed on exception emails, the following steps apply only to valid emails.

6. Saves data to PeopleTools email tables using PeopleTools ERMS application programming interfaces.

   The PeopleSoft system deals with only two constructs—plain text and attachments. Any Multipurpose Internet Mail Extension (MIME) parts other than plain text, such as HTML areas and graphics, make emails no longer purely plain text and cause the part containing that construct to be stored as an attachment in the PeopleSoft system. The mail client of the sender determines the MIME format of an email.

   See Enterprise PeopleTools PeopleBook: PeopleSoft MultiChannel Framework

7. Authorizes attachments in case emails have attachments.

   PeopleTools secures all attachments. During this step, the mail reader process authorizes anyone with access to the Inbound Email component to view all of the email's attachments.

8. Classifies email as structured or unstructured, and saves a pointer to the email in either the unstructured email queue or the structured email queue.

   The mail route process looks at these queues to determine which emails to process, and deletes the pointers when processing is complete.

   Email is classified as structured if the <?xml version="1.0"?> and <WEBFORM_TEMPL_ID> XML tags appear in the email body. All other email is unstructured.

9. Analyzes the sender's email address to identify the sender.

   If the sender cannot be identified as a known customer or worker, the mail reader process performs one of these actions based on the mailbox configuration:

   • Associates the email with the unknown user business object that you choose in the System Installations page when you set up ERMS.

   • Creates a new user based on the setting of the business unit that the mailbox associates with. The role type of the new user matches the type of the mailbox, which means that the user has the role of consumer if the mailbox type is external, and worker if the mailbox type is internal.

10. Saves data to the main CRM email table.

    The CRM email table includes a pointer to the PeopleTools table and contains additional CRM-specific fields. The component interface that is used to store the data in the CRM table performs certain additional processing:

    • Creates an interaction for the email.

      See Working with Interactions.

    • Calculates when the mailbox-level warning and final notifications should be sent and saves this information to the CRM email table.

11. Deletes email from the external mailbox.

    This does not happen until after the email is saved to the CRM database. This protects you from data loss in case of a process failure.

12. Updates processing statistics.

    For each instance of the mail reader process, the system tracks the number of exception, structured, and unstructured emails processed overall and for each mailbox.

The following diagram illustrates this flow:

Process flow for the mail reader process

The Mail Route Process

The mail route process performs the following operations on structured and unstructured emails:

1. If the mailbox is not configured for automatic routing, all emails are routed to the default group worklist. If the mailbox is configured for automatic routing, this process routes the email based on an analysis of its individual characteristics. First, it checks to see if the address or domain based routing applies to emails and route them accordingly.

2. Then, it checks to see if the customer-based routing applies to emails and route them to the group worklist specified in the custom application class code.

3. It checks to see if emails are threaded. If yes, they are routed to the same group worklist to which the previous inbound email was sent.

4. It processes emails based on their classification, structured or unstructured.

   • If the email is structured, the process converts the email from XML to plain text and extracts the email subject and body based on the webform and email workspace field mapping.

     If the system is configured to always use the default category, the process looks up the category from the webform definition and finds the associated rule that is used to trigger automated actions for that email. If this option is not selected, the process next checks the availability of NLP.

     If the NLP server is present, the process sends the identified email subject and body for content analysis. The rules engine of AMP (automated mail processing) takes the NLP-suggested category and threshold values, finds a matching rule and trigger automated actions. If the NLP server is unable to return a suggested category, or it is unavailable, the default category is used.

   • If the email is unstructured and NLP is available, the email is processed the same as any structured email when NLP is present. If NLP does not return any category, the email is routed to the default group worklist.

     If NLP is unavailable, the email goes through content-based routing that is performed by Verity.

5. It performs the following post-routing operations:

   • Sends an auto-acknowledgement email to the sender, if the mailbox is so configured.

   • Deletes successfully processed emails from the email queue.

   • Establishes thread associations if the mailbox's automatic routing setting prevented the associations from being established during routing analysis.

6. The mail route process schedules the next instance of the scheduler process.

Please refer to the Setting Up Automated Mail Processing chapter for more information on AMP and the flow diagram of the mail route process.

See Also

Understanding Unstructured Email Routing

Understanding Structured Email

Understanding Automated Mail Processing

The Scheduler Process

This section provides a high-level overview of the scheduler process. Additional details about the email analysis and routing steps are provided in the documentation for setting up unstructured email routing rules.

See Understanding Unstructured Email Routing.

The scheduler process performs the following operations:

1. It reviews the data in the email queue.

   Note. If there are no emails in the queue, the scheduler process schedules its own next instance, and the process ends. This ensures that the system does not attempt to build the Verity collection when there is no data to be added to the collection—a condition which would cause an error in the build collection process.

   If there are emails in the queue, the scheduler process removes all emails with a status of Successfully Processed, and then it changes the status of any remaining emails to Ready for Processing. This ensures that emails that were partially processed (those with a status of Verity Collection Built or Processing) are ready to be reprocessed.

2. It schedules unstructured content analysis job that consists of the build collection process and the mail route process, if there are unstructured emails and NLP is not available.

   Only the mail route process is scheduled if NLP is available in the system, or if there are only structured emails in the queue.

3. The build collection process creates a search collection containing data from all unstructured emails.

   Each instance of this process overwrites the previous search collection (unless it is still in use, in which case the new collection is not built until the previous one is released).

   Note. This process applies to the Verity-based content analysis. If NLP is enabled, the system skips this build collection process.

4. The mail route process analyzes and routes the email based on its content. The process flow changes slightly with the availability of NLP. Refer to step 4 of the mail route process section above for more information.

   If the process is unable to route an email based on its individual characteristics, the process routes the email to the default worklist for the mailbox.

The following diagram illustrates this flow:

High-level process flow for the scheduler process

The Email Alert Process

Every email has up to four associated notification times that the Email Alert processes monitor:

• Mailbox-level warning and final notification times are established when the email is saved to the PeopleSoft CRM email tables.

  The system calculates these times from the time that the external mail server receives the email. The mailbox metrics change every time an email is reassigned to a different mailbox.

• Worklist-level warning and final notification times are established when an email is routed to a group worklist.

  The system calculates these times from the time the email is routed to the group worklist. The group worklist metrics change every time an email is reassigned to a different group worklist, and that is why individual assignments must always be associated with a group worklist.

The Email Alert processes perform the following operations:

1. The Time Out Process Handler process schedules its own next instance.

2. The process identifies email that has one or more notifications scheduled to occur before the next instance of the process (the one that was just scheduled).

3. The process identifies emails with statuses other than Cancelled or Completed.

   Emails that have been canceled or completed are ignored because alerts are intended to notify users of email that is still pending.

4. For email that is not canceled or completed, the process uses the notification time stored on the email record to schedule the Time Out Notification process.

   The system schedules the notification process using a run control that includes the email ID.

5. When the Time Out Notification process runs (at the scheduled notification time), it does the following:

   1. Verifies that the email is still not canceled or completed.

      If the email is canceled or completed, the process ends without sending any notifications.

   2. If the email is not canceled or completed, sends a notification.

      First, the system determines whether the email is assigned to a group worklist. If it is, all notifications (mailbox-level and worklist-level) go to the group worklist owner. If the email is not assigned to a worklist, there are no worklist-level notifications, and any mailbox-level notifications go to the mailbox owner.

The following diagram illustrates this flow:

Process flow for email alerts

Process Instantiation

The mail reader process is the master controller for all ERMS processes. In addition to performing basic operations common to all emails, this process schedules the first occurrence of each of the other ERMS processes and also schedules its own recurrences.

The mail reader process recurrence frequency is based on the polling frequencies of all active mailboxes. The first time the mail reader process runs, it processes all mailboxes. It then calculates the next polling time for each mailbox and schedules future processing times accordingly. If an instance is already scheduled at the appropriate time, an additional instance is not scheduled.

For example, suppose that you have three active mailboxes. The polling frequencies are 10 minutes for mailbox A, 15 minutes for mailbox B, and 20 minutes for mailbox C. If you start the first instance of the mail reader process at 12:00, it reads mail from all three mailboxes and then schedules future instances for 12:10, 12:15, and 12:20. The 12:10 instance reads mail from mailbox A and then determines that the next time to check mailbox A is at 12:20. Because an instance of the process is already scheduled for 12:20, another instance is not scheduled. When the 12:20 instance of the process runs, it reads mail from both mailbox A and mailbox C.

The first instance of the mail reader process also schedules the first instance of the scheduler process and the email alert process. Each of these processes then schedules its own next occurrence based on intervals that you define.

The following diagram shows how certain ERMS processes trigger others:

Process instantiation flow

See Also

Understanding ERMS Setup

Email Process States and Incompletely Processed Email

As the ERMS processes handle an email, they maintain process state information. The process state indicates how far along the automated processing is.

Before an email is completely processed, its process state can be:

• Email Instance Created: the initial state of an email after it is saved to the PeopleSoft CRM email tables and before any additional processing occurs.

• Queued for Routing: the Mail Reader process (RB_MAIL_READ) has finished with email, and the email is queued to be processed as an unstructured or structured email.

• Mailbox Forwarding: the mailbox reset operation is performed.

After an email is completely processed, its process state can be:

• Auto Responded By System: the email process sent an automatic response.

• Email Routed: the structured email process has routed the email to a group worklist.

The process state is visible on the Message Details page of the email workspace only if the email is not completely processed. Users might access incompletely processed emails under two conditions:

• A user accesses the email between the time the mail reader process saves it to the CRM email tables and the time the appropriate email handling process completes its processing.

• The email process fails.

In both situations, the email can be accessed only through the menu navigation to the Search Inbound Emails component: incompletely processed emails do not appear in worklists or the Multichannel Toolbar. Agents who interact with emails only through the Worklist or the Multichannel Toolbar will normally never even see incompletely processed emails.

Only the email's mailbox owner can work with incompletely processed emails. (Although the email's group worklist owner has the same privileges as the mailbox owner, incompletely processed emails do not have a group worklist owner because they have not yet been assigned to a group worklist.)

To handle an incompletely processed email, the mailbox owner:

1. Accesses the email in the email workspace.

2. Verifies the process state.

3. Enters sender information, if necessary.

   Depending on which process failed, and when, the sender information may already be present.

4. Establishes a thread association.

   Depending on which process failed, and when, the thread association may already be established.

5. Changes the process state to Email Routed.

   This prevents the next instance of the email process from attempting to reprocess the email.

6. Clicks the Reassign button and send the email to the appropriate group worklist.

   This saves changes to the email.

See Also

Email Status Tracking

Processing Statuses for the Unstructured Email Process

Email that is placed in the unstructured email queue has an additional status tracking field (different from the overall process state) that indicates how far along the unstructured email process is. Each email in the unstructured email queue has one of these statuses:

• 0: Ready for processing.

• 1: Verity collection built.

• 2: Processing.

• 3: Successfully processed.

When the mail reader process first creates an entry in the unstructured email queue, it assigns status 0 (ready for processing). When the unstructured email process runs, it updates the status.

Each instance of the unstructured email process picks up all emails with statuses other than 3 (successfully processed). This practice ensures that a future instance of the unstructured email process will attempt to reprocess any emails that are not successfully routed.

The unstructured email process status is not visible from the email workspace. To view this data, you must query the database.

Running and Monitoring Processes

This section discusses how to:

• Review process settings for mailboxes.

• Start and stop ERMS processes.

• Review Mail Reader processing details.

Pages Used to Run and Monitor Mail Reader Processes

Reviewing Process Settings for Mailboxes

Access the Mailbox Viewer page.

The Mailbox Definitions View grid lists all ERMS mailboxes. The grid columns correspond to the identically-named fields on the Mailbox Definitions page. You can edit only the fields that affect the Mail Reader process. Changes you make on this page also appear on the Mailbox Definition page.

See Also

Defining Mailboxes

Starting and Stopping ERMS Processes

Access the Start/Stop ERMS Batch Process page.

Start ERMS System

Click to schedule the Mail Reader process, which in turn schedules all other ERMS processes. Each ERMS process schedules its own next instance, so the ERMS processes continue to run at the intervals you've defined until you stop the ERMS system. Note. When starting the ERMS System, you need to be logged in as the same user who set the Verity Run Control information at Set Up CRM, Product Related, Multichannel Definitions, Email, System Installation. You will receive an error message if trying to start the ERMS system while logged on as a different user.

Stop ERMS System

Click to cancel all current and future instances of ERMS processes. It is not necessary to stop the ERMS system when you make changes to a mailbox's status or polling frequency.

Reviewing Mail Reader Processing Details

Access the Mailreader Process Monitor page.

Process Instance Selection

Use the fields in the View For Status and View Mail Reader Logs/Request Details For group boxes to specify the Mail Reader instances that you want to review.

Mail Reader Process Details

See Also

Defining Mail Filters

Enterprise PeopleTools PeopleBook: PeopleSoft Process Scheduler

Reviewing Detailed Process Information

This section discusses how to:

• Review mail reader statistics.

• Review exception email.

Pages Used to Review Detailed Process Information

Reviewing Mail Reader Statistics

Access the Mail Reader Process Log page.

Mail Reader Statistics

Mail Box Details

This grid lists the mailboxes that were processed and, for each mailbox, displays the number of structured, unstructured, and exception emails that were processed.

Exception Emails

This grid lists the exception emails that were processed by this Mail Reader instance.

Reviewing Exception Email

Access the Exception Email Details page.

Several of the fields on this page are the same as the identically-named fields on the Mail Reader Process Log page.