When to Use This Skill
Use this skill when you need to:
- Create list views for objects
- Generate filtered, column-based record listings
- Configure list view visibility and sharing
- Troubleshoot deployment errors related to List Views
Specification
📋 Overview
Salesforce List Views define filtered, column-based record listings on an object's tab.
🎯 Purpose
- Provide curated, role- or task-specific subsets of records
- Standardize commonly used filters and visible fields across teams
🔧 Configuration
Unless specifically requested to be generated inline, List Views are stored at:
- force-app/main/default/objects//listViews/.listView-meta.xml
Only if the user requests are they to be included in the object's metadata file:
- fore-app/main/default/objects//.object-meta.xml
Key elements:
- label: Human-friendly name shown in UI (must be under 40 characters in length)
- fullName (fullName): API identifier used in metadata and file name
- filterScope: Everything | Mine | Queue
- filters: field/operation/value triples
- booleanFilterLogic: Combine multiple filters logically with AND/OR (e.g., "1 AND (2 OR 3)")
- columns: Ordered list of field API names to display
References:
- listViews appear on the entity's tab
- listViews can be referenced by flexipages using the "filterListCard" component
Critical Decision: Visibility Strategy
Choose how broadly the view should appear in the org.
Choose "Visible to all users" when:
- The view is useful across profiles/roles
- It's a governed, shared artifact to be managed via source control
- Data contained is appropriate for broad visibility
Choose "Owner-only/Restricted" when:
- It is experimental or niche during iteration
- It is specifically requested to be limited to Users, Groups or Roles
- There are governance/security reviews pending
When in doubt: Default to "Visible to all users".
Critical Decision: Columns Density
Choose minimal, high-signal columns when:
- Users need at-a-glance scanning
- Mobile/responsive performance matters
Choose richer column sets when:
- Desktop heavy workflows need more context without opening records
- It serves as a work queue and extra fields reduce clicks
When in doubt: Start with 4–6 columns that directly support the primary task.
Critical Rules (Read First)
Rule 1: Custom Field API Names
For custom fields, use exact API names (e.g., Status__c), not labels.
Wrong:
Right:
Rule 2: Standard Field Names
For standard fields on Custom Objects, use already defined names:
Wrong:
Right:
The standard fields on Custom Objects are:
- NAME
- RECORDTYPE
- OWNER.ALIAS
- OWNER.FIRST_NAME
- OWNER.LAST_NAME
- CREATEDBY_USER.ALIAS
- CREATEDBY_USER
- CREATED_DATE
- UPDATEDBY_USER.ALIAS
- UPDATEDBY_USER
- LAST_UPDATE
- LAST_ACTIVITY
Rule 3: Operations Must Match Field Types
Picklists require equals/notEqual; date fields require date operators; boolean values are 0 and 1; do not mix text-only operators with non-text fields.
Wrong:
- operation="contains" on a picklist
- value=True on a boolean
Right:
- operation="equals" with a valid picklist value
- value=1 on a boolean
Rule 4: Name and Path Alignment
File name, fullName (also sometimes referred to as DeveloperName), and uniqueness must align.
Wrong:
- File: My_List.listView-meta.xml
- fullName: MyList
Right:
- File: MyList.listView-meta.xml
- fullName: MyList
Rule 5: Folder Placement
Place files under the object's listViews directory or deployments will fail to resolve components. Only if a user
requests it, may the listView may be included inline in force-app/main/default/objects//.object-meta.xml
Path:
- force-app/main/default/objects//listViews/.listView-meta.xml
Generation Workflow
- Identify the target object API name (e.g., Object__c).
- Gather business requirements: purpose, audience, fields, filters.
- Validate values and operator compatibility with field types.
Step 2: Examine Existing Examples
- Repo: force-app/main/default/objects//listViews/ (unless otherwise required by end user)
- Org: retrieve existing list views for proven patterns (filters, logic, columns).
- Note what passed review/deployment and delivered expected UX.
Step 3: Create Specification
Document before implementation:
- Name: fullName and Label
- Audience: Visibility scope ("all users" vs. shared)
- Filter scope: Everything | Mine | Queue
- Filter items: filter, operator, value; plus booleanFilterLogic if multiple
- Columns: Ordered list of field API names
- Acceptance criteria: Which records appear, paging behavior, key scenarios
Use a Lightning-compatible template and ensure valid XML:
Notes:
- For "My" views, use filterScope="Mine".
- Keep columns tight and purposeful.
- If intended for all users, omit the "sharedTo" section.
Step 5: Validate Locally
- Well-formed XML; correct namespace
- Field names exist on the object; operators and values match field types
- Path and fullName alignment
- If multiple filters: set booleanFilterLogic correctly (e.g., "1 AND (2 OR 3)")
Step 6: Deploy and Verify in Org
- Deploy the component path or the whole object.
- In the UI, open the object tab and:
- Confirm records match filters
- Confirm columns render correctly
- Confirm visibility matches audience
Common Deployment Errors
| Error | Cause | Fix |
|---|
| "Invalid field Status" | Used label instead of API name, or used API Name instead of defined name for Standard Field | Use Status__c (or correct API name), or NAME instead of Name (for Standard Fields) |
| "Invalid filter operator" | Operator not valid for field type | Choose operation compatible with field type (e.g., equals for picklist) |
| "Component not found at path" | Wrong folder or file name | Place in objects//listViews and align file name with fullName |
| "Malformed booleanFilterLogic" | Syntax or index mismatch | Use "1 AND 2" style, ensure filters index order matches |
Verification Checklist