When to Use This Skill

• 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

Salesforce List View Metadata Knowledge

📋 Overview

🎯 Purpose

• Provide curated, role- or task-specific subsets of records
• Standardize commonly used filters and visible fields across teams

🔧 Configuration

• force-app/main/default/objects/<ObjectName>/listViews/<fullName>.listView-meta.xml Only if the user requests are they to be included in the object's metadata file:
• fore-app/main/default/objects/<ObjectName>/<ObjectName>.object-meta.xml

• 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

• listViews appear on the entity's tab
• listViews can be referenced by flexipages using the "filterListCard" component

Critical Decision: Visibility Strategy

• 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

• 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

Critical Decision: Columns Density

• Users need at-a-glance scanning
• Mobile/responsive performance matters

• Desktop heavy workflows need more context without opening records
• It serves as a work queue and extra fields reduce clicks

Critical Rules (Read First)

Rule 1: Custom Field API Names

• Status (label)

• Status__c (API name)

Rule 2: Standard Field Names

• Name (API Name)

• NAME

• 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

• operation="contains" on a picklist
• value=True on a boolean

• operation="equals" with a valid picklist value
• value=1 on a boolean

Rule 4: Name and Path Alignment

• File: My_List.listView-meta.xml
• fullName: MyList

• File: MyList.listView-meta.xml
• fullName: MyList

Rule 5: Folder Placement

• force-app/main/default/objects/<ObjectName>/listViews/<fullName>.listView-meta.xml

Generation Workflow

Step 1: Get Metadata Information

• 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/<Object>/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

• 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

Step 4: Author Metadata File

<?xml version="1.0" encoding="UTF-8"?>
<ListView xmlns="http://soap.sforce.com/2006/04/metadata">
    <fullName>OpenMine</fullName>
    <label>Open - My Records</label>
    <filterScope>Mine</filterScope>
    <columns>NAME</columns>
    <columns>Status__c</columns>
    <columns>OWNER.ALIAS</columns>
    <columns>LAST_UPDATE</columns>
    <filters>
        <field>Status__c</field>
        <operation>equals</operation>
        <value>Open</value>
    </filters>
    <sharedTo>
        <role>CEO</role>
        <roleAndSubordinatesInternal>COO</roleAndSubordinatesInternal>
    </sharedTo>
</ListView>

• 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

Verification Checklist

• All required fields populated (fullName, label, filterScope, columns)
• Property values are XML-encoded where needed
• Custom Field references use API names (e.g., Status__c)
• Standard Field references use defined names (e.g., NAME)
• Operations match field types; picklist values are valid
• booleanFilterLogic (if used) matches filters ordering and count
• File path and fullName/developerName are aligned
• No deprecated or Classic-only properties included
• Deployed successfully and visible as intended
• Records, columns, and filtering behave as specified