Question
ANZ
AU
Last activity: 14 Jul 2022 21:19 EDT
How to filter SLA broken queue items based on assignment handle
Hi All ,
Is there any way OOTB pega that we can filter out a broken queue item from thousand of broken queue items by case id /assignment id ?
Also , exposing pxAssignmentHandle in pr_sys_queue_sla table is good idea to easily identify the cases ?
Accepted Solution
Updated: 14 Jul 2022 21:19 EDT
Lventur
IN
Lventur
IN
@Srikanth Gaddamanugu
We are not having Pega OOTB rules to achieve your logic. But you could achieve this by having a simple report definition.. You need to use work-object pzInsKey in this scenario not pyID. Because pega will maintain the work and assign- table link by using pzInskey of work-object.
- To get particular work-object broken-item information, pass the work-object pzinskey as input parameter and in filter have .pxRefObjectKey = Param.pzInsKey and .pxAssignedOperatorID= "BrokenProcesses", have your report definition in Assign-WorkBasket class. This should help you in getting particular work-object related broken item information
- To get particular work-object and particular agent related broken item information have the same logic in report definition as mentioned above, but have another one additional filter .pxCreateOpName = Agent Name. For example you want to fetch SLA related broken item of work-object then filter should have below condition. A AND B AND C
- A = .pxRefObjectKey = Param.pzInsKey
- B = .pxAssignedOperatorID= BrokenProcesses
- C = pxCreateOpName = Agent(System-Queue-ServiceLevel.ProcessEvent)
ANZ
AU
@Gunasekaran_Baskaran
With First point
We can get only the assignmentKey for that case id . That will not solve my purpose.
But my requirement is , I want the pyItemID of the Broken queue for the given case id , knowing that there is a broken item for that case
in other way ,
I need filtering mechanism on the broken queue items , to fetch the broken item for given case id .
Lventur
IN
@Srikanth Gaddamanugu
For getting Item ID, please have below filter in logic
Mail RD should be in Assign-WorkBasket
Filter A
A = .pxRefObjectKey = Param.pzInsKey and .pxAssignedOperatorID= "BrokenProcesses"
In the same RD join condition, have System-Queue-ServiceLevel as join class (Join Alias = SL).
Join Type = Inner Join -> Only Include Matching Rows
Join Filter = SL.pxAssignmentHandle = .pzInsKey.
In main RD filter column you can include SL.pyItemId. This should help you in getting itemid of queue sla agent entry by passing case pzInsKey.
Pega will maintain the link between System-Queue-ServiceLevel and Assign-by maintaining pzInsKey of Assign- table entry in pxAssignmentHandle property of SLA Queue table.
ANZ
AU
@Gunasekaran Baskaran Thanks for your response .
But back to my first post , I have to optimize the pxAssignmentHandle in the pr_sys_queue_sla table right ?
As of now it is not an exposed column from Pega OOTB .
Also if we have to do , I want to understand will there be any issues to the existing SLA items and any other performance issues ?
Lventur
IN
@Srikanth Gaddamanugu
Exposing a column should not have any negative impact and it will not impact any performance.
If needed we can expose the column in pega OOTB tables and use that for our business specific logic. Pega is not having any restrictions on this.
For existing SLA entries you might need top run a OTA for updating the values in exposed column (or) you can use the pega OOTB column population job.
ANZ
AU
@Gunasekaran Baskaran Thanks for that reply . So i think that is only option left for us right .
Or Do you have any other ideas ?
Accepted Solution
Updated: 14 Jul 2022 21:19 EDT
Lventur
IN
@Srikanth Gaddamanugu
This implementation via expose column and report definition will not have any negative impact.
Another option would be, you need to browse all broken items and then build logic to find respective case related information. This will results in unwanted looping and impact performance also.
@Srikanth Gaddamanugu
This implementation via expose column and report definition will not have any negative impact.
Another option would be, you need to browse all broken items and then build logic to find respective case related information. This will results in unwanted looping and impact performance also.