Creating a new implementation application on Pega Customer Service
|Description||Understand the options presented while running the New Application wizard to make informed choices when building a new implementation application.|
|Version as of||8.5|
|Capability/Industry Area||App Configuration and Behaviors|
Guided steps to building a new Pega Customer Service implementation application
Pega Customer Service provides a guided and streamlined series of steps to help implementers easily build their custom application while recognizing the various options that are presented in the process ranging from selection of existing cases, data objects, and channels to determining the application structure. This article describes these options to help you make informed decisions while building a new custom implementation application so that you avoid rework or refactoring at a later point. Also described are the artifacts that are created in the new application as a result of your choices and how they help speed up the implementation and therefore reduce costs.
The following steps apply for any Pega Customer Service application regardless of the industry application. The screenshots, displayed below, are for illustration purposes only. The actual screens might vary across different Pega Customer Service applications.
- Make a business decision on whether you want to create a new framework application, and then build an implementation application on top of it, or you want to build a new implementation application. Consider the following guidance to help you make that decision:
- Build a new framework application if you have multiple companies, lines of business, or entities that share a common set of assets. Then build a new implementation application for each entity on top of this new framework application.
- Build a new implementation application of top of Pega Customer Service if you have a single line of business or entity and do not anticipate building multiple applications to represent each entity.
- Ensure that you have an operator that points to the CustomerService:AppSetup access group to build an application on top of Pega Customer Service. For the Pega Customer Service industry applications, your operator should point to one of these access groups based on the industry application:
- CustomerServiceComms:AppSetup (Communications)
- CustomerServiceForFS:AppSetup (Financial Services)
- CustomerServiceHC:AppSetup (Healthcare)
- CustomerServiceForIns:AppSetup (Insurance)
This operator enables the use of the New Application wizard with the corresponding application template already preselected.
Understanding various options in the New Application wizard
After you log in with the required operator, the New Application wizard displays the appropriate Pega Customer Service application already preselected as the application template.
Additional options that are included in the New Application wizard are described below.
Selecting cases/service requests
In the next step, the New Application wizard displays options to select one or more out-of-the-box service request bundles that are included as part of the Pega Customer Service application. It also displays a select-all option if all service request bundles apply for the new application. Service request bundles group all functionally-related service requests (cases), thereby enabling implementers to choose a bundle that is most relevant to their line of business. For example, in the case shown in the image, an implementer can select the Business bundle that would include all service requests relevant to a B2B line of business. Similarly, they can select the Consumer bundle if their line of business represents B2C. They can also select both.
Based on the service request bundle selected, the New Application wizard displays the list of all service requests included in the bundle as preselected, to be included in the new implementation application. Implementers can then browse this list and retain the service requests that are relevant to their minimum lovable product (MLP) implementation and clear the check boxes for the rest of the service requests. They also have an option to reset the selections or include all service requests. Additionally, they can use the Show more option to see the service requests that are not selected and were part of other bundles that were not selected in the previous step. Use this step to carefully determine the service requests that you want to include in your new application.
Note that for any service requests that you did not add during application creation, you can import later by using Case Designer after the new application is created.
Selecting data objects and data types
The next step is to select the data entities and data types that are relevant to the line of business. The bundle selected in the prior step is also used to group all logically-related data types. Based on the bundle selection, all the data types that are part of the selected bundle display as preselected. Implementers can retain the relevant data entities that they want to include in the new application and remove the rest. Similar to service requests, implementers have an option to reset the selections made or include all data types irrespective of bundle selection. These data types represent the logical data model and the out-of-the-box data entities that are offered by Pega Customer Service applications and used for service requests, composites, and other application features. Implementers should carefully select the data entities that they want to leverage from the customer service application to be included in their new application based on their MLP implementation scope.
Selecting interaction channels
Implementers can use this step to select the channels that they want to support in their new application. Out-of-the-box interaction types include Inbound phone, Email, Outbound phone, Chat (includes all messaging channels, including Twitter, Facebook Messenger, Apple Business Chat, Short Messaging Service, and WhatsApp), Mobile, Web, and IVR. Selecting the relevant interaction types will include the interaction infrastructure for such channel types in the new implementation application. Implementers can choose to select all interaction types. Also, if they do not select an interaction type during new application creation, they can still add such interaction types later by using Import case type in Case Designer. This step also ensures that the corresponding interaction drivers are copied into the new application.
Enable Customer Decision Hub
If implementers plan to leverage Customer Decision Hub for decisioning and integrating marketing capabilities with their customer service application, they can enable this option. Implementations should license Customer Decision Hub to enable interoperability with the customer service application. By default, this enablement is disabled. This step ensures the creation of the relevant integration artifacts that are needed for marketing capabilities in the new application.
After all the above steps are completed, implementers can enter the new application name and click Create application to proceed. For this option, the New Application wizard uses the application name and an auto-generated organization name to generate the class structure for interactions and service requests inheriting from the class groups from the application template. Use this option when you do not need granular control over how the class structure is generated.
If you are building a framework application or want to control how the class structure should be generated based on for example, organization, division, and unit, complete the Advanced configuration section of the wizard.
Select the application structure
As explained in the prerequisites, use an appropriate application structure, framework or implementation, based on whether you want to support multiple companies or lines of business. Also provide an application name and version.
To control the class structure that is generated and introduce more layers of pattern inheritance, Pega provides the Organization name, Division name, and Unit name (three levels of hierarchy). The organization that you provide is used to generate the class structure for the class group including the application name. You can include further granularity by selecting the class layers at the division and unit levels, which is then used to generate the case class structure.
You can review the class structure before application creation and make changes accordingly. Class names are limited to 56 characters. Implementers may need to manually edit the automatically generated class names as the New Application Wizard will not allow implementers to proceed until they are updated. Error messages are displayed next to the classes which exceed the class limit.
Click Save after the class structure is confirmed and then click Create Application to proceed with new application creation. This process can take a couple of minutes to complete.
Creating new operators
Note that no new operators are created for the new implementation application. After the new application is created, implementers can create new operators by providing their email addresses and associating them with the access groups that are cloned from the application template. More than one operator can be created and can be invited to access the new application by using Send invitation feature along with system-generated passwords. Implementers can also associate existing operators with the new application by using the corresponding cloned access group.
Go to new application
Use the Go to app button to navigate to the new implementation application and start with the implementation and configuration steps in App Studio. The operator used for creating the new application is updated with the Author access group for the new implementation application.
Validate all created implementation artifacts
- Based on the interaction types selected as part of the New Application wizard, the corresponding interaction classes are created with the interaction driver.
- Based on the service requests selected, the corresponding service case type classes are generated with case type rules and intent tasks.
- Based on the data types selected, categories can be reused in the interaction drivers.
- The Customer Decision Hub option generates the corresponding application setting rules that enable the usage of the relevant service APIs. Additionally all integration artifacts are also generated.
- The class group is generated based on the advanced configuration settings. If multiple work pools and class groups are in the application template, multiple class groups are generated for the new application as well (for example, Grp1-, Grp2-).
- Access groups, access roles, and personas are cloned in the new implementation application.
- Application settings data transforms are created with dynamic class references and default settings in the new application, rendering the application ready to use with out-of-the-box service requests and data objects.
- Node-level data pages are cloned in the new application with the cloned access group to set the correct new application context.
For more information on using the the New Application wizard, see Creating your Pega Customer Service implementation application.