Creating a new implementation application on Pega Customer Service
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 build their custom application with ease while recognizing the various options 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 to avoid rework or refactor at a later point. Also described are the artifacts created in the new application as a result of these choices that help speed up the implementation and hence reduce costs....
The following steps apply for any Pega Customer Service application regardless of the business vertical. The screenshots used below are for illustration purposes only. The actual screens may 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. The following considerations can help you make that decision:
- Build a new framework application if you have multiple companies, line of business, or entities that share a common set of assets. Then build a new implementation application for each such 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 an access group, CustomerService:AppSetup, if you want to build an application on top of Pega Customer Service. For the Pega Customer Service vertical applications, your operator should point to one of these access groups based off the business vertical: CustomerServiceComms:AppSetup (Communications), CustomerServiceForFS:AppSetup (Financial Services), CustomerServiceHC:AppSetup (Healthcare), or CustomerServiceForIns:AppSetup (Insurance). This operator enables 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 is displayed with the appropriate Pega Customer Service application already preselected as the application template.
The following additional options are presented in the New Application wizard.
Selecting cases/service requests
In the next step, the New Application wizard presents options to select one or more out-of-the-box service request bundles included as part of the Pega Customer Service application. It also presents a select-all option if all service request bundles apply for the new application. Service request bundles group all functionally related service requests (cases) enabling implementers to choose a bundle that is most relevant to their line of business. For example, in the below case, an implementer can select the Business bundle that would help include all service requests relevant for 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 presents 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 for their minimum lovable product (MLP) implementation and unselect the rest. 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 any service requests not added during application creation can still be imported later by using Case Designer after the new application is created.
Selecting data objects/types
The next step is to select the data entities/types that are relevant for 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 part of the selected bundle are presented 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 (OOTB) data entities offered by Pega Customer Service applications 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, 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 implementations 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 creation of the relevant integration artifacts 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 autogenerated 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.
But 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, use Advanced configuration.
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 generated and introduce more layers of pattern inheritance, Pega supports providing the Organization name, Division name, and Unit name (three levels of hierarchy). Organization provided 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/Unit level, which is then used to generate the case class structure.
You can review the class structure before application creation and make changes accordingly.
Click on "Save" once the class structure is confirmed and then click on "Create Application" to proceed with new application creation. This process can take a couple of minutes to complete.
Creating new operators
Please note no new operators are created for the new implementation application. Once the new application is created, implementers can create new operators by providing their email addresses and associate them to the access groups cloned from the application template. More than one operators can be created and they can be invited to access the new application by using "Send invitation" feature along with system generated passwords. Implementers can also associate existing operators to the new application 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 implementation artifacts created
- Based on the interaction types selected as part of New Application wizard, the corresponding interaction classes will be created along with the interaction driver.
- Based on the service requests selected, the corresponding service case type classes are generated along with case type rule, 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 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/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 will be cloned in the new implementation application.
- Application settings data transforms will be 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 will be cloned in the new application with the cloned access group to set the correct new application context.