description: "Use this skill when users need to create, generate, or validate Salesforce List View metadata. Trigger when users mention list views, filtered record lists, creating views, setting up record columns, filtering records by criteria, or ask about list view visibility. Also use when users say things like \"I need a view that shows...\", \"filter records by...\", \"create a list view for...\", or when they're working with ListView XML files and need validation or troubleshooting."
- 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:
- Status (label)
Right:
- Status__c (API name)
### Rule 2: Standard Field Names
For standard fields on Custom Objects, use already defined names:
Wrong:
- Name (API Name)
Right:
- NAME
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/<ObjectName>/<ObjectName>.object-meta.xml
| "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/<Object>/listViews and align file name with fullName |
| "Malformed booleanFilterLogic" | Syntax or index mismatch | Use "1 AND 2" style, ensure filters index order matches |
