7

Below is our scenario

We have a custom case object. where ownership is based on queues.

Users are assigned to queues and any user part of a queue gets access to all the cases assigned to the particular queue.

We have a scenario where particular user of the queue can go for a court trial for that case. In that case all other members except for the trial user needs access to the case.

If we remove the user from the queue he will lose access to all other cases assigned to that queue.

If we remove access to the queue for that case then all members of queue lose access to the case.

The solution we came up was to find all users who have access to the case, remove queue based access and then insert user share records for all users except for trial user using apex sharing.

We have millions of cases and queues can have up to 1000 users.

Questions

  1. Is this solution scalable?
  2. Is there a better solution for this scenario?
  3. Is there any way we can do it through configuration instead of code?
Improve this question
10
  • Is this scenario an exceptional case or standard operating procedure?
    – David Reed
    Commented Sep 7, 2018 at 18:35
  • It's a public sector client. On 100 cases 10 cases can have this scenario
    – RedDevil
    Commented Sep 7, 2018 at 18:37
  • Are you trying to do something similar to account teams on custom object? Is there a hard requirement to use queues for this, or you can work with, let's say CaseTeamMember Custom Object?
    – Roman
    Commented Sep 10, 2018 at 13:05
  • I can with caseteams custom object. Can I use teams for custom object?
    – RedDevil
    Commented Sep 10, 2018 at 13:35
  • It seems to me that the very low granularity of the sharing here (up to 1000 users shown any given Case) is going to be a challenge for any proposed solution. Could you say more about why/how so many users need access? Is it possible that the true access requirements could be defined more tightly?
    – David Reed
    Commented Sep 10, 2018 at 14:21

3 Answers 3

Reset to default
4
+50

You can hide the detail layout of the case from the target user going to the court trial.

  1. Create a formula field, is courtgoing User Current user where formula is

    $User.Id= Court_Going_User__c

  2. Use Component visibility of lightning on your detail page layout, enter image description here

and only display detail layout when is court going user current user is false. enter image description here

  1. Also, you can also add a text area to tell the user that you cannot access the case data. enter image description here

You don't have to worry about sharing , Your org seems to be LDV org so sharing table would be extensive, and altering the sharing table having millions of records is slow.

I agree List views would be pain, but if you show non sensetive information in them you can probably save yourself from sharing hell.

Improve this answer
4
  • 1
    Very interesting. Only spoiler is the record can still be accessed through reports
    – RedDevil
    Commented Sep 11, 2018 at 8:56
  • Do users create reports on their own or they access pre-created reports?
    – Pranay Jaiswal
    Commented Sep 11, 2018 at 8:58
  • they can create own reports since they are all case workers
    – RedDevil
    Commented Sep 11, 2018 at 9:11
  • I am marking this as answer since this is the closest of all, looks to me that there is no escape for us from apex sharing. we will create groups to save ourself from individual sharing records.
    – RedDevil
    Commented Sep 12, 2018 at 15:33
1

For Custom Object Teams solution is following :

  1. You create custom object [CaseTeamMember] with at least two fields: master-details to your custom case object and Lookup for the user.

  2. Then you will need to create an auto-lunched flow with two input variables ObjectId and UserId. On that flow drag&drop record create element, select [YouCustomCase__Share] as object and fill in ParentId and UserOrGroupId fields with variables you have created.

  3. Set this element as start element of the flow. Close flow designer and activate your flow.

  4. Now you can user this flow in processbuilder and as soon as [CaseTeamMember] is created you can call a flow and create sharing records.

Unfortunately you will still need apex trigger to handle delete of [CaseTeamMember]. Or you can delete sharing records directly, but it requires a bit more manual works.

Hope it will help you.

Improve this answer
0

The use case is tricky here.

Queues are used when queue members will work on the case. Either all the queue members will get the access to the record or none of them.

In your situation, if restriction should be provided for trial user. So, there will be 2 approaches.

1st Approach

Create 2 queues, one is including that trial user and other will be excluding that user. Define a criteria based sharing rule to assign the record to the respective queues.

There is a Recalculate button exists on the Sharing Rules related list and clicking on that, all the rules will be re-evaluated.

2nd Approach

If you don't want to define 2 queues then remove the user from queue. Create a criteria based sharing rule and provide Read/Write access for those records which the user needs.

Sharing rule doesn't provide access to queue. It gives to Role, Roles & internal subordinates, Public Groups (not thinking here about Portal users).

Then create queue with roles or public groups which has been defined in the sharing rule. So, queue members will automatically get access.

And Recalculate the rules.

It is recommended to perform this operation at off working hours and this should be tested in full copy sandbox.

Improve this answer
4
  • For Approach 1. There can be 1000 user in 1 queue. Everytime a new user from queue becomes case going user then create a new Queue with 999 members and exclude the case going member? This would end up creating 1000 * 1000 queues assuming all those 1000 members would be case going user in one of the cases. Looks too tough For Approach 2 : Criteria based sharing rule only applies on Groups and Roles, Any idea how can we share those with specific users who are part of the queue(excluding case going member)?
    – Pranay Jaiswal
    Commented Sep 11, 2018 at 14:59
  • For Approach1: Everytime, if user is excluded we should not create a new queue, rather try to utilize existing queue, so it might have max 2 to 3 queues. Ideally 2 queues, one for All members and second one will be rest of members excluding trial one. For Approach 2: Queues can be created based on public groups or Role hierarchy. If we share records to the group then queue members who is part of queue automatically get access. Hope it clarifies!
    – Santanu Boral
    Commented Sep 11, 2018 at 17:00
  • Approach 1: Suppose there is 1 queue of 1000 memebers, and out of that 5 users are court going members, Then each case going member should have to access to all cases in queue except the one they are going to court. So can it be solved by 2 queue approach? Approach 2: If someone is court going user how is his access removed?? Hes still part of the group right.
    – Pranay Jaiswal
    Commented Sep 11, 2018 at 17:16
  • For Approach1: How many queues to be defined based on use case or OP's requirement. Ideally, queue members should work on the case, here design has not done properly. This can be easily be done through sharing, if someone needs to access the record. Approach 2: Click Recalculate button after removing user, all the rules will be revalidated and trail user will loose access. Trail user will not part of that group where record access is restricted. You can do a small POC on this. It should work.
    – Santanu Boral
    Commented Sep 11, 2018 at 17:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .