Creating a new implementation application on Pega Customer Service
|Request to Publish||Yes|
|Description||Understand the options presented while running the new application wizard to make informed choices while building a new implementation application|
|Version as of||8.5|
|Capability/Industry Area||All industries|
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ Please Read Below ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
Enter your content below. Use the basic wiki template that is provided to organize your content. After making your edits, add a summary comment that briefly describes your work, and then click "SAVE". To edit your content later, select the page from your "Watchlist" summary. If you can not find your article, search the design pattern title.
When your content is ready for publishing, next to the "Request to Publish" field above, type "Yes". A Curator then reviews and publishes the content, which might take up to 48 hours.
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ The above text will be removed prior to being published ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
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, channels to determining the application structure. In this article, we will understand these options to help make informed decisions while building a new custom implementation application to avoid rework or refactor at a later point. We shall also understand the artefacts created in the new application as a result of these choices that would help speed up the implementation and hence reduce costs.
The steps detailed below shall apply for any Pega Customer Service application irrespective of the business vertical. The screenshots used below are for illustration purpose only. The actuals 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. Below should help you make that decision:
- Build a new framework application if you have multiple companies, line of business or entities that may a 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 to build multiple applications representing each entity.
- Ensure you have an operator that points to access group - CustomerService:AppSetup - if you wish to build an application on top of Pega Customer Service. For the Pega Customer Service vertical applications, your operator should point to either of these access groups based off business vertical - CustomerServiceComms:AppSetup (Communications); CustomerServiceForFS:AppSetup (Financial Services); CustomerServiceHC:AppSetup (Healthcare); CustomerServiceForIns"AppSetup (Insurance). This operator will enable us land us in the new application wizard with the corresponding application template already pre-selected.
Understanding various options presented in new application wizard
Once we login with requisite operator, we would see the new application wizard with the appropriate Pega Customer Service application already pre-selected as the application template.
Lets try to understand the other options presented as part of the new application wizard:
Selecting cases / service requests
In the next step, new application wizard present 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 eg. 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 "Consumer" bundle if their line of business represents B2C. They can select both as well.
Based on service request bundle selected, the application wizard will present the list of all service requests included in the bundle as pre-selected 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 included in your new application.
Do note any service requests not added during application creation can still be imported later after new application is created using Case Designer.
Selecting data objects / types
Next step is to select the data entities / types 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 bundle selection, all data types part of the selected bundle are presented as pre-selected. Implementers have an option to retain the relevant data entities that they want to be included 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 they want to leverage from the customer service application to be included in their new application based on their Minimum Lovable Product (MLP) implementation scope.
Selecting interaction channels
Implementers can use this step to select the channels they wish 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, 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 using "Import case type" later in Case Designer. This step also ensures 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 server application, they can enable this option. Implementations should license for Customer Decision Hub to enable interoperability with customer service application. By default this is disabled. This step ensures to create the relevant integration artefacts needed for marketing capabilities in the new application.
Once all above steps are completed, implementers can simply provide the new application name; and click on "Create application" to proceed. For this option, application wizard uses the application name and an auto-generated organization name to generate the class structure for interactions and service requests inhering from the class groups from the application template. Use this option when we do not need granular control over how the class structure is generated.
But if we are building a framework application or we want to have control over how the class structure should be generated based on say Organization, Division, Unit; then use "Advanced configuration".
Select Application structure
As explained in 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 (3 levels of hierarchy). Organization provided is used to generate the class structure for the class group including the application name. We can include further granularity by selecting the class layers at the Division / Unit level which is then used to generate the case clalass structur
You can review the class structure before application creation and make changes accordingly.
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 author access group for the new implementation application.
Validate all implementation artefacts created
- Based on interaction types selected as part of new application wizard, the corresponding interaction classes will be created along with interaction driver.
- Based on the service requests selected, corresponding service case type classes shall be generated along with case type rule, intent tasks.
- Based on data types selected, categories can be reused in the interaction drivers.
- The Customer Decision Hub option will generate the corresponding application setting rules that would enable usage of the relevant service APIs. Additionally all integration artefacts will also be generated.
- The class group shall be generated based off the advanced configuration settings. If there were multiple work pools / class groups in the application template, multiple class groups shall be generated for the new application as well (For eg. Grp1-, Grp2-).
- Access groups, access roles, personas shall 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 shall be cloned in the new application with the cloned access group to set the correct new application context.