Understanding ERMS

This chapter provides overviews of email handling, unstructured and structured email, email response interfaces, email management response system (ERMS) processes, and Customer Data Hub (CDH) impact on ERMS. It also discusses how to:

• Run and monitor processes.

• Review detailed process information.

• View email error logs.

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.

   The system sends the email directly to the default group worklist of the associated mailbox if the automatic routing option is disabled.

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.

The ERMS system routes an unstructured email to a relevant group worklist based on the information provided in the email. Information used in the evaluation process includes:

• 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.

• 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.

Each mailbox is associated with a default group worklist. An email is routed to the default group worklist under these situations:

• None of the routing processes returns a valid group worklist to which the email can be sent.

• The email is oversized (and therefore cannot be analyzed).

• The mailbox to which the email belongs is set up to not perform automatic routing.

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

A structured email is sent when a user 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 Verity system to analyze content and return for the email a category and a score value, if the webform definition is not set to use the default category to apply automated mail processing (AMP) rules. Using this information, the AMP rules engine 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). Your organization is responsible for constructing webforms that gather the appropriate data. These custom webforms must generate and format structured email properly so that they can be collected and processed by the ERMS system.

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) by clicking the Notification toolbar button, one of the following occurs:

  • If the transaction is not associated with any email, the Outbound Notification page is used.

  • If the transaction is associated with one or more email, a secondary page appears and it asks if you want to respond to any current email or send a brand new email. If it is a response, and the option to use email workspace for responding to existing notifications is selected at the system level, the Response page of the email workspace is used. The Outbound Notification page is used either if it's a new mail, or it's a response but the option to use email workspace is not selected.

The interfaces of the Outbound Notification page and email workspace are similar. The Outbound Notification page functions the same as the Response page in the email workspace, except that you cannot search for solutions or documents on the Outbound Notification page. You can, however, use the page to email solutions from cases.

See Also

Sending Manual Notifications

Finding and Attempting Solutions

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, thread-based routing and keyword-based routing. It carries out necessary email processing based on the email type (structured or unstructured). 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 emails in queue, 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 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 (RB_MAILROUTE), which analyzes and routes emails.

• 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 the mail reader, mail route, scheduler, and email alert processes work together to process emails that are sent to an organization:

ERMS high-level process flow of receiving and processing incoming email

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 PeopleTools 8.52: PeopleSoft MultiChannel Framework PeopleBook

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.

13. Checks if the system option to create case for new inbound email is selected; if yes, create cases accordingly.

14. Check if the system option to add notification as note to the associated case; if yes, add case notes accordingly.

The following diagram illustrates the mail reader flow, which classifies incoming email and stores email data in appropriate database tables:

Mail reader process flow for classifying incoming email and storing data to database tables

The Mail Route Process

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

If the incoming email is unstructured:

1. The mail route process first checks if automatic routing is enabled at the mailbox level.

2. If automatic routing is enabled, the process checks to see if the address or domain based routing applies to the email and route it accordingly.

3. If address-based routing doesn't apply, then it checks to see if customer-based routing applies to the email and route it to the group worklist specified in the custom application class code.

4. If customer-based routing doesn't apply, it checks to see if the email is threaded. If yes, it is routed to:

   • (If the Process customer response as new email option is selected at the system level) The group worklist to which the previous inbound email was routed.

   • (If the Process customer response as new email option is selected at the system level) The group worklist of the provider group, if the email is associated with a case and the case is assigned to a provider group.

   • (If the Process customer response as new email option is not selected at the system level) The group worklist to which the sender (agent) of the previous outbound email belongs.

5. If thread-based routing doesn't apply, it proceeds to keyword-based routing that is performed by Verity and routes the email to the best suited group worklist based on the predefined query and worklist association.

   See Content-Based Routing.

6. In the case where automatic routing is disabled at the mailbox level, Automated Mail Processing (AMP) is used for email routing purposes. The AMP rules engine uses Verity to search for predefined keywords (which are associated with categories) in email. For each keyword match that is found, a score is given to the associated category. As a result, email is assigned to the category with the highest score, and the rules engine can then trigger the actions that are associated with that category on the email. If the score returned for the email category does not meet the confidence level of any AMP rules for that email category, or that the email category is not associated with any rules, the system routes the email to the default group worklist of the mailbox.

   See AMP Overview.

If the incoming email is structured:

