Hi Bramesh,

1) Multiple users should have the ability to open Work Objects is  read only mode at the same time  

--> As suggested by everyone, we will have a review harness for all the users to open a Work Object in read only mode.

2 While one / many users have work object in read only mode, one of the users should be able to enter 'edit' mode for the WO  .

--> Using the below screen shot, one of the user will be able to enter 'edit' mode for the WO  .

3 User in edit mode would be able to resolve the case w/o error . 

--> After updating the WO, you might resolve the case using the below option (Save)

4 If a user in Read Only mode attempts to transfer the case to him/her self where the WO was recently resolved by another user, and error should be generated indicating the case has been resolved  .

--> Dont provide the transfer or Claim option when the case has been resolved or display proper error message saying that the case has been resolved when the user tries to claim the case

Thanks to all for sharing the approaches. 

I do agree on whenever user opens a work object by Search box then case would be displayed in review mode, where WO’s are not getting locked ,Hence multiple users can open it  at a time.

As per our App process, all work objects gets routed to the WB ,and any of the user can act upon it by pulling it up through GetNextWork or directly  from work basket.

By configuring the Default locking mechanism(V7.1.6), user holds the lock on assignment by opening it from WB/WL itself ,so locking exception is comes up for other users who are trying to open the same assignment.

From my perspective ,following are major blockers of this specification:

1)    Assignment to be opened in read-only mode for all users when it gets opened.

Assumption :it can be done by displaying the flow action in read-only mode by using FLAG /Privileges.

2) Assignment shouldn't be locked by simply opening it by users, and users should be acquired the lock until & unless takes any action explicitly  (like Edit button).

Assumption: I’m thinking to release the lock forcibly(during assignment open)  by calling  OTB unlock activity at Pre-Processing of the flow action,and if user want to edit/approve the assignment then user has to click on edit button where WO gets locked by current requestor.

Please share your suggestions & let me know if need more information regarding this.

Thanks,

Brahmesh.

Hi Brahmesh,

You summed up most part of the scenario, how ever little changes are required.

1)  Assignment to be opened in read-only mode for all users when it gets opened.

Solution: Use Optimistic Locking. 

2) Assignment shouldn't be locked by simply opening it by users, and users should be acquired the lock until & unless takes any action explicitly  (like Edit button).

Solution: Use Actions --> Claim / Edit. Configure the menu item to acquire the lock for the case. Set PRIV / FLAGS so that if another user tries to get the lock, either option is not shown or displays appropriate error messages. 

Pros: Most part of the solution is OOTB with very little customizations

With this, even SLA agents cant update the CASE or WO as it is locked. Later on broken queue item can be examined or deleted as the need would be for SLA items.

Cons: If any user say U1 directly submits the CASE with out clicking Actions-->Claim/Edit, and no other user has claimed the lock, then changes made by U1 woudl be submitted by acquiring lock and other users would see error screens when acquiring lock. 

To negate this, we can customize Work-pyCaseActionAreaButtons to not include any action buttons like Submit and then in the work section include a Button equivalent to Submit action, and check if user has acquired Lock, if yes, contine with Finish Assignment else, ask user to acquire lock by Clicking Action --> Claim / Edit and then Submit. Little Extra work :( 

Vamshi