Understanding ERMS Setup
These topics discuss:
Mail servers and mailboxes.
Email handling options.
Email classification.
ERMS application engine processes.
Mail reader error handling options.
Note: These topics do not discuss routing rules for structured or unstructured email.
The ERMS system integrates with mail servers and mailboxes that you establish outside of the PeopleSoft system. You use PeopleSoft MultiChannel Framework and PeopleTools Integration Broker to manage the connection with these external systems.
You also establish mail server definitions and mailbox definitions within the ERMS system. The mail server definition is minimal: it is the name of the physical mail server. The mailbox definition is more extensive. It includes connection-related settings (such as the password that is used to access the mailbox and the frequency with which the ERMS system fetches email from the external mailbox), as well as email handling options such as:
Default group worklists to which emails are routed if no suitable group worklist is found.
Time limits after which the system sends notifications that an email has not yet been closed.
Auto-acknowledgement processing.
The from address that is to be used for automatic responses to email that comes to this mailbox.
Whether the mailbox is used for email from external customers or internal customers, which in turn controls which types of business objects can be associated with email that is sent to this mailbox.
Email that is sent to external mailboxes can be associated with consumers.
Email that is sent to internal mailboxes can be associated with workers.
Use internal mailboxes in conjunction with PeopleSoft HelpDesk or PeopleSoft HelpDesk for Human Resources.
Note: Although you use pages in the Mailbox Definition component to set up the mailbox's routing rules for unstructured email, these topics do not discuss those pages. Refer instead to the documentation for unstructured email routing rules.
See the product documentation for PeopleTools: PeopleSoft MultiChannel Framework.
In addition to the mailbox-level options, several system-wide options exist.
Business Object Associations
The mail reader process, which fetches each email from an external mailbox and saves it to PeopleSoft tables, analyzes the from address of the email and looks for a customer or worker (depending on the mailbox type: external or internal) to associate with the email.
Every inbound email must be associated with a PeopleSoft CRM business object. If the Mail Reader process cannot identify the sender, select in each mailbox definition whether it should create a user based on the email address, or associate the email with a specific person record that you've chosen to represent all unknown users. The same unknown user setting applies to all mailboxes.
Email Reply Settings
In the System Installation component, define the following settings for email replies:
The correspondence template that formats the email history that the system automatically enters into the body text of an email reply.
The CRM system delivers a template called Email History - Model 1 that you can use. If you do not explicitly select a template, the following default text appears above the text of the original email:
<===== Received from <address@service.domain> on <date.time>======>
Whether the email history appears at the beginning or end of the reply.
Initially, the email history is the only body text in the reply. Agents can manually add text anywhere. But if they apply templates, the system inserts the template text before or after the existing text depending on this system setting. That is, if you configure the system to keep the reply at the end of the reply, then newly applied template text is added to the beginning of the existing body text instead of the end.
The greeting text to use when replying to an email. PeopleSoft delivers a template called EmailGreeting that you can use.
The closing text to use when replying to an email.
PeopleSoft delivers a template called EmailClosing that you can use.
The subject text to use when replying to an email that has no subject.
Mail Filters
To boost the performance of the ERMS system and the productivity of the users who respond to email, PeopleSoft provides the ability to filter spam email and keep the spam from being analyzed and routed.
You can set up mail filtering based on the sender's email address—either a fully qualified email address or an entire domain. You can also use PeopleTools application classes to create your own email filters. The pages where you define mail filtering include an option to identify a custom application class to use.
You can choose whether to remove the spam entirely or whether to keep it in an exception area, where it remains available if you want to analyze filtering activity or if you want to look for email that was filtered out erroneously.
Email History Tracking
PeopleSoft provides two levels of email history tracking:
An event history that is implemented in PeopleCode.
The system automatically creates an email history record when one or more of these conditions take place:
An email is newly created.
Change of email status to canceled or complete occurs.
Change of group worklist name occurs, for example, when the email is reassigned.
An agent accepts the email.
An audit history.
The audit history displays field-level and record-level changes to email data. You set up audit processing using PeopleSoft Application Designer and the Audit - Setup page.
User Settings
The ERMS system leverages the user settings that you define for correspondence management, including:
Approval processing.
If you designate an approver for a specific user, any email replies that the user sends are routed to the approver, who can either approve or reject the reply. Use this option to ensure the quality and consistency of your customer communications and to monitor the development of your workforce.
Default routing for responses to ad hoc email.
If you use the ERMS system, each ad hoc email that is sent from the PeopleSoft CRM system includes a context tag. If the recipient replies to an ERMS mailbox, and if the reply contains the context tag, the system uses the context tag to identify the user who sent the original ad hoc email. The system then routes the reply to a group worklist based on the Process Customer response as new email system option.
Default From addresses for email replies that are sent by the agent.
By sending replies from a system email address rather than a personal email address, agents can be sure that any response from the customer is handled by ERMS. Different defaults exist depending on whether the email is from an external mailbox, an internal mailbox, or an internal human resources (HR) mailbox.
Note: These user settings are available for setup on Supervisor Desktop.
System Activities
On the email workspace, agents can search for transactions that can be associated with the emails that they work on, or create new transactions that support the completion of the emails, such as creating a lead, order, or case. The ERMS system provides the infrastructure for you to reference the application class methods that are used to create those transactions for emails on the email workspace.
The ability to correctly identify the intent of an email enables more accurate suggestions to be given on actions to resolve customer issues or on templates when you are sending replies. In the ERMS system, an email can be classified using one or more of the following attributes:
Category: high-level classification of an email (for example, inquiry, problem, or spam).
Depending on the nature of an email (unstructured or structured) and system configuration, the category of an email (if populated) can come from AMP or system default.
Type: subdivision under a given category (for example, hardware problem or software problem).
Product Group: high-level product grouping (for example, air conditioner or refrigerator).
Product: specific products under a given product group (for example, air conditioner with product ID A123 or fridge with product ID F234).
Mood: email sender's general disposition (for example, disappointed, neutral, or happy).
Priority: priority of the email.
Language: language used in the email.
Agents can manually adjust these classification values if needed. ERMS uses these values as search criteria to find matching solutions and actions that may resolve customer issues raised in the email, and to find matching correspondence templates for the email response.
ERMS relies on several PeopleSoft Application Engine (AE) processes to read emails from an external mailbox, analyze them, take proper email actions, and send alerts when they are not handled within the specified time period. The ERMS Processes topic of the Understanding ERMS topics describe what these processes do; this topic discusses setup tasks for these processes.
See ERMS Processes.
Process Parameters
To set up ERMS, you define:
The number of emails that the mail reader process works with at a time.
The process scheduler server where the ERMS processes run.
Note: The process scheduler server needs to be run on either a Windows NT or UNIX machine at all times, regardless of database, to support all ERMS processes.
The run frequency for processes other than the mail reader process.
The mail reader process frequency is based on the polling frequencies that you define for your ERMS mailboxes.
Run control information for the inbound email search index.
The search index is used in email content-based routing.
Process Notifications
Because ERMS depends on its PeopleSoft AE processes, prompt notifications of process failures can be important.
PeopleSoft Process Scheduler enables you to set up notifications that are sent when a process or job finishes successfully or when an error occurs in the process or job.
When you set up your ERMS system settings, process-specific links navigate you directly to the PeopleTools pages where you set up these notifications.
ERMS Mail Reader uses PeopleTools APIs to fetch emails from the mail server. When an email is not fetched successfully, these APIs return an error code. Mail Reader invokes the Error Mail Handler using this error code to take the appropriate action.
The setup for handling mail reader errors includes these steps:
Define actions.
Define action groups.
Map action groups and error codes.
The system triggers desired actions based on the error that occurs.
Delivered Actions
This table provides a list of system-delivered action codes:
Action Code |
Description |
---|---|
CUSTM |
Customized Action List Application Class |
DELEML |
Delete Email from Mail Server |
INACTM |
Inactive or Skip the same Mailbox |
LGTBL |
Log into Exceptional Table |
NDFWL |
Not to Routing To Default Worklist |
NSTEML |
Not to store Email in CRM tables |
NTFY |
Notify Action |
RETEML |
Retain Email from Mail Server |
STEML |
Store Email in CRM table |
Delivered Action Groups
This table provides a list of system-delivered action groups:
Action Group |
Description |
---|---|
000 |
Successful |
001 |
Connector Size Overflow |
002 |
PSFT IB threshold Size Overflow |
004 |
Connecting to the mail server failed |
007 |
Unsupported Encoding |
008 |
Cannot write to the attachment Repository |
009 |
Messages were downloaded to repository and deleted from mail server |
010 |
Generic Email Connect Error |
013 |
Internal Error |
9993 |
Integration Broker or Gateway Problem. Please Check with the Administrator |
9994 |
Not able to fetch further email. Too many bad emails |
9995 |
UID Empty |
9996 |
Inbound Email CI Save Error! |
9997 |
Inbound Email CI Create Error! |
9998 |
Abort Error |
9999 |
Unknown Error |