List Views in Salesforce

This is Part 13 of the Salesforce series. In the previous post, we covered Quick Actions, Buttons, and Links. Today we turn our attention to one of the most heavily used features in any Salesforce org: List Views.

List views are deceptively simple. Every user interacts with them daily, yet most admins underestimate how much thought should go into governing them. In this post we will cover everything from the basics of creating a list view to the nuanced governance decisions that separate a clean org from a cluttered one.

What Are List Views?

A list view is a filtered, column-configured view of records for a particular object. When you navigate to the Accounts tab, the grid of records you see is a list view. Every standard and custom object that has a tab automatically supports list views.

Types of List Views

Anatomy of a List View

Every list view consists of three components:

1. Filters — the criteria that determine which records appear.
2. Columns — the fields displayed in the grid.
3. Sharing settings — who can see the list view (private, specific groups, or all users).

How to Create a List View

Step-by-Step

1. Navigate to the object tab (e.g., Accounts).
2. Click the gear icon next to the list view name and select New.
3. Enter a List Name. The API name auto-populates.
4. Choose the visibility:
   • Only I can see this list view — private.
   • All users can see this list view — public to the entire org.
   • Share list view with groups of users — lets you pick specific public groups, roles, roles and subordinates, or territories.
5. Click Save.
6. Click Add Filter to define your criteria.
7. Use the Fields button (columns icon) to select which columns display.

Filter Logic and Complex Filters

Basic filters use AND logic by default — every condition must be true. For more nuanced queries, click Add Filter Logic to write custom Boolean expressions.

Example: Show all Accounts where Industry is “Technology” OR Industry is “Healthcare” AND Annual Revenue is greater than $1,000,000.

Filter 1: Industry equals Technology
Filter 2: Industry equals Healthcare
Filter 3: Annual Revenue greater than 1000000
Filter Logic: (1 OR 2) AND 3

Supported filter operators include:

Important: Filter logic supports AND, OR, and NOT, along with parenthetical grouping up to a depth of three levels. You can add up to 10 filter conditions on a single list view in Lightning Experience.

List View Charts

One of the most underused features in Lightning Experience is List View Charts. These let you visualize the data in your current list view without building a report or dashboard.

How to Use List View Charts

1. Open any list view.
2. Click the Charts icon (bar chart) in the top-right corner of the list view.
3. Click the gear icon inside the chart panel and select New Chart.
4. Choose the chart type: Bar, Donut, or Funnel.
5. Select the Aggregate Type (Count, Sum, Average) and the field to aggregate.
6. Select the Grouping Field.
7. Click Save.

Practical Uses

• Opportunity list view grouped by Stage with Sum of Amount — a quick pipeline snapshot.
• Case list view grouped by Priority with Count — instant case distribution.
• Lead list view grouped by Lead Source with Count — channel performance at a glance.

Charts update in real time as you switch between list views or change filters.

Inline Editing from List Views

Lightning Experience supports inline editing directly from the list view grid. This is a powerful productivity feature that lets users update records without opening each one individually.

How It Works

1. Double-click a cell in the list view.
2. Edit the value.
3. Press Tab to move to the next cell or Enter to save.
4. A blue indicator appears on all changed cells.
5. Click Save to commit all changes at once, or Cancel to discard them.

What You Can Inline Edit

• Text fields, number fields, currency, percent, date, email, phone, URL
• Picklist and multi-select picklist fields
• Lookup fields
• Checkbox fields

What You Cannot Inline Edit

• Formula fields (they are read-only)
• Auto-number fields
• Fields on records you do not have edit access to
• Fields controlled by validation rules will validate on save
• Encrypted fields

Tip: Inline editing respects field-level security. If a user has read-only access to a field, the cell will not be editable even though other cells in the same row might be.

Mass Actions from List Views

List views are a primary interface for bulk operations in Salesforce. Users can select multiple records using the checkboxes and perform actions on all of them at once.

Available Mass Actions

Mass Action Limits

• You can select up to 200 records at a time for mass actions in Lightning Experience.
• The “Select All” checkbox selects all records on the current page. If your list view returns more than 200 records, you will need to perform the action in batches.
• Some mass actions trigger automation (flows, triggers, workflow rules) on each record individually, so be mindful of governor limits when performing bulk operations.

How to Grant Users Access to Create List Views

Not every user should create list views (we will discuss why shortly), but if you do want to grant this ability, here is how.

The Required Permission

The ability to create and manage list views is controlled by the following user permissions:

These permissions are assigned through Profiles or Permission Sets.

Step-by-Step: Granting the Permission via Permission Set

1. Navigate to Setup > Permission Sets.
2. Click New or select an existing permission set.
3. Click App Permissions (or System Permissions, depending on your org).
4. Enable Create and Customize List Views.
5. Optionally enable Manage Public List Views if the user should be able to share views with others.
6. Click Save.
7. Assign the permission set to the appropriate users.

