Question
Medical Mutual
US
Last activity: 15 Aug 2016 16:12 EDT
When/How does a user take ownership of work from a workbasket?
Hello All,
We are currently using Pega v6.3 SP1 and are in the process of upgrading to PRPC v7.2. I am currently working on a requirement to understand Pega OOB functionality and best practices in regards to when/how users view and take ownership of work. Specifically, I want the following questions answered for PRPC v 7.2 -
1. When/how does a work object move from a workbasket to a user's work list i.e. gets assigned to the user's worklist? (i.e. Does it happen automatically when they open a work object from a workbasket or the contact history or search by Interaction/Service Intent ID?)
2. If the transfer happens upon "update" of a work object, what constitutes an update? (i.e. It doesn't change upon updating notes, so when does it happen?)
3. What is best practice for allowing a user to move a work object to a resolved state? (i.e. How should the user know that clicking submit will resolve the work object rather than taking them to the next step in the process?)
Any related information/ help will be much appreciated!
Thanks,
Harman
***Updated by Moderator: Lochan. Removed user added helpme and Ask the Expert tags. Apologies for confusion, shouldn't have been an end-user option; updated Categories***
PEG
PL
Use "WorkBasket" or Pull based routing.
1. Create a "WorkBasket" and add members to this group
2. Configure additional priority of the task such as complexity of the task, timezone of the user, seniority of the user and skills of the user on the Routing.
3, Under "Assignment Properties" -> "Assignment"->"Router" and select "ToLeveledGroup".
ToLeveledGroup-The system choosing an operator randomly, operators are sorted by workload and desired skills.
3. Set skill-set and time-zone for the user.
Medical Mutual
US
Hi Rajeev,
Thank you for your reply. We do not have any requirement in our application to configure additional priority of the task such as complexity of the task, timezone of the user, seniority of the user and skills of the user on the Routing. Can you please review my questions above and answer those specifically.
Thanks!
Pegasystems Inc.
US
Hi Harmandeep,
With regards to your overall question, to my knowledge the concepts surrounding work object routing are essentially the same in 7.2 as in 6.3. Routing or re-assigning a work object in 7.2 should feel very similar to how it does in 6.3.
With regards to your specific questions:
1. By default, when an operator opens a work object from a workbasket, the item will not automatically be routed to them. The operator can action the work item (assuming there are no restrictions you've put in place preventing it) but it will remain in the work basket until it is re-assigned(either by routing configured in your flow, or an explicit re-assign) or resolved. This behavior should be very similar to what you already see in 6.3.
2. If I understand your question correctly, it sounds like you're asking "When does a work object get routed?". This is completely configurable, as it was in 6.3. You can configure your flow to perform routing between operators and/or workbaskets, and can have actions that re-assign work objects without advancing the flow. Because workbasket and worklist displays are based off of the values for certain properties on each assignment (such as pxAssignedOperatorID), when a work object is re-assigned or routed, these values must be "updated" as part of that that process. Again, this will be similar to what you currently see in 6.3.
Hi Harmandeep,
With regards to your overall question, to my knowledge the concepts surrounding work object routing are essentially the same in 7.2 as in 6.3. Routing or re-assigning a work object in 7.2 should feel very similar to how it does in 6.3.
With regards to your specific questions:
1. By default, when an operator opens a work object from a workbasket, the item will not automatically be routed to them. The operator can action the work item (assuming there are no restrictions you've put in place preventing it) but it will remain in the work basket until it is re-assigned(either by routing configured in your flow, or an explicit re-assign) or resolved. This behavior should be very similar to what you already see in 6.3.
2. If I understand your question correctly, it sounds like you're asking "When does a work object get routed?". This is completely configurable, as it was in 6.3. You can configure your flow to perform routing between operators and/or workbaskets, and can have actions that re-assign work objects without advancing the flow. Because workbasket and worklist displays are based off of the values for certain properties on each assignment (such as pxAssignedOperatorID), when a work object is re-assigned or routed, these values must be "updated" as part of that that process. Again, this will be similar to what you currently see in 6.3.
3. I do not know if we have a specific "best practice" for allowing a user to move a work object to a resolved state. In most scenarios that I've seen, the last flow action performed by the user will have something on the screen that indicates that, upon submission of the current flow action, the work object is going to be resolved. You may want to consider setting up your resolution flow actions in a similar fashion.
Hope this information helps!
-Kurt