Question
Infosys
NL
Last activity: 9 Jul 2020 5:27 EDT
How to block/ update Pending(Sent) Outcome Status in Interaction History Table
Hello Everyone,
Pega OOTB feature for every outbound offer result for a campaign run IH(Interaction History) is updated with outcome as Pending in Interaction history table.
Up until 8.3 we are filtering such outcomes by updating the backend DF's which were available framework rules for such updates . In order to avoid the overflowing records in IH table with defaults status we followed this approach .
As we moved to 8.4 recently we noticed that most of the marketing OOTB rules are Finalized and not available to and custom modification but we want to stop Data Flows from updating IH or mody the outcome as "Sent" instead of "Pending" which is more meaningful.
Tried to update filed value(Outcome.Pending) in below class but not helpful
If someone was successful in achieving this please share the same, much appreciated.
Hello Everyone,
Pega OOTB feature for every outbound offer result for a campaign run IH(Interaction History) is updated with outcome as Pending in Interaction history table.
Up until 8.3 we are filtering such outcomes by updating the backend DF's which were available framework rules for such updates . In order to avoid the overflowing records in IH table with defaults status we followed this approach .
As we moved to 8.4 recently we noticed that most of the marketing OOTB rules are Finalized and not available to and custom modification but we want to stop Data Flows from updating IH or mody the outcome as "Sent" instead of "Pending" which is more meaningful.
Tried to update filed value(Outcome.Pending) in below class but not helpful
If someone was successful in achieving this please share the same, much appreciated.
Regard's
Manindra
Pegasystems Inc.
US
These parts of the system have been locked down because they have exposed improper customizations. Specifically for your ask, there is no mechanism for changing the IH record from Pending to something else, and in fact it does represent the correct status, as it reflects that it has been queued for delivery, but has not been sent yet. This is a system status that should not be overridden as there can be un-forseen consequences to doing so (even though you might have gotten away with it in prior releases. If you want to have a different label to Pending for reporting purposes, you should be able to do that either as you extract from IH for reporting purposes or in a lookup as part of the report itself.
Updated: 8 Jul 2020 5:49 EDT
Infosys
NL
Thank you for you Reply Saleem,
I am curious to learn as in what specific advantage do we get with a status as Pending?
because "Sent"(Or any other status) make sense for our requirement as it means for us offer has been sent from marketing and to be delivered to customer, we have seperate status called Delivered that will be updated in IH once the end customer receives the offer.
In our case we insert records to IH with multiple status for a single interaction with Pending(OOTB),Sent,Delivered,Redirected,Accepted,Rejeted...etc which is causing performance issue when trying to fetch Interaction History in strategies to as per requirement.
To reduce performance impact we try to reduce the number of IH records by filtering Pending records from getting inserted into IH table. So instead of pega hardcoding the status wouldn't it be more appropriate to provide control over what type of status should it insert because Pending may not be correct status in all scenarios or to everyone.
Our major problem here is performance of strategies with large IH records not just for simple reporting purpose.
Hope you understand our concern here.
Pegasystems Inc.
US
From the original thread above I note that you are using 8.4 and previously 8.3? With more recent versions of the product (8.3 and 8.4 included), its best practice not to fetch history directly from IH, but rather use IH Summaries. This feature is explicitly there to ensure that fetching history is not a performance bottleneck as the IH counts you need in your logic will immediately be available to you without fetching the IH records explicitly. I recommend you transition to this approach for your performance concerns.
Pegasystems Inc.
NL
In addition to Saleem's clarification, I suggest that you go through the latest Decisioning Consultant mission, where you'll learn how to use Next-Best-Action Designer, which uses best practice Decision strategy patterns including Interaction History Summary components. The mission also covers extending the IH summaries to your specific needs.