Granting via Profile

1. Navigate to Setup > Profiles.
2. Select the relevant profile.
3. Scroll to General User Permissions (or use the Enhanced Profile User Interface to search).
4. Check Create and Customize List Views.
5. Click Save.

Best Practice: Use permission sets rather than profiles for this. It gives you finer control over who gets the ability without modifying an entire profile that may be shared by hundreds of users.

How to Create List View Buttons

You can add custom buttons to the list view button bar so that users can trigger custom actions on selected records.

Creating a Custom List View Button

1. Navigate to Setup > Object Manager.
2. Select the object (e.g., Account).
3. Click Buttons, Links, and Actions.
4. Click New Button or Link.
5. Set the Display Type to List Button.
6. Choose the behavior:
   • Display Checkboxes (for Multi-Record Selection) — requires users to select records first.
   • No Checkboxes — the button acts on the entire list or navigates somewhere.
7. Choose the Content Source:
   • URL — redirect to a custom URL or Visualforce page.
   • Visualforce Page — render a Visualforce page that can process the selected record IDs.
8. Write your button logic.
9. Click Save.

Adding the Button to the List View Layout

After creating the button, you need to add it to the object’s Search Layout (for Lightning Experience) or List View Layout:

1. Go to Setup > Object Manager > [Object] > Search Layouts for Salesforce Classic.
2. Click Edit next to List View.
3. Move your custom button from Available Buttons to Selected Buttons.
4. Click Save.

In Lightning Experience, custom list buttons must use a Visualforce page or a URL. Lightning Web Components and Aura components cannot be directly used as list buttons without wrapping them in a Visualforce page or using a different approach such as a Quick Action.

Example: A “Mass Update Region” List View Button

Suppose you want a button that lets users select multiple Accounts and update their Region field in bulk. You would:

1. Create a Visualforce page that accepts the selected record IDs via the GETRECORDIDS function.
2. The page processes the IDs, presents a form for the new Region value, and performs a DML update.
3. Create a List Button on the Account object pointing to that Visualforce page with checkboxes enabled.
4. Add it to the Account search layout.

List View Sharing: Public vs. Private

Understanding list view visibility is critical for keeping things organized.

Private List Views

• Visible only to the creator.
• Cannot be seen, edited, or deleted by other users (including admins in most cases).
• Useful for personal productivity — a user might create a view for “My Open Tasks This Week.”

Public List Views

• Visible to all users or to specific groups/roles.
• Can be created only by users with the Manage Public List Views permission.
• Appear in every qualifying user’s list view dropdown.

Sharing Options

When creating or editing a list view, you can share it with:

Who Owns a List View?

List views have a Created By user but do not have a traditional “owner” field like records do. If the creator is deactivated, the list view persists. Public list views remain accessible. Private list views created by a deactivated user become orphaned — they still exist in the system but no one can see or manage them.

List View Limitations

List views are powerful but come with a set of constraints you should be aware of.

Technical Limitations

Behavioral Quirks

• Column widths do not persist across sessions for all users. Users may need to re-adjust them.
• Sort order is per-user and does not persist when sharing a public list view. Each user sees their own sort preference.
• Pinned list views are user-specific. You cannot pin a default view for all users on an object (though you can set a default via the Lightning App Builder or a custom solution).
• Filter by Owner uses a special “My [Object]” scope that filters by the current user. This is not a regular filter — it is a separate scope selector at the top of the filter panel.

Why You Might Not Want Users to Create List Views

This is one of the most important governance conversations an admin will have. Here is why unrestricted list view creation can become a problem.

List View Sprawl

When every user can create public list views, the dropdown menu becomes unusable. Imagine an Opportunity object with 150 public list views, most of which are variations of the same filters created by different reps. Users cannot find the views they need, so they create yet another one — compounding the problem.

Naming Chaos

Users tend to name list views things like “My Stuff,” “Test 123,” “John’s Opps,” or “DELETE ME.” Without a naming convention, the list view dropdown becomes a wall of meaningless labels.

Maintenance Burden

Every public list view is something the admin team must eventually audit, clean up, or explain to confused users. List views created by former employees persist indefinitely unless someone manually removes them.

Performance Concerns

While individual list views are generally performant, certain filter combinations on large objects can cause slow queries. A user who creates a list view with complex filters on an object with millions of records may experience slow load times — and if that view is public, every user who lands on it shares that experience.

Security Considerations

Public list views expose filtered views of data based on the creator’s intent, not necessarily the viewer’s access level. While field-level security and sharing rules still apply (users will not see data they should not), a list view can surface records or field combinations that were not intended for a broad audience. For example, a list view titled “High-Value Deals Over $1M” shared with all users might reveal sensitive pipeline information to roles that should not be reviewing it.

Recommended Approach

Why You Might See List Views You Did Not Create

