How to Deploy Standard Field Picklist Values in Salesforce (2025 Update)
22 min
When working with Salesforce, picklists are essential for ensuring data consistency, guiding user input, and simplifying reporting. Standard picklist fields (those provided by Salesforce by default) often require value updates across environments (sandbox, QA, production, etc.).
In 2025, there are more refined tools and practices that allow admins and developers to deploy standard picklists reliably and securely.
This article walks through how to deploy standard field picklist values in Salesforce in 2025, what has changed, and how to avoid common pitfalls.
What Is a Standard Picklist, and What’s New in 2025
A standard picklist field is a field provided by Salesforce on a standard object (for example: Lead.Source
, Case.Status
, Opportunity.Stage
) with predefined values. While certain metadata aspects cannot be changed (such as the API name or field type), you can:
- Add new values.
- Reorder values.
- Set default values.
- Deactivate obsolete values.
What’s new in 2025:
- Greater support in Metadata API / Salesforce CLI for handling StandardValueSet, which stores values for many standard picklists.
- DevOps tools (like Gearset, Copado) display changes to StandardValueSet, GlobalValueSet, and custom picklists more clearly.
- Improved validation and dependency error messages when values are missing from record types, Flows, or validation rules.
- Stricter enforcement in production regarding default values and active dependencies.
Why Proper Deployment Matters
- Ensures consistency across environments.
- Maintains report integrity.
- Prevents deployment errors caused by missing dependencies.
- Reduces risks for dependent processes (Flows, integrations, APIs).
Step-by-Step Guide: How to Deploy Standard Picklist Values
Step 1: Identify Which Standard Picklist Fields Need Updates
- List fields such as Lead Source, Case Status, Opportunity Stage.
- Verify whether their values are stored in StandardValueSet.
- Audit current versus desired values, including inactive and default ones.
Step 2: Review Dependencies and Permissions
- Record Types: ensure new values are allowed.
- Validation Rules, Flows, Apex, Processes: check dependencies before renaming or deactivating values.
- Field Security and Page Layouts: confirm users have access.
- Global Value Sets: consider using them if multiple objects share similar picklists (when possible).
Step 3: Make Changes in the Source Org
- Add, deactivate, or reorder values.
- Use Setup UI for small changes or CLI / Metadata API for bulk changes.
- Confirm the API version being used (v65–v70 or higher).
- In
package.xml
, use the correct StandardValueSet name (example:StandardValueSet:LeadSource
).
Step 4: Retrieve and Prepare Metadata for Deployment
Example with Salesforce CLI:
sfdx force:mdapi:retrieve -m StandardValueSet:LeadSource,StandardValueSet:CaseStatus -r retrieveDir
- Include RecordTypes in the package.
- Keep in mind that Change Sets don’t always capture deletions or inactive values.
Step 5: Deploy to the Target Org
Example with CLI:
sfdx force:mdapi:deploy -d deployDir -u TargetOrgAlias
- Validate first in QA or Sandbox.
- Include dependencies (record types, layouts, rules).
- Monitor for errors related to invalid values.
Step 6: Post-Deployment Verification and Adjustments
- Confirm values in Object Manager.
- Check layouts, record types, and default values.
- Update reports and dashboards.
- Document changes (new values, inactive values, defaults).

Common Issues and Fixes
- Missing StandardValueSet metadata → verify the correct name.
- Deployment errors due to dependencies → include record types in the package.
- Inactive values still in use → review Flows, rules, and processes.
- Default value problems → ensure layouts and logic respect updated defaults.
Conclusion
Deploying standard field picklist values in Salesforce in 2025 is more reliable than ever thanks to StandardValueSet, Salesforce CLI, and DevOps tools. By following best practices and verifying dependencies, you’ll save time and reduce deployment risks.
