Email HandlingThis chapter discusses:
Email handling.
Unstructured and structured email.
Email responses.
Email management response system (ERMS) processes.
Email HandlingERMS helps you manage large volumes of inbound email by:
Moving email from an external mail server into the PeopleSoft Customer Relationship Management (CRM) database tables.
Identifying the email sender and creating an interaction so that the email is visible in the sender's 360-degree view.
Routing email to a person or an automated process that can respond.
Enabling users to reroute or respond to emails that require manual handling.
Enabling users 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
Unstructured and Structured Email
This section discusses:
Unstructured email.
Structured email.
Unstructured EmailUnstructured 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:
An automated routing phase, during which an application engine process analyzes the email and assigns it to a group worklist or queue.
An email management phase, during which users work on and reply to emails.
Because the system cannot interpret the intent of an unstructured email, the system routes the email to worklists so that people can review the email and reply to it. 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.
The system can route unstructured email 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 ID. 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 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 worklist and route the email accordingly.
If you license the third-party Banter server product that enables natural language processing (NLP), you can set up the system to perform actions on emails automatically based on the email intention. The 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 NLP, the framework analyzes the email content and comes up with a suggested category that's returned to the email system. The system then finds the rules that are associated with the suggested category and triggers the most eligible action with the highest priority.
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 address records for customers and workers. 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.
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 so that 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 Inbound Email component.
Modify certain email fields, 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
Defining Unstructured Email Routing Rules
Structured EmailStructured 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, which enables the PeopleSoft system to parse the data and perform automated processing, including sending an automated response.
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 ERMS passes information to an application class that you associate with a webform ID that is embedded in the email. The application class performs any necessary processing and passes back information that the ERMS uses to send a response.
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
Defining Structured Email Handling
Email ResponsesAn 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, and 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. If you are a supervisor who receives email approval notifications, you go to the Outbound Email component to approve or disapprove emails before the system delivers them to recipients.
See Also
ERMS ProcessesERMS uses application engine processes to fetch, route, and monitor inbound email.
This section discusses:
High-level process flow.
The Mail Reader process (RB_MAIL_READ).
The Unstructured Email process (RB_STR_EMAIL).
The Structured Email process.
The Email Alert process.
Process instantiation.
High-Level Process FlowThere are four main ERMS processes:
The Mail Reader process does all of the basic email handling that is common to both structured and unstructured email. Among other things, it fetches email from external mail servers, saves the data in the PeopleSoft system, and classifies the email as structured or unstructured.
Three application engine processes make up the Unstructured Email process. Together, these processes enable the system to analyze unstructured emails and route them to group worklists based on the routing rules that you establish. The three processes are:
The Unstructured Scheduler process (RB_CHECKUQ), which determines whether any unstructured emails are awaiting further processing.
If there are, the Unstructured Scheduler process then 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.
This process also updates the email tables to identify the emails that it builds into the collection.
The Unstructured Content Analysis process (RB_MAILROUTE), which analyzes and routes unstructured email.
This process also establishes thread associations, and it sends acknowledgements for emails from mailboxes that are configured for acknowledgements.
This process parses structured email, passes information to the application class that is responsible for interpreting the data, and then sends an email response based on information passed back from the application class.
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 following process flow illustrates how these processes work together to handle email sent to an organization:
ERMS high-level process flow
See Also
The Mail Reader Process (RB_MAIL_READ)The Mail Reader process performs the following operations:
Schedules its own next instance.
Because this is the first operation performed, the next instance runs even if the current instance fails.
Determines whether the last instance of the Unstructured Email process was able to schedule its own next instance, and if it wasn't, the Mail Reader process schedules an immediate instance of the Unstructured Email process.
Unlike all other ERMS processes, the Unstructured Email process does not schedule its own next instance until it finishes processing. 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.
Identifies the mailboxes to be polled.
Fetches email 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.
Identifies exception emails and discards them.
Exception email is any email, structured or unstructured, that meets the mail-filtering criteria. When you set up the 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.
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 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 8.45 PeopleBook: PeopleSoft MultiChannel Framework
Authorizes attachments in case the email has 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.
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 Unstructured Content Analysis job and the Structured Content Analysis process look at these queues to determine which emails to process, and they delete 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.
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 the 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.
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.
Calculates when the mailbox-level warning and final notifications should be sent and saves this information to the CRM email table.
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.
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 Unstructured Email Process (RB_STR_EMAIL)This section provides a high-level overview of the Unstructured Email process. Additional details about the email analysis and routing steps are provided in the documentation for setting up unstructured email routing rules.
See Defining Unstructured Email Routing Rules.
The processes that make up the Unstructured Email process perform the following operations:
The first process, the Unstructured Scheduler process, reviews the data in the unstructured email queue.
Note. If there are no emails in the queue, the Unstructured 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 Unstructured 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.
The Unstructured Scheduler process schedules the Unstructured Content Analysis job, which consists of the Build Collection process and the Unstructured Content Analysis process.
The Build Collection process creates a search collection containing data from all emails in the unstructured email queue.
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.
The Unstructured Content Analysis process (the second process in the job) analyzes and routes the unstructured email.
If the mailbox is not configured for automatic routing, all email is routed to a single default worklist. If the mailbox is configured for automatic routing, this process routes the email based on an analysis of its individual characteristics. This routing can be based on the email's threading information, the customer who sent the email, the sender's email address or domain, or the email content. Content-based routing leverages natural language processing to perform actions (which can include automatic routing) if the system supports the integration with the Banter server, or the Verity collection if the integration is not available.
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 Unstructured Content Analysis process 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 unstructured email queue.
Establishes thread associations if the mailbox's automatic routing setting prevented the associations from being established during routing analysis.
The Unstructured Content Analysis process schedules the next instance of the Unstructured Scheduler process.
The following diagram illustrates this flow:
High-level process flow for unstructured email
The Structured Email ProcessThis section provides a high-level overview of the process for handling structured email. For details about the process flow, refer to the documentation for setting up structured email handling.
See Defining Structured Email Handling.
The Structured Content Analysis process performs the following operations:
Schedules its own next instance.
Fetches emails from the structured email queue.
Finds the webform ID of the email.
If the webform ID is invalid, or if the body of the email contains malformed XML, sends a notification to the mailbox's administrative worklist.
In the testing environment, this helps you determine whether the webforms are sending properly constructed email.
If the webform ID is valid, calls the application service that is associated with that webform ID.
Based on the output from the application service, invokes correspondence management to send an automated reply.
After all emails are processed, deletes all of the processed emails from the structured email queue.
The following diagram illustrates this flow:
High-level process flow for structured email
The Email Alert ProcessEvery 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:
The Time Out Process Handler process schedules its own next instance.
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).
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.
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.
When the Time Out Notification process runs (at the scheduled notification time), it does the following:
Verifies that the email is still not canceled or completed.
If the email is canceled or completed, the process ends without sending any notifications.
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 InstantiationThe 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 Unstructured Email process, the Structured Email 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