SLA updates the Work record but not the pxUpdateOperator
We are seeing that when SLA's are running to increment the Urgency on assignments, the SLAs are also updating the Work record and what we are seeing is that the pxCommitDateTime and the pxUpdateDateTime are incremented however the pxUpdateOperator is remaining the same as the old User who last updated the case. We are using BIX to extract the Case data to the Data Warehouse system and they say if any of the users pull any Compliance reports using their BI tools, it will report that the user has performed an update when in reality the System (SLA) has performed an update. What we have also seen is that the pxAddedByID and the pyPerformed on the HISTORY tables say System and Service Level Agent.
What I have seen is that the SLAs run the activity ProcessEvent which calls ExecuteSLA. Step 22 of the ExecuteSLA updates the pxUpdateDateTime on the pyWorkPage and saves it. There is no update to the pxUpdateOperator however.
I have a document attached that details what we are seeing both on the Pega side as well as on the Datawarehouse side when the BIX runs have been run.
We are seeing that when SLA's are running to increment the Urgency on assignments, the SLAs are also updating the Work record and what we are seeing is that the pxCommitDateTime and the pxUpdateDateTime are incremented however the pxUpdateOperator is remaining the same as the old User who last updated the case. We are using BIX to extract the Case data to the Data Warehouse system and they say if any of the users pull any Compliance reports using their BI tools, it will report that the user has performed an update when in reality the System (SLA) has performed an update. What we have also seen is that the pxAddedByID and the pyPerformed on the HISTORY tables say System and Service Level Agent.
What I have seen is that the SLAs run the activity ProcessEvent which calls ExecuteSLA. Step 22 of the ExecuteSLA updates the pxUpdateDateTime on the pyWorkPage and saves it. There is no update to the pxUpdateOperator however.
I have a document attached that details what we are seeing both on the Pega side as well as on the Datawarehouse side when the BIX runs have been run.
The issue from the client is that when looking at just the Work table, the data is inaccurate since the User did not perform any updates on the case but when I look at the data it looks like the User did make an update. And to perform a Join against the Case History to get the pyPerformer or pyAddedByID is too expensive in the DWH environment because of the volume of data we will have in the Case History. Also, BIX does not support Joins on a table if I were to extract the data from Case History and send the pxAddedByID or the pyPerformer.
The ask from the client is can the pxUpdateOperatorId be updated to System on the Work table since System is the true performer.
Reproduction Steps:
1. Create a new case with an assignment that has a SLA (ideally set with a 2 min goal)
2. After creating the case, see that the pxCreateOperator and pxUpdateOperator is your id and also make a note of the pxUpdateDateTime and pxCommitDateTime
3. Once the SLA has run, you will see that the pxUpdateDateTime and pxCommitDateTime has been updated, the pxUpdateOperator is still your id. Also in the History tables with the same time stamps you will see an entry for the SLA.
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.