Defining General Settings for Correspondence

This chapter provides an overview of correspondence settings and discusses how to:

Define user settings.
Redirect links.
Create action request codes.

Note. This chapter does not describe how to define correspondence templates, nor does it describe how to define automated workflow notifications.

Understanding Correspondence Settings

This section discusses:

Settings by correspondence type.
Default From addresses.
Configure additional user settings.
Link redirection.
Action requests.

Settings by Correspondence Type

Manual notifications, correspondence requests, and automated notifications that are sent by workflow actions each require their own specific setup. Some configuration options apply to just one mechanism, other options apply to several.

The following table lists the pages that are used when setting up manual notifications and explains where else those setup options are used. For topics that are not covered in this chapter, the table provides a cross reference to the appropriate chapter.

Note. If you use the email response management system (ERMS) of PeopleSoft Multichannel Communications, the setup that you do for manual notifications also applies to email responses. Additional ERMS-specific setup steps are documented in the PeopleSoft Multichannel Communications PeopleBook.

Setup Option	Manual Notification	Correspondence Request	Automated Notification
Reply to Group Worklist setting (Agent Setup page).	Optional if you use ERMS, otherwise not applicable.	Not applicable.	Not applicable.
Approval processing (Agent Setup page).	Optional.	Not applicable.	Not applicable.
Reply To Addresses (Agent Setup page).	Optional.	Not applicable.	Not applicable.
Link redirection (URL Setup page).	Optional.	Not applicable.	Optional.
Action requests (Action Requests page).	Optional; used only for worklist notifications.	Not applicable.	Not applicable.
Correspondence templates and their processing (various pages).	Optional.	Required.	Required. Correspondence templates are used for sending email notifications using CRM workflow (for example, through AAF), except when they are sent from business projects.
Workflow email templates (native).	Not applicable.	Not applicable.	Required only for email notifications that are sent from business projects. Workflow email templates do not apply to worklist notifications.

Note. The term correspondence templates refers to the templates that are used for manual notifications and correspondence requests. The term workflow email templates (native) refers to the templates that are used by business projects to deliver email notifications.

Default From Addresses

Users can send email from the CRM system using the Correspondence Request page, the Send Notification page, and, for ERMS users, the Outbound Email page. Every email that is sent from any of these places has a From address; if the recipient replies to the email, the reply is sent to that address.

All email mechanisms get the default From address from user-specific settings on the Agent Setup page. When user-specific default email addresses are not available, the default sender addresses are derived from other places:

For correspondence requests, a system-wide default comes from the Correspondence Management Installation Setup page.
For email replies, a mailbox-specific default comes from the Mailbox Definition page.
For manual notifications that are not email replies, there is no secondary default value: the sender address is blank if there is no user-specific default.

You can define up to three different default From addresses for each user:

An external From address to use when sending email to customers.
An internal From address to use when sending email to workers for whom PeopleSoft HelpDesk cases are created.
An internal HR From address to use when sending email to workers for whom PeopleSoft HelpDesk for Human Resources cases are created.

When sending email from the context of a transaction, the system determines the appropriate default From address based on the transaction. For example, when sending email from a help desk case, the default From address is the agent's internal From address.

When replying to an email directly (from the Email Workspace rather than from a transaction), the system determines the appropriate default From address based on the mailbox type: External, Internal, Internal HR, or Partner.

By setting an outbound email's From address, you control the handling of any reply that the recipient might send. If you use ERMS, this is an easy way to optimize handling for replies that do not include a context tag and therefore cannot follow the normal thread-based routing rules. Use of the appropriate From address directs those replies to mailboxes that are fine-tuned to process specific types of inbound email. This functionality is particularly useful if you publicize general purpose email addresses such as [email protected], but you also maintain mailboxes with more specific purposes—perhaps mailboxes for different product lines.

For example, if a customer sends an email to [email protected], but the reply that you send is from [email protected], then a follow-up email (without a context tag) will go to your printer support mailbox, which is optimized for routing printer-related emails.

If you use your own products internally, an agent who supports those products can respond to customer from [email protected], while responding to worker's questions from [email protected].

