2

I'm unable to deploy a picklist field that was promoted to a global value set to my production environment. The global value set, and the new field in another object that uses it are both OK, but when I try to deploy the original picklist field I get the following error:

Cannot change which global value set this picklist uses.

enter image description here

I've found this is the minimal case to reproduce this:

  1. Create a custom picklist field with some values in a sandbox environment.
  2. Deploy this field to your production environment in a change set.
  3. In your sandbox environment, promote the picklist field to a global value set.
  4. Deploy the global value set and the upgraded picklist field to production in a change set.
  5. Receive "Cannot change which global value set this picklist uses." error.

I've tested this case on an all-new object with no actual records, so it's clearly nothing to do with existing data.

What is the solution here? How do I get this change deployed? Deleting the field and recreating it is a non-starter because we already have many flows, classes, and object records using this field.

5
+50

There's a lot of pain here for orgs that retroactively want to convert to global picklists (since global picklists came out in beta in Summer '16). I won't be able to tell you why they exist other than that they do.

In the global value set docs, they mention this:

You can’t undo a custom picklist field’s association with a global value set. If you need a picklist field to use a different global value set, or different individual values, delete the custom picklist field and create a new one in its place.

Not to mention the frustrating limitation of:

You cannot promote a field to an existing global value set.

For your specific situation, converting an existing picklist into a new global picklist, you only have the option to manually click "promote to global picklist" in the target org and there's no way to deploy it.

That functionality is only accessible through their picklist promotion button in the org. This idea delivered that functionality and they seemed to indicate they were not planning on adding additional functionality (and this was 3 years ago).

That situation is manual, but at least provides an option for existing fields with heavy dependencies to be turned into a global picklist without losing existing data and customizations.

The problem is with orgs with history where you have 2 separate picklist fields that you want to turn into a global picklist but both are referenced in code, flows, etc in the target org. Only one has the easy way out of clicking the "promote to global picklist" whereas the other one you basically have no option unless you can remove all references to it in your code, delete the field, recreate it, etc. This idea mentions the difficulty of this functionality with regards to orgs with many picklists/history that want to convert to global picklists.

1
  • I just got this reply from SF support: "We would like to help you out as much as we can but the only option we had for now is to delete the existing one in order to deploy it successfully." - I really can't understand the (lack of) thinking behind some of these things in Salesforce, or that this kind of issue stays open for so very long without resolution. – Llama Oct 29 '20 at 0:44
1

Workaround is you need to delete the field and its associated picklist from the target org and then it allows you to deploy from source to target environment.

Kindly review Idea link and vote for this feature.

Thanks,

3
  • That's not really a workaround, since we'd lose the data that field holds. Not to mention all of the scripts and flows that reference this field that would need to be modified beforehand, and then we'd have to somehow go back in and put all the data back. It's a non-starter, I'm afraid. – Llama Oct 20 '20 at 14:05
  • Unfortunately, This is a known limitation with the global picklist. – Vinay Oct 20 '20 at 17:54
  • What's the underlying reason for not being able to deploy the result of the conversion (i.e. the now-global picklist and the global value set) to a different environment? It just seems like an arbitrary limitation. We really can't understand the logic of having sandbox environments but being unable to deploy changes from the sandbox environment to the production environment. – Llama Oct 22 '20 at 5:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.