Converting a CPM CSR Portal to a CPM Interaction Portal
This article explains the steps required to convert an existing CPM CSR Portal to a CPM Interaction Portal.
HFix-21430 is recommended to be installed after the CPM 7.1.3 upgrade. Contact Global Customer Support (GCS) to obtain this hotfix.
To convert the CPM CSR Portal to CPM Interaction Portal, follow these steps:
- Configure the CPM Interaction Portal
- Update the interaction flow
- Retrofit custom harnesses into the interaction class
- Populate data pages
- Copy data from interaction to service items
- Update Service Tasks
- Retrofit custom harnesses into the work class
- Interaction composite details
- Retrofit wrap-up functionality
CPMInteractionPortal and update a new access group to include CPM standard roles.
CPM CSR Portal (pre-CPM 7.1)
CPM interaction Portal (CPM 7.1)
In CPM 7, the Interaction Portal uses the flows CPMInteraction and CPMInteractionDriver instead of CAInteraction and CAInteractionDriver, which were used in previous versions of CPM.
Any customizations implemented using CAInteraction and CAInteractionDriver must be ported to instead use CPMInteraction or CPMInteractionDriver.
As a part of CPM 7.1.3, all CPM harnesses are updated with Pega 7 OOTB features. Copy these harnesses into custom rulesets and retrofit all the harness level customizations into the respective harnesses.
Update the custom Perform harness
The custom Perform harness needs to be updated to work with the new CPM user interface. Resave the OOTB Perform harness in PegaCA-Work-Interaction-Call. Perform and retrofit any customizations as required.
Perform harness (pre-CPM 7.1)
Perform harness (CPM 7.1)
In CPM versions previous to CPM 7.1, a thread family page called CAPortalInteraction was used for sharing between interaction and service processes. Currently, in the event of any changes, syncing with Interaction pyWorkPage instances is manually performed.
In CPM 7.1, requestor level data pages are created on demand for maintaining the data.
Customer-related data in CPM 7.1.3, Account and Contact, are referred to in the data pages D_Account and D_Contact, respectively.
Both Interaction and Service process pages, pyWorkPage.Account and pyWorkPage.Contact refer to data pages, D_Account, D_Contact respectively in the new design. These pages are auto populated on demand when a service case is launched from the Interaction work page.
Populate contact details
The D_Contact_Details data page is auto-populated with customer contact details in an interaction when a contact is selected. This data page populates the data to the service case from the interaction case when a new service case is triggered. Both D_Contact_Addressses and D_Contact_CommOptions are simultaneously populated.
In OOTB CPM, the data page is auto-populated based on the page property PegaCA-Work.Contact.ContactID.
Override the Load activities of the respective Data pages to populate the customer specific data.
Populate pyWorkParty (Contact) details a data page, D_Contact_Party, which is auto populated based on the Declare Onchange Trigger, CPMGetContactData on Contact.ContactID.
Interaction Driver Data and Service Case Data is displayed using data pages (parameterized). The following sections detail the different data pages that are auto-populated.
Driver data pages
- D_TasksListForMenu – Take Action menu
- D_SuggestedTasks – Suggestions
- D_QueuedTasks – To do items
- D_CompletedItems – Completed Item. Can be used to display a Log.
Other data pages
- D_CPMInteractions – A requestor level page that is maintained and is filled by iterating through the pzRecentsCache OOTB data page. Records are filtered by the custom property Type.
- D_ServiceCases – Used by applying the current interaction pyID for the services case. It can be a parameterized data page (requestor level) or a Thread Family level data page.
- D_CPMPortalContext – Always maintains the current interaction context details when multiple interactions are opened or while switching between multiple interactions.
- D_CPMInteractionDriverVisibility – Maintains all interaction IDs that are open in the particular requestor session. The DriverVisible property uniquely identifies the current active interaction.
- D_CPMPortalRecents – Lists all interaction details open by the current requestor session.
- D_CPMServiceCaseRecents – Lists all triggered service cases.
CACopyParentData, used in CPM versions earlier than CPM 7.1 for populating data to the service cases, is no longer used in the new Interaction Portal. Accordingly, any respective changes have to be retrofitted using the data transform CPMSetDefaults or the activity NewDefaults.
It is recommended to use the CPMSetDefaults data transform to copy all required data from an Interaction to a Service Case. If any other custom logic (which cannot be achieved using data transform) is required, then use the NewDefaults activity.
If the NewDefaults activity has to be overridden, then perform the following steps:
- Copy the NewDefaults activity rule from CPM OOTB into the respective custom work class (for example, PegaCA-Work) activity. Do not remove the first step, because it is required for CPM to work correctly.
- Copy the NewDefaults activity rule from CPM OOTB into the respective custom Interaction Class (for example, PegaCA-Work-Interaction) activity and remove the first step. This step is required for CPM to work correctly.
If the NewDefaults activity exists in the work class, then add the first step to call the CPMNewDefaults activity. This is mandatory for CPM Portals to work correctly.
Update the service process flows and intent tasks
Starting in CPM 7.1.3 for the use of CPM Interaction Portal, the intent task is driven by the starting flow instead of the starting activity.
- All service process flows must be created as starter flows.
- All intent tasks must be updated with the corresponding service process flows by checking the following options in the Process tab of the flow:
- Create a new work object
- Skip create harness
- All intent tasks must be updated with the corresponding starting flow and task class.
Update the flow actions
Configure the flow action’s Action area and Back-to-back Processing Configuration, based on business need. This depends on whether you want to display the Confirm harness or close the work object.
For example, the flow actions must be updated in the Action button to close the work object if any assignment is not performed, rather than displaying review harness.
This update must be performed for all of the flow actions in the intent task flows.
As a part of CPM 7.1.3, all of the CPM harnesses are updated with Pega 7 OOTB features. Copy these harnesses into the work class of custom rulesets and retrofit all of the harness level customizations into the respective harnesses.
The custom Perform harness must be updated to work with the new CPM user interface. Resave the OOTB Perform harness in PegaCA-Work. Perform and retrofit any customizations as required.
Perform harness (pre-CPM 7.1)
Perform harness (CPM 7.1)
Prior to CPM 7.1, composite data was displayed using the CAComposite harness rule. In CPM 7.1.3, the CPMCompositeContainer auto-generated section holds the composite data.
The OOTB CPMCompositeContainer section container holds the Account, Business Unit, and Summary data sections.
Retrofit the changes from the CAComposite to the CPMCompositeContainer section by:
- Save-As the OOTB CPMCompositeContainer section to custom ruleset or class.
- Create a new wrapper section and embed all of the sections to be displayed as a part of the interaction composite details in a tabbed group.
- Include the wrapper section in the CPMCompositeContainer section.
CA Composite (pre-CPM 7.1)
CPMSummaryComposite_New (CPM 7.1.3)
For wrap-up functionality in releases prior to CPM 7.1, the CAWrapUp flow was used. Starting in CPM 7.1.3, this process has been updated to use CPMWrapup. Any customizations on the CAWrapUp flow must be retrofitted back to the CPMWrapup flow.
- Ensure that the
- Save-As the CPMWrapUp flow to a custom ruleset or class and incorporate or retrofit the existing functionality.