1. The mail route process first converts the email from XML to plain text and extracts the email subject and body based on the webform and email workspace field mapping.

2. It identifies the default category from the webform definition that is associated with the email.

3. It checks if the option to always use the default category is selected in the webform definition.

   If yes, the system uses the default category as the email category, looks up any AMP rules that are associated with it, and performs rule actions on the email.

   Make sure that the default category is associated to a AMP rule to apply actions. If using the default category doesn't resolve in performing any rule actions, the system routes the email to the mailbox's default group worklist.

   If no, the system uses Verity to identify the category of the structured email, just like the way unstructured email are processed when automatic routing is disabled in the system. If the returned category score does not meet the confidence value of any AMP rule associated with the category, the system routes the email to the default group worklist of the mailbox.

Lastly, the mail route 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 email queue.

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

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

Mail route process flow for routing unstructured and structured emails

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. If the queue contains emails, the scheduler process schedules the unstructured content analysis job, which consists of the build collection process and the mail route process.

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

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

4. The mail route process analyzes and routes the email based on its content. Refer to 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 graphic illustrates the scheduler process flow:

High-level process flow for the scheduler process to analyze and route emails

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 graphic illustrates the email alert flow that sends out notifications for emails reaching commitment deadlines:

Process flow for sending alert notifications for emails that are reaching commitment deadlines

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 graphic illustrates the relationship between all ERMS processes and how one process triggers the rest:

Relationship of ERMS processes and the 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.

Customer Data Hub (CDH) Impact on ERMS

After the merge of business objects occurs within the CDH, CRM receives the result of the merge and responds to the inactivation of the merge-from BO. First, CDM merges customer data and then it passes on the control to the products, including ERMS, to update the inactivated BO IDs on their transactions.

The ERMS merge process performs the following steps:

• Updates merge-from BO ID on inbound email.

• Logs before and after values for the BO ID.

Note. It is recommended that you stop the ERMS system when the merge process is expected to produce a high volume of merged BOs. This will generally be shortly after implementing CDH when the full sync is run for the first time.

See Also

Understanding Customer Data Hub Integration

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 (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Servers and Security, Batch User Monitor Form, Mailbox Viewer).

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 (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Servers and Security, Batch User Monitor Form, Start/Stop ERMS Batch Process).

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 (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Servers and Security, Batch User Monitor Form, Mailreader Process Monitor).

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

PeopleTools 8.52: PeopleSoft Process Scheduler PeopleBook

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 (Click the Mail Reader Details link on the Mailreader Process Monitor 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 (click the Details link in the Exception Emails section of the Mail Reader Process Log page).

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

Viewing Email Error Logs

This section discusses how to:

• View mailbox errors.

• View mailbox controls.

• View exception emails.

See Also

Mail Reader Error Handling Options

Pages Used to View Email Error Logs

Viewing Mailbox Errors

Access the Mailbox Errors page (Correspondence, Inbound Email Error Log, Mailbox Errors).

Use this page to view logs that are generated when an error is encountered. Logs can be searched by Mailbox ID, process instance number, and date ranges.

Viewing Mailbox Controls

Access the Mailbox Control page (Correspondence, Inbound Email Error Log, Mailbox Control).

Use this page to view the list of mailboxes that are being processed by the Mail Reader at that instance of time. When the process instance is completed, the status is set to Completed in the Tools Read Mail Status column. You can use this page to check if the Mail Reader is working properly or not. For example, if Mail Reader crashes for some reason, the mailboxes being processed would remain in In Process status and would never be picked up by another instance of Mail Reader to read mails.

This page lets you clean up stalled process. To do so, select the entries you want to remove and click the Delete Selected button. Entries with the Completed status are removed automatically by the Mail Reader once the corresponding mailboxes are processed successfully.

Viewing Exception Emails

Access the Exception UIDs page (Correspondence, Inbound Email Error Log, Exception UIDs).

The Mail Reader may encounter problems while processing emails that are fetched from mail server. When that happens, the Mail Reader stops processing those emails further and stores their UIDs into a log table so that other Mail Reader instances are aware of these problematic emails (if they are not already deleted from the mail server) and do not spend resources processing them again. Administrators can correct issues with these emails on the mail server or delete them from the mail server. When an administrator successfully corrects an email, its corresponding entry needs to be deleted from this log so that it can be processed by the Mail Reader. To remove an entry, select it and click Delete Selected button.