Gearset is always trying to find ways to make users’ data deployments more likely to succeed first time round. Recently, we’ve seen the Salesforce error INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST causing a number of deployments to fail. In this blog post, we’ll look at why picklist errors occur and how they can be solved.
What causes picklist errors in data deployments?
The same INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST Salesforce error can be caused in a few different ways, making it a trickier error to fix 😞
Usually, the INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST error is down to one of these cases:
1. The picklist field on the target uses a restricted value set that doesn’t include the picklist value being deployed
Suppose we have a custom object Student with a picklist field Supervisor. Supervisor is a restricted picklist (i.e. under picklist options, “Restrict picklist to the values defined in the value set” is checked).
In the source org, Supervisor contains four values: { Grace, Alan, Katherine, Edsger }. In the target org, Supervisor contains three values: { Grace, Alan, Katherine }. This mismatch may happen if you’re making changes in your source but you haven’t done a metadata deployment yet.
| Source | Target |
|---|---|
 |  |
If you create a record in your source, Student_1, you might set its Supervisor field to Edsger. If you then try to do a data deployment, Student_1 will cause an error because Edsger isn’t in the picklist field on the target, and that field is restricted.
This error can happen with both locally defined and global picklist value sets.
2. The record type on the target doesn’t allow the picklist value being deployed
Objects have RecordType metadata that dictate which picklist values are allowed for each picklist field on records of that type. For example, suppose Student has the record type UndergradRecordType.
In the source, UndergradRecordType allows the values { Grace, Alan, Katherine } for the Supervisor field. In the target, UndergradRecordType allows the values { Grace, Alan }.
(Note that the scenario is the same as in the first case, i.e. Grace, Alan, and Katherine are active picklist values for Supervisor in both orgs. It’s the record type that won’t allow certain values.)
| Source | Target |
|---|---|
 |  |
If you create a record in your source, Student_2, which is of UndergradRecordType, you’ll be able to set the Supervisor field to Katherine. But if you then try to run a data deployment, the Student_2 record will cause an error since Katherine isn’t an allowed value on UndergradRecordType in the target.
This can also happen when record types set a default value that isn’t allowed, for example, if UndergradRecordType by default sets Supervisor to Katherine.
3. Record types weren’t deployed so the deployment uses the default record type, which doesn’t allow the picklist value being deployed as in (2)
Let’s say UndergradRecordType is the default record type for Student. Say we also have the record type PostgradRecordType. Here’s a comparison of the values they allow on the Supervisor field:
| Record Type | Source | Target |
|---|---|---|
UndergradRecordType | { Grace, Alan, Katherine } | { Grace, Alan } |
PostgradRecordType | { Katherine } | { Katherine } |
In the previous example, Student_2 was of record type UndergradRecordType. In the source, say we now change Student_2 to be of PostgradRecordType. We set the Supervisor field to be Katherine, which is now an available value on this record type.
Now we try to do a data deployment. If record types aren’t included in the data deployment, Gearset can’t tell Salesforce which record type to use. Salesforce instead uses the default (UndergradRecordType), which then results in the INVALID_OR_NULL_RESTRICTED_PICKLIST error since Katherine is not allowed.
Solutions to picklist errors
Gearset excludes records with invalid picklist values where possible
Gearset data deployments will now automatically remove records causing INVALID_OR_NULL_RESTRICTED_PICKLIST errors of the first type. You don’t have to do anything; hopefully you’ll just notice fewer errors 😄
Manually exclude the record from the deployment
If you know which record is causing the issue, you can exclude it from the deployment by using the record filters at the start of the deployment. (There’s more information about excluding records here.)
For example, you can filter for records where Supervisor does not equal Edsger, so that only those records are deployed.
Fix the problem without excluding records
In both the first and second case, you usually just need to run a metadata deployment of the object before the data deployment. Changes in values on picklist fields or in the allowed values on record types will show up in the metadata comparison.
And finally, for the third case, you just need to include record types in the data deployment 😄
Simple data deployments for picklists
If you’re not using data deployments yet, you can try it for yourself on a free 30-day trial with nothing to install in your orgs. You can also book a demo with one of our DevOps experts to see a guided walkthrough of Gearset’s data deployment solution.
