Generating List View

## 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

# Salesforce List View Metadata Knowledge

## 📋 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/<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

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:
- 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