Sharing a List View Doesn't Share the Records

Module 6 of 6 in the chapter Public Groups and Criteria-Based Sharing Rules, chapter 7 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: A list view is the saved list of records you see when you open a tab in Salesforce. When someone shares one with a group, what have they actually shared, and who should be allowed to do it?

First, what is a list view?

Open the Cases tab in Salesforce. Before you open a single case, you see a list: “My Open Cases,” “Recently Viewed,” maybe “All Open Cases.” Each of those is a list view. It’s a saved search with a name: which records to show (the filters) and which fields to show for them (the columns).

Anyone with the right permission can make their own. “My escalations this week.” “Accounts in Texas with no activity.” And they can share it, so the rest of the team sees the same list view in their dropdown. That’s what this module is about: what sharing a list view gives people, what it doesn’t, and who should be allowed to do it.

Here’s a question for the room. I share a list view called “All open cases” with the whole service team. Can everyone on the team now see every open case?

No. They can see the list view. What’s in it depends on who’s looking.

What a list view shares

A list view is a saved filter: a name, some filters and some columns. When it runs, it runs as the person looking at it, and it shows them the records they can already see. Sharing the list view shares the filter. It doesn’t share a single record. To create a list view at all, Salesforce asks for “Read on the type of record included in the list” (Create a Custom List View in Lightning Experience (opens in a new tab), Salesforce Help, checked 2026-11-07).

So two people can open the same shared view and see different lists. The team lead sees 400 open cases. A new agent with a Private default and no rules sees the 12 they own. Same view, different file cabinets.

That’s the same idea as the group itself (module 1): a bucket grants nothing by itself. Putting someone in the group a list view is shared with gives them a filter, not access. The sharing model you built in chapters 6 to 8 still decides the records.

Click to enlarge

When you create a list view, you “Choose who can see this list view: just you, all users (including Partner and Customer Portal users), or specific groups of users.” For groups, you “select public groups or roles,” and to pick roles you need the View Roles and Role Hierarchy permission (Create a Custom List View in Lightning Experience).

Two things in that sentence to read slowly.

All users means all users. Salesforce says it in brackets: including partner and customer portal users. If a view’s name or filters say something you wouldn’t tell a partner, don’t share it with everyone.
Groups, not people. “List views can be shared with groups, roles, and territories only, not specific users” (Considerations for List Views and Related Lists (opens in a new tab), Salesforce Help, checked 2026-11-07). So a well-built public group is the Swiss Army knife again: the same group that a sharing rule targets can be the group a list view is shared with.

Three permissions

For years, sharing a list view took one broad permission, and it was all or nothing. Salesforce now lists three (Create a Custom List View in Lightning Experience):

Create and Customize List Views: “To create list views,” for yourself.
Manage Shared List Views: “To share personal list views.”
Manage Public List Views: “To create, edit, share, or delete public list views”: every public view in the org.

The middle one is new in Summer ‘26. Salesforce’s Admins blog describes the old problem: “a well-meaning user accidentally edited or deleted a critical public list view because they had the broad Manage Public List Views permission.” With Manage Shared List Views, users can share their own views “with their specific roles, groups, or territories without giving them the ‘keys to the kingdom’ to modify every public view in the org” (Jen’s Top Summer ‘26 Release Features for Admins (opens in a new tab), Salesforce Admins blog, checked 2026-11-07).

And it’s limited by the groups you’re in. “With the Manage Shared List Views user permission, a user can remove a group from the list view’s sharing settings only if they’re a member of that group.” And to delete the list view or make it private, they must be in every group it’s shared with (Considerations for List Views and Related Lists).

There’s one more switch. The blog says you can “let users edit the filters or names of list views shared with them, even if they don’t have the full management permission, by enabling the ‘Shared list view editing feature’ on the User Interface Settings page in Setup” (Jen’s Top Summer ‘26 Release Features for Admins). Decide that one on purpose: a filter someone else can edit is a list someone else can change.

Click to enlarge

The list view bleed

A list view can’t show a record you can’t see. But it can show a field you thought you’d hidden.

In my video I hide a security status field on the page with conditional visibility. Then I create a new list view, only I can see, add the security status column, and there it is: every security status for every record, even though the page layout hides it. The problem is that you have to give the user access to the field even though it’s not on the screen, and therefore they can come along, make a list view and add that field. You can’t stop them.

That’s the bleed over. You can keep it off the screen, but you can’t keep it from other mechanisms: reports, dashboards, list views and global search. And note that this one needs no sharing permission at all. A private list view, only I can see, is enough.

So a list view is a test, not a control. If a field truly must stay hidden, the user mustn’t have field-level security on it. Chapter 4 covers fields and how to show a protected value without granting it.

What an architect decides here

Who gets Manage Public List Views. Usually a few people who look after the org’s public views, not every power user.
Whether users share their own views with Manage Shared List Views instead, and whether the Shared list view editing feature is on.
Which public groups list views are shared with, and whether those are the same groups your sharing rules use.
That no view shared with all users says, in its name or filters, anything external users shouldn’t read.
Which fields mustn’t bleed: no field-level security on them for users who mustn’t see them, whatever the page layout shows.

Beyond the exam: what AI changes. A list view is a question saved with a name: “my team’s open escalations.” Agents answer questions the same way, as the user they run for, from the records that user can see. So the lesson here is the lesson for agents. Neither one grants access, and neither one hides a field the user can read. If an agent can read a field, it can put it in an answer, whatever your page layout hides. Chapter 20 covers agents.

Explore

Create a Custom List View in Lightning Experience (opens in a new tab), Salesforce Help (checked 2026-11-07)
Considerations for List Views and Related Lists (opens in a new tab), Salesforce Help (checked 2026-11-07)
Jen’s Top Summer ‘26 Release Features for Admins (opens in a new tab), Salesforce Admins blog (checked 2026-11-07): the Manage Shared List Views permission