Understanding Correspondence and Notification Settings

This section discusses:

  • Settings by correspondence type.

  • Default From addresses.

  • Additional user settings.

  • Link redirection.

  • Action requests.

  • Recipient specific terms.

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.

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 thePeopleSoft Multichannel Communications PeopleBook documentation.

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


Not applicable.

Not applicable.

Reply To Addresses (Agent Setup page).


Not applicable.

Not applicable.

Link redirection (URL Setup page).


Not applicable.


Action requests (Action Requests page).

Optional; used only for worklist notifications.

Not applicable.

Not applicable.

Recipient specific terms.


Not applicable.

Not applicable.

Correspondence templates and their processing (various pages).



Required. Correspondence templates are used for sending email notifications using CRM workflow (for example, through the active analytics framework), except when they are sent from business projects.

Note: The term correspondence templates refers to the templates that are used for manual notifications and correspondence requests.

Users can send email from the CRM system using the Correspondence Request page and the Outbound Notification 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, or Internal HR.

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 support@yourcompany.com, but you also maintain mailboxes with more specific purposes—perhaps mailboxes for different product lines.

For example, if a customer sends an email to support@yourcompany.com, but the reply that you send is from printer_support@yourcompany.com, 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 product_support@yourcompany.com, while responding to worker's questions from product_helpdesk@yourcompany.com.

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 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 Multichannel Communications is licensed.

See Configure Agent - Email Configuration Page.

Default ERMS Worklists

If you use ERMS, you can define which ERMS worklist is used for responses to the user's Outbound notification 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 Outbound notification, the system uses the context tag to identify the user who sent the original Outbound notification 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.

Both Outbound 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 Outbound notification, select the Include URL 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:


The URI portion of this URL is:


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





Service orders: 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 Outbound 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 Notification page, which the recipient accesses to view the full details of the message.

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

Manual notifications support the use of correspondence templates to populate the content of the messages. When a user selects and applies a template to the notification, the system checks for any AAF terms that are included in the template, resolves them, and presents the final version of the message for review. For any terms that are specific to recipients, such as Recipient First Name and Recipient Last Name, they are resolved based on the information of TO recipient. And if multiple TO recipients are present for the notification, the system provides an option for the user to pick one of the TO recipients and that recipient will be used for resolving recipient-related terms.

In order for recipient specific terms to be resolved successfully when templates are applied at runtime, they must be specified in advance as a setup task.