Configuring Additional User Settings

This section discusses additional user-specific options that you can configure.

Approval Processing

If you designate an approver for a specific user, any correspondence that the user sends gets 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.

This setting applies to manual notifications and, if you license PeopleSoft Multichannel Communications, to email replies.

Default ERMS Worklists

If you use ERMS, you can define which ERMS worklist is used for responses to the user's ad hoc email (ad hoc refers to manual notifications that are not replies to inbound email.)

If you use the ERMS system, all email sent from the CRM system includes an identifier known as a context tag . If the recipient replies to an email (and the reply includes the context tag, and the reply is sent to a mailbox that ERMS monitors), then the system uses the context tag to establish the thread association between the inbound and outbound email and to route the new inbound email appropriately.

If the new inbound email is part of a thread that includes other inbound email, then the ERMS system routes the new email to the same worklist where the previous inbound email was handled. But if the new inbound email is a response to an ad hoc notification, the system uses the context tag to identify the user who sent the original ad hoc email and then routes the reply to that user's Reply To group worklist, if available. If a user does not have a default group worklist, the reply goes to the default worklist for the mailbox where it was sent.

Consult the Multichannel Communications documentation for more information on email threading and routing processes.

Link Redirection

Both ad hoc notifications and automated notifications that are sent by the Active Analytics Framework (AAF) have the option to include a URL (uniform resource locator) in the body of the message. The URL gives the recipient easy access to the transaction where the email originated. If the notification is sent by email, the URL appears at the end of the text message you enter.

Note. Link redirection does not apply to worklist notification.

To configure a notification to include a URL:

In an ad hoc notification, select the Attach URL to Email Recipients check box.
In a workflow configuration in AAF, select the Send URL check box.

Redirecting to a Different Server

URLs for PeopleSoft pages are made up of two parts:

