All Collections
Gearset for data sandbox seeding
Troubleshooting
Resolving data deployment errors: INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST
Resolving data deployment errors: INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST

This article explains when and why the INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST error occurs, and how to fix it

David Runciman avatar
Written by David Runciman
Updated over a week ago

An INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST error can occur during a data deployment if the metadata of your source org doesn’t match the metadata of your target org, or if you have invalid picklist values in your source that were added via the API.

What causes the error?

This error occurs if a record in your source org includes a value from a restricted picklist and the same picklist value does not exist in your target org. Restricted picklists constrain the picklist values that can be selected to those in the value set. This is in contrast to unrestricted (or 'advisory') picklists, which accept any value as valid that is entered or selected by the user. Whether a picklist is restricted is determined by the restrictedPicklist field and can be set with a checkbox from the Salesforce UI. 

Lists of values for restricted picklists are enforced by the Salesforce API, which means that the source record cannot be deployed if the specified picklist value isn’t available in the target org. Records containing an invalid picklist value cause Salesforce to throw the INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST error that Gearset displays as follows:

How do I fix the error?

The main way of avoiding this error is to make sure that your source and target orgs contain the same metadata with identical picklist values available in each org. You could do this manually by logging into your source org and checking what picklist values are available before logging into your target org and checking that the same values exist there too. Alternatively, you can run a quick metadata comparison between your orgs in Gearset and deploy the picklist if there are any differences. You can then deploy your data with Gearset’s data loader. Of course, you also always have the option of simply filtering and excluding the record(s) that give rise to the error.

What if my picklist metadata shows No difference between my source and target?

You may notice when running a Gearset comparison that your picklist values are the same in your source and target. However, you can still receive this error even if this is the case, if some of your picklist values were added before you made the picklist restricted.

For example, if you initially had a non-restricted picklist with values defined as One, Two, Three, and you then added a record with picklist value Un via the API. This would automatically add this new Un value to your picklist metadata, as an inactive value.

If you then made the picklist restricted, this record with the invalid value would still exist in the source. Salesforce would also not stop you if you then deployed the metadata picklist changes to your target org, or refreshed your sandbox. Because of this, the metadata between your two orgs could look identical, but if you then tried to deploy the record with the invalid value, you would hit the same error.

To fix this, you would need to either:

  • Add the invalid value to the restricted picklist value set in the target

  • Change the value in the source to a value included in the restricted value set in the target

  • Exclude this record from your deployment

This error can also occur when there is a dependent picklist but the record in your source org does not respect it. For example, if you have a field dependency that determines that the value of Field B depends on Field A, but the record in your source has a value for Field B and no value for Field A, this error may come up. This can happen if the record was created a long time ago, before the field dependency was set up.

Similar to the above, to fix this you would need to either:

  • Change the value in the source to a value that respects the field dependency in the target

  • Exclude this record from your deployment

Did this answer your question?