Dynamic Data Visibility

What do you do when the “normal” ways of doing things just don’t seem to cut it?

On a recent project, we were presented with a fairly unique requirement. At least we thought it was a unique requirement. For some background, the client is a retail business with many locations. Data (accounts, orders, etc.) from all locations are stored in the same org.

The basic requirements were:

• Customer data should only be visible to the location where the customer does business.
• Users can have access to one or more locations (e.g. Sally works at Location 1, and James works at Locations 2 and 3 while Sam works at Locations 1 and 4, and so on).
• Users should be able to filter dashboards, related lists and reports by specific locations (e.g. show me all the leads from Location 1 only, or show me the Sales Dashboard for Location 2 only).

Sharing Model

The first decision was determining the sharing model. We decided to go with Apex sharing using Groups. Each location had an associated group. The Org Wide default was set to Private for most objects, and we set the owner of the object to a common, generic user. Each object had a field on it that represented the location and we used a Record Triggered Flow to share the record with the associated location specific group.

With this process, each record is manually shared with the location specific group. So now, just add the appropriate user(s) to each group and voila, each user can see the accounts they should see.

Multi Location Users – Uh Oh

This model works fine for users that only work at one location. And it even handles most of the requirements for users that work at (or support) multiple locations.

But, the last requirement above (list views, reports, dashboards) gets tricky. Chances are, if you’re reading this, you know that the most logical option is to create filtered reports, or filtered list views.

e.g. Location 1 Leads, Location 2 Leads, etc.

The, let the user choose the appropriate List View. But, that can get difficult when the system starts to scale – say, supporting 200+ locations, and some users need access to 10 locations, and other users need access to a different 5 locations, and so on.

Do we really want to create all these filtered list views and reports? And then manage the visibility of each so people only see the filters that apply to them?

We wanted to leverage the “All Leads” list view and only show a specific location at a time.

Enter Dynamic Data Visibility

Wouldn’t it be great if a user could choose the group they are in? And then change it dynamically based on the specific location they are supporting? But we can’t give everyone Admin access.

Can we do that? Can we build a user interface that allows the user to choose the location(s) they want to see, then change it back at any time.

So, we created a custom field in the user object called “Visible Locations.” This was a multi-select pick list where the admin can decide what location(s) the user has visibility.

Then we created a screen flow that runs with System access that lets the user choose location(s) from their list of chosen visible locations.

Once selected, the flow removed the user from All Groups, then adds them back the ones that they specifically chose.

With this design, users can now dynamically choose which group memberships they have and thus are dynamically changing their data visibility.

Choose Location 1, go to “All Leads” and you only see Location 1’s Leads. Or, you can choose Location 1 and Location 2, go to the Sales Dashboard, and you see sales for both locations. Wanna sees sales for only Location 1, change your selection to only be Location 1, and ta-da, you only see Location 1 sales.

We’d love to hear your thoughts and feedback on this design. What potential pitfalls are there? What are other ways to meet these requirements?