Using Picklist API Values IRL

I recently built an integration and decided to use the new-in-2017 functionality to customize picklist API values to store the external ID for the system I was integrating into. Per developer force, doing so would “protect your picklist integrations” by allowing “ admins to change what users see when they view and select picklist values on a record, without impacting code that references these values.” And who wants to practice unsafe integration?

Using picklist API values did make things a bit easier on a number of fronts
- no conversion table needed
- ux with picklist is better for users vs using a lookup against an object

And presented one minor challenge
- no easy way to add picklist values + api values in bulk (i pulled it off by creating the filed, exporting the metadata w/ workbench, tweaking the metadata using a text editor, and deploying back via the metadata api).

And threw one major brick when it came to its use in real life
- displaying the picklist label in a flow screen that launches the integration

This is because formulas, workflow rules, and flow all use the API value when dealing with picklists - and there is no declarative way to get at the picklist label (in code there is the toLabel method that can be used in SOQL to translate the results).

For full clarity : you can use a picklist choice in a flow screen without any issues (any issues specific to using picklist API values - there are plenty of issues with use of picklist choices in flows). What you can’t do is display the current value of the picklist from an existing record in a flow as the flow will display the API value, not the label.

But then, just today, I finally thought of a stupid simply solution for this.

For the API value, add both the external ID and the label, with some unusual and unique junk phrase in between. So instead of setting api value to 123, set the api value to 123_DumpsterFire_The_Label_You_Want_To_See_In_The_World

With this approach, you can do a simple find / substitute function to pull out The Label You Want To See In The World - with virtually no overhead.

And in your integration, you can similarly extract the external ID with some very easy find + left logic, and discard the rest.

And finally, whenever you change the picklist label, you can update the API name without breaking your integration.

That said, gIven that the whole point of this feature is specifically to ‘keep picklist integrations safe’ by decoupling changes to labels from the API values, none of this tomfoolery should be necessary and Salesforce (er, Vladimir Gerasimov) should have pushed to add a formula to get the label on day 1. Note : I love Vlad’s work - he has done so much awesome work on things including global picklists, custom metadata types, and the time field type - but this one is ¾ baked at best.

So vote early and vote often for this idea, and gently, kindly, and empathetically harass Vlad if you see him.

And until that idea gets delivered and flows realize their destiny, just use this approach and you will get the benefits that this functionality was designed to deliver!