The URI (uniform resource identifier) is the subset of the URL that points to the location of the resource, but does not include any parameters passed to that resource.
The query string includes the parameters (such as the page name and values for the transaction's key fields) that are specific to the transaction.

For example, consider the following URL:

http://someserver/psp/C1B89004/EMPLOYEE/CRM/c/CALLCENTER.RC_CASE_SEARCH.GBL?DISP_TMPL_ID=RC_SUPPORT

The URI portion of this URL is:

http://someserver/psp/C1B89004

You can configure the system to embed different URIs in the URL depending on whether the recipient is internal or external. This enables you to send your customers to pages outside your firewall. All workers, regardless of whether they are your CRM users or employees that are being served by your help desk, are considered internal.

Redirecting to a Different Component

You can also redirect links from one component to another. This is useful when the underlying data can be viewed in more than one page, and you want to ensure that recipients are directed to the correct page. For example, cases can be viewed in either agent-facing or self-service pages. In this situation, the link is redirected based on the user ID. A customer who follows the link will see the self-service page, while internal users who follow the link will see the agent-facing page.

To implement this functionality, you can make the URL point to a hidden component with component pre-build PeopleCode that redirects the user to the appropriate page.

PeopleSoft delivers the RC_CASE_MAP component to perform this processing for all types of cases. RC_CASE_MAP redirects users to the appropriate case component depending on the person's user profile. Users with security access to the standard component are transferred there; users without that access are transferred to the self-service component. Users never see the RC_CASE_MAP component; they are always redirected to another component before it appears.

PeopleSoft also delivers system data so that all case components are configured to send links to the RC_CASE_MAP component instead of to the actual component where the notification originates.

PeopleSoft also delivers system data for configuring links from the Lead component. In this case, however, the link configuration exists not to provide conditional logic, but to provide the necessary menu information to the PeopleSoft Application Engine process that sends lead-related notifications in PeopleSoft Sales. The process is not otherwise able to determine the menu variable for the URL in the notification it sends.

The following table describes the system data that PeopleSoft delivers for configuring links. The market for the target component is always the same as the market for the source component.

Source Component	Target Menu and Component
Cases: RC_CASE (global market)	CALLCENTER, RC_CASE_MAP
Leads: RSF_LEAD_ENTRY (global market)	RSF_LEADS, RSF_LEAD_ENTRY

Action Requests

Action requests are optional attributes of manual notifications that are sent to worklists. They are not used for any type of email correspondence.

Action requests describe an action that the recipient is expected to take in response to the notification. When sending an ad hoc notification, a sender can select an action request from a list of values established by your organization. The selected value is visible both in the recipient's worklist and in the Outbound Email page, which the recipient accesses to view the full details of the message.

There is no associated processing; the action request is informational only.

Specifying User Settings

This section discusses how to define user settings.

Page Used to Define User Settings

Page Name	Object Name	Navigation	Usage
Agent Setup	RB_ERMS_PER_GRPWLS	Set Up CRM, Common Definitions, Correspondence, Agent Setup	Define user-level settings such as the default From addresses for correspondence that an agent sends.

Defining User Settings

Access the Agent Setup page.

Name

Enter the names (not the user IDs) of workers who send outbound email, either ad hoc email or email replies (if you use ERMS).

Process Settings

Reply To Group Worklist	Select the group worklist to which replies to this user's ad hoc email will be routed if you use ERMS. If you do not use ERMS, this field is not relevant.
Approving Person	Enter the name of the worker who must approve all outbound correspondence (email, print, and worklist channels) that is sent by the person you are setting up. If you leave this field blank, no approvals are necessary. Otherwise, correspondence that the user sends are automatically routed to the approver's worklist.

Reply To Address

These fields apply to ad hoc notifications and ERMS outbound email. These fields do not apply to email sent through a correspondence request.

External Reply Address

Enter the default From address to be used when this agent sends email to external customers.

Internal Reply Address

Enter the default From address to be used when this agent sends ad hoc email from a help desk case or replies to an email that was originally sent to an internal mailbox.

This field is visible only if you license PeopleSoft HelpDesk.

Internal HR Reply Address (Internal Human Resources Reply Address)

Enter the default From address to be used when this agent sends ad hoc email from a human resources help desk case or replies to an email that was originally sent to an internal HR mailbox.

Redirecting Links

To redirect links, use the Workflow URL component.

This section discuses how to redirect links.

Page Used to Redirect Links

Page Name	Object Name	Navigation	Usage
URL Setup	RB_WF_URL_SETUP	Set Up CRM, Common Definitions, Workflow, Workflow URL, URL Setup	Configure links for internal and external routing.

Redirecting Links

Access the URL Setup page.

Redirecting Links to a Different Server

Internal URI

Enter a URI to be used in links sent to internal recipients. The URI would typically be for a location within your firewall.

Provider groups and sales teams are always considered to be internal. Workers are considered internal if the Contact Flag field on the Worker page is set to Internal.

External URI

Enter a URI to be used in links sent to external recipients. The URI would typically be for a location outside your firewall.

Contacts, consumers, and email addresses in the format [email protected] are always considered external. Workers are considered external if the Contact Flag field on the Worker page is set to External.

Redirecting Links to a Different Page

Use the fields in the Component Details group box to make notification URLs point to a component other than the one where the notification originated.

The following field definitions include information about how to set up notifications sent from cases so that the URL points to a hidden component that appropriately redirects the user to the agent-facing or self-service component.

Component Name and Base Market	Enter the object name of the component from which notifications are sent, and select the component's market.
Menu Name, Component ID - To and Market	Enter the menu, target component and market of the target component that is to be referenced by links in notifications that are sent from the source component you selected. The markets you select for the source and target components should be identical.

Creating Action Request Codes

To create action request codes, use the Action Requests component.

This section discusses how to define action request codes.

Page Used to Define Action Request Codes

Page Name	Object Name	Navigation	Usage
Action Requests	RB_ACT_RQST	Set Up CRM, Common Definitions, Workflow, Action Requests, Action Requests	Create action request codes.

Defining Action Request Codes

Access the Action Requests page.

In each row, enter the action request text. This is the text that notification senders and recipients see in the notification form.

Although setting up action request codes is optional, users may find it strange if there are no values in the Worklist Action Request drop-down list box on the Send Notification page.