Skip to main content

How to deploy picklist changes on Standard and Custom Fields

How do you deploy new picklist values on Standard and Custom Fields?

Mateusz Kochanowicz avatar
Written by Mateusz Kochanowicz
Updated today

Sometimes the metadata used to represent a change made in Salesforce doesn't quite line up with what the Salesforce UI would lead you to believe. An example of this is picklist values on Standard Fields - for instance, the values of the Account Source field on the Account standard object.

The Salesforce UI makes it look as if the field actually stores the value, but the reality is that the values are stored in another metadata type called a Standard Value Set.
​
And the actual field definition for Account Source is only a reference to the Standard Value Set.

Understanding the metadata types

To start with, it's important to understand the distinction between different metadata types related to picklists.

  • Custom field - this metadata contains the definition of a custom field. It includes custom field's picklist values if it's a picklist field that is not based on Global Value Set. The values are defined directly within the field's metadata.

  • Standard Value Set - this metadata type holds standard picklist values for standard fields on standard Salesforce objects (e.g. Industry field on Account object, or StageName field on Opportunity object).

  • Global Value Set - this metadata represents a reusable set of picklist values that can be shared across multiple custom picklist fields. So if your Custom field uses a Global Value Set, you'd need to retrieve Global Value Set metadata in your Gearset comparison + Custom field metadata (which is a part of Custom object).

How to find changes made in picklists (e.g. picklist values)

To find changes to your picklists, if you're unsure whether to use either Standard or Global Value set, we recommend to run a comparison that includes these 3 metadata types in your custom filter:
- Standard Value Set
- Global Value Set
- Custom object (already includes Custom field metadata)

You can then filter the comparison results, and find the changes you're interested in.

If it's picklist values you're looking for, they should be either under Standard Value Set or Global Value Set metadata type.

Note: If you believe your picklist value(s) should have been retrieved by Standard Value Set or Global Value Set for a specific picklist on an object that your Salesforce user has access to in the org, please try the retrieval via Workbench to confirm the behaviour.

If can retrieve your picklist values but Gearset can't, please reach out to us via in-app chat and ask to add support to retrieve these picklist values - we'd then speak to our engineering team and ask for this to be updated in the app.

Insufficient user permissions

A common blocker is the lack of necessary permissions for the user account performing a metadata retrieval - this is typically a Salesforce user account used to connect your org in Gearset.

To correctly access and retrieve metadata, either user's profile in Salesforce or a permission set assigned to the user must have the following permissions:

  • API Enabled - this is a fundamental permission required to use Salesforce Metadata API.

  • Modify All Data - these permissions often give access to view custom field definitions.

  • Customize Application - this permissions allows users to both access and modify custom settings, this includes custom fields and their value sets. Without this permission it's likely a Salesforce user won't be able to retrieve the definition of a custom field.

  • Object and Field-Level Security - in some specific API contexts, insufficient object or field-level security for a Custom object and a field in question can potentially prevent access to picklist values.

Note on deleting picklist values:
It's a documented limitation of the Metadata API deletions of picklist values aren't supported by Salesforce Metadata API.

Instead, the value become inactive when you deploy their deletions from the source environment.
​
This behavior is the same for Custom Fields - it's because the Metadata API treats Standard and Custom Fields as one type.

Did this answer your question?