Setting Up ERMS System

This chapter provides an overview of email response management system (ERMS) setup and discusses how to:

• Define correspondence management for ERMS.

• Define system settings for email processing.

• Define mail servers.

• Define mail filters.

• Define mailboxes.

• Define email business units.

• Define priorities and moods.

• Define email audit history tracking.

• Define mail reader error handling options.

Understanding ERMS Setup

This section discusses:

• Mail servers and mailboxes.

• Email handling options.

• Email classification.

• ERMS application engine processes.

• Mail reader error handling options.

Note. This section does not discuss routing rules for structured or unstructured email.

See Also

Understanding Structured Email

Understanding Unstructured Email Routing

Mail Servers and Mailboxes

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 Enterprise HelpDesk or PeopleSoft Enterprise 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, this chapter does not discuss those pages. Refer instead to the documentation for unstructured email routing rules.

See Also

Understanding Structured Email

Understanding Unstructured Email Routing

Enterprise PeopleTools 8.50 PeopleBook: PeopleSoft MultiChannel Framework

Email Handling Options

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, partner, or worker (depending on the mailbox type: external, partner, 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.

  See Defining System Settings for Email Processing.

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

See Also

Defining System Settings for Email Processing

Understanding Audit Information

Defining User Settings

Email Classification

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

  The system prepopulates the category of email that is returned from Verity.

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

See Also

Associating Categories with Recommended Actions

Managing Email

Defining Template Categories and Types

Setting Up Products

ERMS Application Engine Processes

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 section of the Understanding ERMS chapter describes what these processes do; this section 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 build collection process, which runs as part of the unstructured content analysis job.

  The build collection process creates a Verity search collection that is used during 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.

Mail Reader Error Handling Options

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:

1. Define actions.

   See Defining Actions.

2. Define action groups.

   See Defining Action Groups.

3. Map action groups and error codes.

   The system triggers desired actions based on the error that occurs.

   See Mapping Action Groups and Error Codes.

Delivered Actions

This table provides a list of system-delivered action codes:

Delivered Action Groups

This table provides a list of system-delivered action groups:

See Also

Viewing Email Error Logs

Defining Correspondence Management for ERMS

Correspondence management functionality is common to all PeopleSoft CRM applications. ERMS leverages this functionality extensively. Correspondence management is documented in detail in the PeopleSoft Enterprise CRM 9.1 Automation and Configuration Tools PeopleBook.

These correspondence-management implementation steps are crucial to ERMS:

• Define worklists.

  If you use the Group Worklist page to create queues (so that agents can use the Multichannel Toolbar to accept inbound email), define your ERMS system settings before creating worklists. ERMS system settings include certain defaults that are required when you are creating queues from the Group Worklist page.

  See Defining Worklists.

  See Defining System Settings for Email Processing.

• Define general settings for correspondence.

  In particular, be sure to define agent settings such as approval requirements and default from addresses for outbound email.

  See Defining General Settings for Correspondence and Notifications.

  See Defining Email Settings for Agents.

• Define settings for template-based correspondence.

  See Defining Settings for Template-Based Correspondence.

• Define correspondence templates.

  See Setting Up Correspondence Templates.

Defining System Settings for Email Processing

To define system settings for email processing, use the System Installation (RB_ERMS_INSTAL) component.

This section lists prerequisites and common elements and discusses how to:

• Define system settings for email processing.

• Define reply with history templates.

• Specify email greetings.

• Specify email closing text.

• Define subject text for replies to email with no subject.

• Define ERMS process notifications.

• Define system activities.

• Identify email workspace fields for mapping.

Prerequisites

Before you set up system settings for ERMS:

• Define the person(s) who will represent unknown senders.

  Enter one name for role type 4 (Employee) and one name for role type 9 (Consumer). Set up these person(s) in the Worker component, and enter the minimum required data. The person's name for the appropriate role type appears on all emails for which the sender is not identified. To associate a role type with the name, enter each of these person names and role types on the Anonymous Object page of the Installation Options component. You might enter role type ID of 4 for the name of Anonymous Employee and role type ID of 9 for name of Anonymous User. This is, however, not necessary if you specify in the mailbox definition that you want the system to create a user automatically for unidentified email senders.

• Define correspondence templates that control the presentation of the email history that the system enters into the body text of the reply.

  You can use the delivered template Email History - Model 1 as a model for this. 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>======>

• Define the default multichannel queue clusters for agents to use Multichannel Toolbar to receive inbound emails.

  This enables you to create multichannel queues from the CRM Group Worklist page; the queues use the default queue cluster that you establish.

See Also

Setting Up Correspondence Templates

Setting Up Universal Queuing

Defining Workers

Setting Up an Anonymous Business Object

Common Element Used in This Section

Pages Used to Define System Settings for Email Processing

Defining System Settings for Email Processing

Access the System Installations page (Set Up CRM, Product Related, Multichannel Definitions, Email, System Installation, System Installations).

System Settings

Mailbox and Queue Defaults

Content Analysis and Time Out Scheduler Sleep Time

Build Collection Run Control, Directories, Reply With History On, Templates and No Subject Phrase

See Also

Setting Up and Using Worklists

Understanding PeopleSoft CRM Searching

Defining Reply With History Templates

Access the History Templates page (click the Set Up History Template button on the System Installations page).

Template Name

Select the template for the system to use when entering the text of the original inbound email to the body of the new outbound email. Select a template, not a template package. At a minimum, the templates that you select must contain the text of the original email; use the delivered History Email Body term for this. Optionally, you can include front matter or end matter in the appropriate language.

See Also

Setting Up Correspondence Templates

Specifying Email Greetings

Access the Greeting Templates page (click the Set Up Greeting Template button on the System Installations page).

Template Name

Select the template for the system to include a greeting in the new outbound email. Select a template, not a template package.

See Also

Setting Up Correspondence Templates

Specifying Email Closing Text

Access the Closing Templates page (click the Set Up Closing Template button on the System Installations page).

Template Name

Select the template for the system to include a closing message in the new outbound email (for example, a disclaimer from your company). Select a template, not a template package.

See Also

Setting Up Correspondence Templates

Defining Subject Text for Replies to Email with No Subject Text

Access the No Subject Phrase page (click the Set Up No Subject Phrase button on the System Installations page).

No Subject Phrase

Enter a default subject to use for replies to email with no subject text to avoid sending replies with insufficient identifying information in the subject.

Defining ERMS Process Notifications

Access the Process Notifications page (Set Up CRM, Product Related, Multichannel Definitions, Email, System Installation, Process Notifications).

The grid on this page lists all ERMS processes: five PeopleSoft Application Engine processes and one job, which consists of two other PeopleSoft Application Engine processes.

See Also

Enterprise PeopleTools 8.50 PeopleBook: PeopleSoft Process Scheduler

Defining System Activities

Access the System Activities page (Set Up CRM, Product Related, Multichannel Definitions, Email, System Installation, System Activities).

Enable	Select the transactions that agents can search for or create within the email workspace and associate them with email.
Activity Type	Select the CRM object that agents can create from the email workspace.
Application Class ID and Application Class Path	Specify the path and ID of the application class program that is written to create transactions of the corresponding CRM object.

See Also

Related Transactions

Identifying Email Workspace Fields for Mapping

See Identifying Email Workspace Fields for Mapping.

Defining Mail Servers

This section lists prerequisites and discusses how to register mail servers in the ERMS system.

Prerequisites

Before you define mail servers and mailboxes within the ERMS system, you must:

1. Set up the external mail servers and mailboxes that the ERMS system will monitor.

   You set up physical mail servers and mailboxes outside of the PeopleSoft system. The PeopleSoft ERMS system supports both POP3 and IMAP4 email protocols.

2. Set up the integration between these external systems and your PeopleSoft system:

   1. Configure the PeopleSoft Integration Broker gateway for the email channel.

   2. Configure the GETMAILTARGET connector properties on the MCF_GETMAIL node.

      Make sure that all of the transactions of MCF_GETMAIL node are set to active on the Service Operations: General page. For more information about nodes, refer to the Configuring Nodes chapter of the Enterprise PeopleTools 8.50 PeopleBook: Integration Broker Administration.

The PeopleSoft MultiChannel Framework documentation discusses these processes in the chapter on configuring the email channel.

See Enterprise PeopleTools 8.50 PeopleBook: PeopleSoft MultiChannel Framework

Page Used to Define Mail Servers

Registering Mail Servers in the ERMS System

Access the Mail Server Definition page (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Servers and Security, System Parameters/Defaults, Mail Server Definition).

Mail Server Name

Enter a row of data for each mail server that the ERMS system will access. The name that you enter here must match the name of the physical mail server. When you set up mailboxes, you will associate each mailbox with one of the mail servers that are listed here. This association gives the mail reader process the information that it needs to find the external mail server from which the mailbox's emails are fetched.

Defining Mail Filters

To define mail filters, use the System Parameters/Defaults (RB_ERMS_SETUP) component.

This section discusses how to:

• Set up address-based and domain-based filters.

• Create application classes for custom mail filtering.

• Apply email filters.

Pages Used to Define Mail Filters

Setting Up Address-Based and Domain-Based Filters

Access the Spam List page (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Servers and Security, System Parameters/Defaults, Spam List).

Email Address/Domain Name	Enter a full email address or a domain name from which you want to block all email.
Type	Select Email or Domain to indicate the type of address being blocked.

Note. To activate the filters that you set up on this page, access the Mail Filters page and ensure that the delivered SYS_SPAM_LIST filter is active.

Creating Application Classes for Custom Mail Filtering

To implement mail filtering other than by email address or domain, create an application class method that identifies the emails to be discarded.

PeopleSoft provides a base class called MailFilter that you extend when creating your own filters. The delivered base class is in the RB_MCF_SETUP package. PeopleSoft also delivers the SYS_SPAM_LIST class, which you can clone as a starting point.

Properties of the Base Class

This table explains the base class properties:

MailFilter(&Row1 As Row) Method

The MailFilter(&Row1 As Row) method uses the &Row1 parameter to populate the DomainName, FromEmailAddress, and EmailRow properties of the class. It accepts this parameter:

No return parameters are available.

IsFromEmailAddressValid() Method

IsFromEmailAddressValid() sets a Boolean value that indicates whether the email is valid. When you create your own mail filters, your custom logic goes here. The returned value is trapped by the mail reader process and is used in this way:

Sample Code

This sample code filters out email from support@abc.com:

import RB_MCF_SETUP:*;

class CstmFilter1 extends MailFilter;
   method CstmFilter1(&Row1 As Row);
   method IsFromEmailAddressValid() Returns boolean;
end-class;


method CstmFilter1
   /+ &Row1 as Row +/
   %Super = create MailFilter(&Row1);
   
end-method;

method IsFromEmailAddressValid
   /+ Returns Bool +/
   If (%This.FromEmailAddress = "support@abc.com") Then
      Return False;
   Else
      Return True;
   End-If;
   
end-method;

See Also

Enterprise PeopleTools 8.50 PeopleBook: PeopleCode Developer's Guide

Enterprise PeopleTools 8.50 PeopleBook: PeopleCode Language Reference

Applying Email Filters

Access the Mail Filters page (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Servers and Security, System Parameters/Defaults, Mail Filters).

Mail Filter ID and Description	Enter a name and description for your custom mail filter. PeopleSoft delivers a mail filter with the ID SYS_SPAM_LIST. This filter blocks email from the addresses and domains that you enter on the Spam List page. You cannot edit or delete the data for this filter.
Status	Select to activate the mail filter. The email addresses and domain filters that you set up on the Spam List page are active only if you activate the SYS_SPAM_LIST filter here.
Application Class ID, Package Tree Viewer, and Application Class Path	Enter the ID and path for an application class that performs custom mail filtering. Click the Package Tree Viewer link to access the Application Packages Lookup page, where you can browse for application classes and select one to use.
Retain Email Body As Exception	Select to have the ERMS mail reader process to save the text of any email that has been blocked by this filter. The blocked email is not routed for handling, but an administrator can review the blocked emails on the Exception Email Details page. If this option is cleared, you can still review summary information about the email on the Mail Reader Process Log page, but you will not be able to view the email's body text.

See Also

Using Application Classes

Reviewing Exception Email

Defining Mailboxes

To define mailboxes, use the Mailbox Details (RB_MAILBOX_DEFN) component.

This section lists prerequisites and discusses how to:

• Define mailbox settings.

• Associate categories with recommended actions.

• Configure the activity list.

• Clone a mailbox.

Note. This section discusses only the general-purpose pages in the Mailbox Details component: the Mailbox Definition page and the Clone Mailbox page. Other pages in the component are used to set up email routing rules and are described in that context.

See Also

Understanding Unstructured Email Routing

Prerequisites

Before you begin defining mailboxes, define the mail server for the mailbox.

Also, define these users and group worklists that are associated with the mailbox:

• The worklist owner (a worker).

• The default group worklist for the mailbox.

• The group worklist to which emails that cannot be handled due to processor errors are sent.

These prerequisites are required if you want to implement the associated functionality:

• To define an auto-acknowledgement message for this mailbox, first create the template and a template package that contain the text of the auto-acknowledgement message.

• To define customer-based routing, first create the application class that is invoked during customer-based routing.

Pages Used to Define Mailboxes

Defining Mailbox Settings

Access the Mailbox Definition page (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Servers and Security, Mailbox Details, Mailbox Definition).

Mailbox ID and Description	Displays the mailbox ID. The ID is used for internal purposes only and does not have to relate to the actual email address that is represented by this mailbox. Be sure to enter a meaningful description for the mailbox because the description appears in several places throughout the system.
Status	Select a status: Active or Inactive. The Mail Reader process fetches inbound email from active mailboxes only.
Clone Mailbox	Click to access the Clone Mailbox page and create a new mailbox based on this mailbox definition.
Mailbox Type	Select External if this mailbox receives email from external customers. For example, your sales and customer support email boxes are external. Select Internal if you use this mailbox in conjunction with PeopleSoft HelpDesk, and select Internal H (Internal HR) if you use this mailbox in conjunction with PeopleSoft HelpDesk for Human Resources. Select Higher Ed if you use this mailbox to receive Higher Education-specific email messages. Select Partner if you use this mailbox to receive email messages for partners. This setting controls which types of people (workers or customers) are associated with the email that this mailbox receives. Also, when agents reply to such email, this setting determines the default from address of the reply. Configure the default from addresses on the Agent Setup page for correspondence management or from the Supervisor Desktop.

Email Address Information

The mail reader process uses the information in these fields to fetch email from this mailbox. These fields are relevant to both structured and unstructured emails.

Email Handling

Email Business Unit Mapping

This section appears if the mailbox type is External, or Partner. This customer setID and email business unit mapping is used for the feature that, when enabled for a group worklist, creates cases for inbound email that are routed to that group worklist. The system uses the business unit and display template family code that are specified in group worklist definition to construct the case prior to populating email data to the case. If these default values are not specified for the group worklist, the system goes to the mailbox definition for the inbound email to collect the needed information from the email business unit mapping. First of all, the system identifies the setID of the email sender, who is also the customer of the new case. Then, it looks at the mapping to find out the matching email business unit. From the definition of the matching email business unit, the system knows which business unit and display template family to use for the case.

For mailboxes of types Internal and Internal HR, the default business unit is used as the email business unit to derive the corresponding business unit and display template family for case creation.

Information in this section is not used if the case defaulting information is already specified in the group worklist definition.

See Defining Group Worklists.

Auto Acknowledgement

Create New Customer

Use this group box to configure how the mailbox acts if the mail reader process cannot identify email senders from the database.

Unstructured Email Processing

See Also

Defining User Settings

Understanding Unstructured Email Routing

Understanding Automated Mail Processing

Email Sender Identification

Using Application Classes

Associating Categories with Recommended Actions

Access the Recommended Actions page (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Servers and Security, Mailbox Details, Recommended Actions).

For each selected category on this page, associate it with one or more ERMS-related actions. When an email is assigned a category (either as default by the system or manually by an agent) at runtime, the associated recommended actions appear on the Email page (under the Assistance section). The sequence number dictates the order in which the actions appear at runtime.

See Also

Assistance

Configuring the Activity List

Access the Mailbox Activity List page (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Servers and Security, Mailbox Details, Mailbox Activity List).

Recent Activity Default Rows	Enter the maximum number of activity rows that users see from the activity result grid on the Recent Activities tab on the Email page.
Activity Type	Select the types of transactions (activities) that can appear when the email workspace retrieves the default activity result list initially. At runtime, all the transactions that are enabled, together with emails, appear in the Activity Type field on the Recent Activities tab on the Email page.
Create New	Select to enable users to create the corresponding transaction at runtime by clicking the Create New link that appears on the Recent Activities tab on the Email page. The link appears when the transaction that has this option enabled is selected in the Activity Type field. If users do not have the permission to create that transaction, they are notified with a system message.
Quick Create	Select to let the system display the Create New <CRM transaction> button for the corresponding transaction at runtime. For example, if you select this check box for the support case transaction, the Create New Support Case button appears on the Email: Main page.

See Also

Assistance

Cloning a Mailbox

Access the Clone Mailbox page (click the Clone Mailbox button on the Mailbox Definition page).

Save As Mailbox ID and Description

Enter IDs and descriptions for the mailboxes that you want to create.

Click the OK button to create mailbox definitions using the IDs and descriptions that you entered. The new mailbox definitions are exact duplicates of the current mailbox definitions except for the ID and description fields.

Defining Email Business Units

This section discusses how to define email business units.

Understanding Case Creation for Inbound Email

At the group worklist level, an option is available that, when selected, allows the system to automatically create a case for every unstructured inbound email routed to that group worklist. The system uses the business unit and display template family that are specified in the group worklist definition to generate cases for inbound email.

If this information is not available in the definition, the system accesses the mailbox definition of the inbound email and uses the setID of the email sender (which is also the customer of the new case) to derive the corresponding email business unit from the Email Business Unit Mapping section.

In an email business unit definition, you specify the default business units for a list of common CRM transactions, which are used for creating these transactions. Additionally, you specify the display template family to be used for each mailbox type for the purpose of case creation.

See Defining Group Worklists.

Page Used to Define Email Business Units

Defining Email Business Units

Access the Email Definition page (Set Up CRM, Business Unit Related, Email Definition, Email Definition).

Business Unit Definition

Case Display Template Details

Use this section to specify a display template family for each mailbox type. The system uses the selected display template family for creating cases, if the Create Case for every new inbound Email feature is enabled for a group worklist but the display template family is not already specified in the group worklist definition.

Defining Priorities and Moods

This section discusses how to:

• Define priorities.

• Define moods.

Pages Used to Define Priorities and Moods

Defining Priorities

Access the Priority Setup page (Set Up CRM, Product Related, Multichannel Definitions, Email, Priorities, Priority Setup).

Values in this grid are used to give priority to email after the content analysis. The priority appears for email in the email workspace.

Defining Moods

To define moods, use the Mood Setup (RB_MOOD_SETUP) component.

Access the Mood Setup page (Set Up CRM, Product Related, Multichannel Definitions, Email, Moods, Mood Setup).

Values in this grid are used to describe what the customer mood is in email after the content analysis. The mood appears for email in the email workspace.

Defining Email Audit History Tracking

This section discusses how to define email audit history tracking in the CRM system.

Page Used to Define Email Audit History Tracking

Defining Email Audit History Tracking in the CRM System

See Setting Up Auditing for Cases and Inbound Email.

Defining Mail Reader Error Handling

This section discusses how to:

• Define actions.

• Define action groups.

• Map action groups and error codes.

See Also

Mail Reader Error Handling Options

Viewing Email Error Logs

Pages Used to Define Mail Reader Error Handling

Defining Actions

Access the Define Action Code page (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Errors and Actions, Define Actions, Define Action Code).

Use this page to define an action that needs to be taken when an error is encountered. The system delivers a number of actions, such as deleting email from the mail server, notifying action, inactivating or skipping a mailbox and so on. You can add new actions to the system as well, which require new PeopleCode to be written to support these actions.

Defining Action Groups

Access the Define Action Groups page (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Errors and Actions, Define Action Group, Define Action Groups).

Action Group	Displays the unique identifier of the action group, which can contain a maximum of 10 characters.
Description	Enter the description of the action group, which can contain up to 100 characters.
Order by	Enter the order in which actions listed in the section to be taken.
Action ID	Enter the ID of the action to be taken.
Active	Click to set the status of the corresponding action to active. Only active actions can be triggered.

Mapping Action Groups and Error Codes

Access the Map Error and Action Group page (Set Up CRM, Product Related, Multichannel Definitions, Email, Define Errors and Actions, Map Error and Action Group, Map Error and Action Group).

Use this page to map standard error codes (returned by PeopleTools API) to action groups. For example, when the connection to the email server is failed, an error code of 4 is returned. This error code is mapped to the action group that contains 3 actions. At runtime, when PeopleTools API returns an error code of 4, the ERMS system performs these 3 actions according to their order by numbers.