Treat Picklist changes to Global Value Sets as Deletions and Re-Creations

[G]

Is your proposal related to a problem?

Deploying picklists that change to Global is time consuming because you have to manually delete and recreate them. automating part of the process would be great.

Describe a solution you propose

If the difference between HEAD and HEAD~1 has a picklist type change, detect it and add it to both package and destructive changes

Describe alternatives you've considered

Do it all manually

Additional context

#N/A

[Sebastien]

Hi @Windyo !

Thanks for raising this feature request and thanks for contributing in making this project better!

I want to know more.
What is a "picklist type change" ?
How to detect this situation ? => What would be the diff from git ?
Can you provide a file content example please ?

[G]

Hey!

In Salesforce, picklists can either be "local" to an Object, or "Global", meaning using a Global Picklist Set to define which values are available.
A "local" picklist can be promoted to Global via the UI.
However, using the MDAPI, a picklist that is local cannot be changed to global (nor can a picklist that uses a Global Value Set change which global value set it uses).
As such, if you are in a dev env, have a data model containing picklists, and change one to global, you can't really deploy easily to another environment.

A picklist that uses a Global value set contains the xml tag <valueSetName></valueSetName>
A piciklist that uses a Local value set will instead contain the xml tag <valueSetDefinition></valueSetDefinition>

So for any commit where changes contain a field of type picklist, check if diff between HEAD and HEAD~1 contains changes from valuesetdefinition to valueset, and if yes, do a destructive change in pre, and then push field as new.

[Sebastien]

Ok I see it know, thanks for the explanation @Windyo

When converting picklist values to global value set it changes the xml element inside the picklist metadata.
valueSetDefinition becomes valuseSetName .

Retrieving the metadata after having converted the picklist value into a global value set will retrieve 2 things

• The new global value set metadata
• The picklist values definition with valueSetName xml element

To deploy that, we need to:

1. backup data from the picklist field
2. delete the previous picklist
3. deploy the global value set and the new picklist values definition
4. restore picklist data

Currently you are dealing with this process manually right ?
With a pre deploy manual action to apply step 1 and 2
And a post deploy manual action to apply step 4

[G]

no issue @scolladon :) thanks for the answers.

minor edit:

To deploy that, we need to:

backup data from the picklist field
delete the previous picklist

and all associated metadata like LEX pages, Flows, etc

deploy the global value set and the new picklist values definition
restore picklist data

For the rest you are 100%s correct.
The process is currently, in a pipeline:

• sfdmu sf > CSV
• pause step, wherein I find the picklsits, delete them and associated medtadata
• deploy
• sfdmu CSV > sf

I don't think that sgd should care about the data transfer, nor should it find all related metadata (that IMO should be something in the sf utility), but if sgd could in fact identify the picklists and generate the destructive changes as needed, while outputting a warning, that'd be awesome.

[Sebastien]

Hi @Windyo

We discussed about that idea and we prefer not to implement it in SGD.

Here is what we have considered:

• We think the best way to deal with that is to use the conversion button in the Custom Field setup.
  • It does not require data recovery (which can be hard for some implementation because of tooling to do it and automation to disable).
  • It is catchable when the conversion is not applied before deployment. Meaning it does not arm the target environment data or metadata to forget about doing this manual action.
  • It can be automated with an other plugin. It is idempotent and can be included inside CI/CD pipeline
• Proposed solution is tightly coupled to a specific process and metadata change detection
  • We don't want to force/constrain the users to have a specific process, we prefer them to be free to use the plugin how they want.
  • It may lead to unexpected behavior for some pipeline if they are not aware sgd works that way now
  • It is not something done very often

Thank you for this idea, sorry for not implementing it, we really think it is best to deal with that using either a premanual action per environment or to automate it using another plugin or equivalent (puppeteer or else).

[G]

No issue, I just read the other plugin, it looks perfect.
Thanks for widening my toolkit and thanks for sgd :)