Intake and Resolution Email Templates in Customer Service for Financial Services

Intake and Resolution Email Templates in Customer Service for Financial Services

Description	The rules and components of the new email templates introduced in Pega Customer Service for Financial Services 8.5
Version as of	8.5
Application	Customer Service
Capability/Industry Area	Financial Services

New email templates were introduced for Intake and Resolution stages in Pega Customer Service 8.5, to standardize how email notifications appear across different implementations. This article lists the different components of the new email templates that can be customized by implementation teams in Pega Customer Service for Financial Services.

List of rules that constitute Intake and Resolution email notifications in Customer Service for Financial Services:

Rule	Rule Type	Usage
SendIntakeNotification_0	Correspondence	This is the standard intake correspondence rule.
SendResolutionNotification_0	Correspondence	This is the standard resolution correspondence rule.
Email header background color	Field value	The value in this field value rule determines the background color for email headers.
IntakeContentHeader	Paragraph	Used for custom header message on the intake notification – to be customized for every case.
ResolutionContentHeader	Paragraph	Used for custom header message on the resolution notification – to be customized for every case.
NotificationSalutation	Paragraph	Used for standard customer salutation.
IntakeContent	Paragraph	Main body of intake notification – to be customized for every case.
ResolutionContent	Paragraph	Main body of resolution notification – to be customized for every case.
NotificationSignature	Paragraph	Used for standard email signatures.
NotificationDisclaimer	Paragraph	Used for generic disclaimer content or footer in email notifications.

The act of closing a case by recording in the properties that work is complete.

As a case advances through a flow, information stored in its properties becomes more complete through user input and automatic processing. When the work for a case is complete, the case is marked as "resolved", or "closed".

The basic building blocks of an application, rules define the behavior of an application. There are many types of rules, each defining a different type of behavior. For example, rules define the display of a form, the fields that are used in your application, and the flows that define the process of completing work.

The system can reuse rules throughout your application. For example, in an application for ordering replacements parts, you can define a user interface to capture an address, and reuse the same rule for the UI to capture both the mailing address and the billing address for the order.

You define rules in an application to create a business solution for your organization and customers. Rules provide flexibility during the development process and help you design applications more efficiently, so that they can be implemented again in future projects.

A business solution that automates workflows in your organization. Multiple, unrelated applications can be hosted in the same system. You create an application by running the New Application wizard.

A program component that defines and implements an interface between an external application acting as a client, and a Pega Platform system acting as a server. An external system can send a request to a Pega Platform application and receive a response.

For example, the Pega Cloud Services SFTP service provides Pega Cloud clients with simple, secure file transfers to and from their Pega Cloud applications.

The first level of organization of the tasks that are required to complete your business process. By providing stages, you organize work into logical phases that users of your application follow to reach an outcome. Stages visualize milestones or significant events in your business process and can also indicate a transition of work from one person to another. For example, if your business process is to review job applications, you can create Submission, Review, and Approval stages, each of which includes a different set of actions and is performed by a different person. Stages that are necessary to resolve a case through the basic, default path are called primary stages.

In a Microjourney™, stages are the milestones that leads towards an outcome.

The basic building blocks of an application, rules define the behavior of an application. There are many types of rules, each defining a different type of behavior. For example, rules define the display of a form, the fields that are used in your application, and the flows that define the process of completing work.

The system can reuse rules throughout your application. For example, in an application for ordering replacements parts, you can define a user interface to capture an address, and reuse the same rule for the UI to capture both the mailing address and the billing address for the order.

You define rules in an application to create a business solution for your organization and customers. Rules provide flexibility during the development process and help you design applications more efficiently, so that they can be implemented again in future projects.

The general classification or particular use of a rule. For example, the System screen in an application used for hiring employees contains Property rules that define the information that needs to be captured from the user, for example, full name, email address, phone number, and résumé. The screen also contains a Section or View rule that defines how the properties are displayed to the user.

Rules of different types are linked together to define your application. Rule types also help to categorize key concepts and behavior in your application, saving you time during the development cycle. You can use another instance of the same rule type to define other sections of the application.

An outgoing email, letter, fax, or text message that is produced by the system and its users. Correspondence is typically associated with one work item, or a cover or folder, and can include text and images. Correspondence that is sent to the originator of a work item is known as an acknowledgment.

The basic building blocks of an application, rules define the behavior of an application. There are many types of rules, each defining a different type of behavior. For example, rules define the display of a form, the fields that are used in your application, and the flows that define the process of completing work.

The system can reuse rules throughout your application. For example, in an application for ordering replacements parts, you can define a user interface to capture an address, and reuse the same rule for the UI to capture both the mailing address and the billing address for the order.

You define rules in an application to create a business solution for your organization and customers. Rules provide flexibility during the development process and help you design applications more efficiently, so that they can be implemented again in future projects.

The act of closing a case by recording in the properties that work is complete.

As a case advances through a flow, information stored in its properties becomes more complete through user input and automatic processing. When the work for a case is complete, the case is marked as "resolved", or "closed".

Actual work that is performed by application users and automations that consists of a sequence of tasks and leads to an intended business goal. An example of a case is a process of hiring a particular job candidate, where an HR worker collects necessary documents, a hiring manager conducts a job interview, and an application sends an automated email with onboarding information after the candidate is approved. To create a case, you first build a template of your business process that is a case type, and then apply the template in multiple cases, for example, to review applications from many candidates.