Users sometimes notice list views they never created appearing in their dropdown. This happens for several reasons.

System-Generated Views

Salesforce automatically creates certain list views when features are enabled. For example:

• “Recently Viewed” — always present on every object with a tab.
• “All [Object]” — a default view showing all records the user has access to.
• “My [Object]” — filters to records owned by the current user.
• Intelligence Views — if Einstein Activity Capture or Sales Cloud Einstein features are enabled, views like “Important Opportunities” or “Overdue Tasks” may appear automatically.

Package-Installed Views

When you install a managed or unmanaged package from the AppExchange, it can include list views as part of its metadata. These appear alongside your org’s custom views and are often named according to the package developer’s conventions.

Admin-Created Public Views

If an admin or another user with the “Manage Public List Views” permission creates a public view, it becomes visible to all users (or to the groups it was shared with). Users may see new views appear without any action on their part.

Deployed Views

List views can be deployed via Change Sets, Metadata API, Salesforce CLI (sf/sfdx), or tools like Copado and Gearset. A deployment from a sandbox to production can introduce new list views that users were not expecting.

How to Investigate

To find out where a list view came from:

1. Navigate to the list view and look at the Created By field in the list view details (click the gear icon and select Sharing Settings or Edit List Filters to see metadata).
2. Query the ListView object via the Developer Console or Workbench:

SELECT Id, Name, DeveloperName, CreatedBy.Name, CreatedDate, SobjectType
FROM ListView
WHERE SobjectType = 'Account'
ORDER BY CreatedDate DESC

3. Check recently installed packages for bundled list views.

Best Practices for List View Governance

Establish Ownership

Assign a team or individual as the owner of the “official” list view library for each major object. This person is responsible for creating, maintaining, and cleaning up public views.

Use a Naming Convention

A consistent naming convention helps users find the right view quickly and makes audits easier.

Recommended format: [Team/Function] - [Description]

Examples:

• “Sales - Open Pipeline This Quarter”
• “Support - Unresolved P1 Cases”
• “Marketing - Leads from Webinar”
• “All - Accounts Missing Industry”

Audit Regularly

Run a quarterly query against the ListView metadata to identify:

• Views created by deactivated users.
• Views with generic or unhelpful names.
• Duplicate views with similar filter criteria.
• Views that have not been accessed recently (note: Salesforce does not track list view access out of the box, so this requires a custom solution or third-party tool).

Educate Users

Include list view guidance in your onboarding materials:

• Teach users how to create private views for personal use.
• Point them to the official public views rather than creating their own.
• Explain why list view hygiene matters.

Leverage List View as a Training Tool

List views are an excellent way to train new users on data navigation. Create well-named, well-filtered views for each role and explain them during onboarding. Users who find useful views waiting for them are less likely to create redundant ones.

Performance Considerations

Query Efficiency

Every list view generates a SOQL query behind the scenes. While Salesforce optimizes these queries, certain patterns can cause slow performance:

• Large objects without selective filters — A list view on an object with millions of records that uses a non-indexed filter field will be slow.
• “All Records” scope on large objects — Avoid list views that attempt to show every record in the org on high-volume objects. Scope to “My Records” or add a filter that limits the result set.
• Complex filter logic — Deeply nested OR/AND combinations take longer to evaluate.

Indexing

Salesforce automatically indexes certain fields (Id, Name, OwnerId, CreatedDate, SystemModstamp, RecordTypeId, and custom fields marked as External ID or Unique). Filters on indexed fields perform significantly better than filters on non-indexed fields.

If you notice a list view loading slowly, check whether its primary filter fields are indexed. If not, consider requesting a custom index from Salesforce Support for heavily filtered fields.

Best Practices for Performance

Section Notes

• List views are one of the first things users interact with when they log in. Getting them right has an outsized impact on user satisfaction.
• The governance question — whether to let users create their own views — does not have a universal answer. It depends on your org size, user sophistication, and willingness to maintain the views. A 20-person org can afford more freedom than a 2,000-person org.
• If you are migrating from Salesforce Classic to Lightning Experience, note that Classic “enhanced list views” and Lightning list views have different capabilities. Some Classic list view features (like inline mass updates from Classic) work differently in Lightning. Test your existing views after migration.
• List views cannot replace reports for complex analysis. If users need cross-object filters, summary formulas, matrix groupings, or scheduled snapshots, they should use reports and dashboards instead.
• Consider combining list views with Kanban view in Lightning Experience for visual pipeline management. The Kanban view is just another rendering of a list view’s data, grouped by a picklist field.

That wraps up our deep dive into List Views. They may seem straightforward, but as we have seen, the decisions around who can create them, how they are shared, and how they are governed have a real impact on org usability and performance.

In the next post, Part 14, we will explore Paths in Salesforce — a feature that gives users a visual guide through the stages of a business process, right on the record page. See you there.