Question
Virtusa Consulting Services Private Ltd
IN
Last activity: 23 May 2022 21:12 EDT
Passing customerID and accountNumber together in SimpleProcessOffer
We are upgrading to Pega marking CDH FS to 8.5 from Pega NBAFS 7.1. In Pega 8.5, we have to run offers with Context Dictionary. Context has to be on CustomerID & Account number passing parametrs for ProcessWSRequest. Here Genericoffer instance creates with AccountNumber as key. Generic offer Instances creation in earlier versions of Pega are forming with format as CustomerID:AccountNumber to keep the instances with unique key. When we try to do the same in 8.5, processing not able to determine the prmiary contact although the context dictionary set up is proper. The same is working fine when creating Genericoffer instances with CustomerID as key. However, we have some customers linked to multiple accounts / some accounts linked to multiple customers. We can not have the Genericoffer instances created with CustomerID as this is not going to be unique for offer deriving.
Solutions tried below
1. Customized the processWsRequest with different name in our application as this is a Final activity in 8.5. We are passing CustomerID in step 19.2 and secondary Context class as blank to keep the key as required along with other reuired parameters for SimpleProcessOffer activity.
2. Tried debugging offer processing keeping "com.pega.mkt.offer.OfferEngine" class in debug mode to see any errors, there is not much help here. No error displayed here.
We are upgrading to Pega marking CDH FS to 8.5 from Pega NBAFS 7.1. In Pega 8.5, we have to run offers with Context Dictionary. Context has to be on CustomerID & Account number passing parametrs for ProcessWSRequest. Here Genericoffer instance creates with AccountNumber as key. Generic offer Instances creation in earlier versions of Pega are forming with format as CustomerID:AccountNumber to keep the instances with unique key. When we try to do the same in 8.5, processing not able to determine the prmiary contact although the context dictionary set up is proper. The same is working fine when creating Genericoffer instances with CustomerID as key. However, we have some customers linked to multiple accounts / some accounts linked to multiple customers. We can not have the Genericoffer instances created with CustomerID as this is not going to be unique for offer deriving.
Solutions tried below
1. Customized the processWsRequest with different name in our application as this is a Final activity in 8.5. We are passing CustomerID in step 19.2 and secondary Context class as blank to keep the key as required along with other reuired parameters for SimpleProcessOffer activity.
2. Tried debugging offer processing keeping "com.pega.mkt.offer.OfferEngine" class in debug mode to see any errors, there is not much help here. No error displayed here.
3. Offer Initiation is working fine here. Determining offer and initiating Interaction, setting waitExpiry are working as expected.
4. The same configuration is not working when resuming the offers from ResumeGenericFlow, running via agent / stand alone using tracer.
5. There are no errors displayed with trace, no errors coming in logs as well. But, Genericoffer instance is failing to resume and it's having status as failed with error "Unable to determine the primary contact for this Offer"
Appreciate your help with in the below challenges
1. How can we have CustomerID and Account number together stored in Genericoffer instaces?
2. What are configuartions need to be changed ?
3. What are changes needed in ResumeGenericFlow agent activity to wake these offers from agent?
***Edited by Moderator Marissa to added Capability tags***
Accepted Solution
Updated: 23 May 2022 21:12 EDT
Pegasystems Inc.
US
Had a discussion with @S_KODATI and captured below details.
Here the relationship between Customer and Account is Many to Many. ie, Customer is like Party,Party can belong to multiple Accounts and vice versa.
In prior implemenetations of Collections, Offer flow was initiated using a combination of CustomerID and AccountNumber where the AccountNumber is used for fetching the Actual account in collections (A separate AccountsInContext page is formed during runtime to map the account level properties). This is no longer required with multi-level decisioning capabilities in latest versions of CDH and collections activity initiates offer flow with Account as the context and SubjectID set to AccountNumber.
Now when Collections process is initiated against Account, it will notify against the primary Customer contact identified. This is a problem as all the parties belonging to the Account needs to be notified. Hence a solution is proposed for initiating Collections against Customer (After identifying Customers belonging to Account in collections in a loop) using the same CustomerID:AccountNumber concatenated string. Supporting change is proposed in the overridden SimpleProcessOffer activity to set saved the value to CustomerID and AccountID (Existing property in Data-Decision-Request-Customer class) separately before invoking ProcessOffer.
Had a discussion with @S_KODATI and captured below details.
Here the relationship between Customer and Account is Many to Many. ie, Customer is like Party,Party can belong to multiple Accounts and vice versa.
In prior implemenetations of Collections, Offer flow was initiated using a combination of CustomerID and AccountNumber where the AccountNumber is used for fetching the Actual account in collections (A separate AccountsInContext page is formed during runtime to map the account level properties). This is no longer required with multi-level decisioning capabilities in latest versions of CDH and collections activity initiates offer flow with Account as the context and SubjectID set to AccountNumber.
Now when Collections process is initiated against Account, it will notify against the primary Customer contact identified. This is a problem as all the parties belonging to the Account needs to be notified. Hence a solution is proposed for initiating Collections against Customer (After identifying Customers belonging to Account in collections in a loop) using the same CustomerID:AccountNumber concatenated string. Supporting change is proposed in the overridden SimpleProcessOffer activity to set saved the value to CustomerID and AccountID (Existing property in Data-Decision-Request-Customer class) separately before invoking ProcessOffer.
Note: This solution is very specific to Customer implementation here. It's reccomended to update to latest version of CDH and implement the design using Next Best Action Designer. https://docs-previous.pega.com/pega-customer-decision-hub-collections-user-guide/86/pega-customer-decision-hub-collections-86-user-guide
Updated: 23 Dec 2021 11:45 EST
Pegasystems Inc.
US
This question is in the context of a Pega Collections implementation where Customer Decision Hub for Financial Services acts as the contact strategy engine for Customer Service. The ideal recommendation here is for the customer to adopt the modern Next Best Action Designer and move away from the ProcessWSRequest SOAP service. However, I am aware this is an upgrade project and the team is trying to achieve parity with the prior version.
Accepted Solution
Updated: 23 May 2022 21:12 EDT
Pegasystems Inc.
US
Had a discussion with @S_KODATI and captured below details.
Here the relationship between Customer and Account is Many to Many. ie, Customer is like Party,Party can belong to multiple Accounts and vice versa.
In prior implemenetations of Collections, Offer flow was initiated using a combination of CustomerID and AccountNumber where the AccountNumber is used for fetching the Actual account in collections (A separate AccountsInContext page is formed during runtime to map the account level properties). This is no longer required with multi-level decisioning capabilities in latest versions of CDH and collections activity initiates offer flow with Account as the context and SubjectID set to AccountNumber.
Now when Collections process is initiated against Account, it will notify against the primary Customer contact identified. This is a problem as all the parties belonging to the Account needs to be notified. Hence a solution is proposed for initiating Collections against Customer (After identifying Customers belonging to Account in collections in a loop) using the same CustomerID:AccountNumber concatenated string. Supporting change is proposed in the overridden SimpleProcessOffer activity to set saved the value to CustomerID and AccountID (Existing property in Data-Decision-Request-Customer class) separately before invoking ProcessOffer.
Had a discussion with @S_KODATI and captured below details.
Here the relationship between Customer and Account is Many to Many. ie, Customer is like Party,Party can belong to multiple Accounts and vice versa.
In prior implemenetations of Collections, Offer flow was initiated using a combination of CustomerID and AccountNumber where the AccountNumber is used for fetching the Actual account in collections (A separate AccountsInContext page is formed during runtime to map the account level properties). This is no longer required with multi-level decisioning capabilities in latest versions of CDH and collections activity initiates offer flow with Account as the context and SubjectID set to AccountNumber.
Now when Collections process is initiated against Account, it will notify against the primary Customer contact identified. This is a problem as all the parties belonging to the Account needs to be notified. Hence a solution is proposed for initiating Collections against Customer (After identifying Customers belonging to Account in collections in a loop) using the same CustomerID:AccountNumber concatenated string. Supporting change is proposed in the overridden SimpleProcessOffer activity to set saved the value to CustomerID and AccountID (Existing property in Data-Decision-Request-Customer class) separately before invoking ProcessOffer.
Note: This solution is very specific to Customer implementation here. It's reccomended to update to latest version of CDH and implement the design using Next Best Action Designer. https://docs-previous.pega.com/pega-customer-decision-hub-collections-user-guide/86/pega-customer-decision-hub-collections-86-user-guide