This chapter provides an overview of correspondence and notification 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.
This section discusses:
Settings by correspondence type.
Default From addresses.
Additional user settings.
Link redirection.
Action requests.
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 for manual notifications also applies to email responses. Additional ERMS-specific setup steps are described in the PeopleSoft Multichannel Communications PeopleBook.
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.
See Also
Setting Up PeopleSoft CRM Workflow
Setting Up Correspondence Templates
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 attempt to 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 and manual notifications, a system-wide default comes from the Sender's Email Address field on the Correspondence Management Installation Setup page.
For email replies, a mailbox-specific default comes from the Mailbox Definition page.
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].
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 is 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 performance of your workforce.
This setting applies to manual notifications and, if you license PeopleSoft Enterprise Multichannel Communications, to email replies.
Note. It is recommended that you use the Supervisor Desktop functionality to configure email approval settings for agents if PeopleSoft Enterprise Multichannel Communications is licensed.
See Defining Email Settings for Agents.
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 about email threading and routing processes.
See Also
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 the PeopleSoft system pages are made up of two parts:
The uniform resource identifier (URI) 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.
The PeopleSoft system 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.
The PeopleSoft system 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.
The PeopleSoft system 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.
This table describes the system data that the PeopleSoft system 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, RC_CASE__HD_SS, RC_CASE_HD_SS_RPT, RC_CASE_SW_SS, RC_CASE_SW_SS_RPT |
CALLCENTER, RC_CASE_MAP |
Leads: RSF_LEAD_ENTRY |
RSF_LEADS, RSF_LEAD_ENTRY |
Service orders: RF_SERVICE_ORDER |
RF_SERVICE_ORDER, RF_SERVICE_ORDER |
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 his or her 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.
To define user settings, use the Agent Setup (RB_ERMS_AGT_SETUP) component.
This section discusses how to define user settings.
Page Name |
Object Name |
Navigation |
Usage |
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. |
Agent 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). To select an agent by user ID, click the look up button next to this field to search for the agent by user ID. An agent must have a user ID in order to be selected. |
Approving Frequency |
Select the frequency of sending the agent’s outbound correspondence to an approver for review before they are sent to customers. You can choose to send all of them, 1 out of X (where X is the number of composed emails), or none. These values are translate values predefined in the system. |
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 is automatically routed to the approver's worklist. |
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. |
Reply To Address
These fields mainly apply to ad hoc notifications and ERMS outbound email.
Note. The system hides all ERMS related values if the ERMS functionality included in PeopleSoft Multichannel Communications is not installed.
External Reply Address |
Enter the default From address to be used when this agent sends email to external customers. When this agent generates correspondence requests from transactions, such as case, the agent-specific email address that is defined here is used as the sender's email address in those requests. If no email address is specified for this agent, then the sender's email address on the Correspondence Management Installation Setup page is used as the default value. |
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. |
To redirect links, use the Workflow URL (RB_WF_URL_SETUP) component.
This section discuses how to redirect links.
Page Name |
Object Name |
Navigation |
Usage |
RB_WF_URL_SETUP |
Set Up CRM, Common Definitions, Workflow, Workflow URL, URL Setup |
Configure links for internal and external routing. |
Redirecting Links to a Different Server
Internal URI |
Enter a URI to be used in links sent to internal recipients. The URI is typically 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 is typically 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. |
To create action request codes, use the Action Requests (RB_UPD_ACT_RQST) component.
This section discusses how to define action request codes.
Page Name |
Object Name |
Navigation |
Usage |
RB_ACT_RQST |
Set Up CRM, Common Definitions, Workflow, Action Requests, Action Requests |
Create 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 think it is strange if there are no values in the Worklist Action Request drop-down list box on the Send Notification page.