Default Flow Picklist Value Without Duplicates

Flows are great but there are some quirks. One quirk is that a picklist input field can’t be prepopulated with the existing picklist field value from a record. There are some workarounds:

and there’s even an Idea: Flow – Pre-populate choices with dynamic values (variables).

The workarounds are good but one minor nuisance is that they cause the current picklist value on the record to be duplicated in the dropdown list.

Below is my solution that doesn’t have a duplicate option by using the PicklistValueInfo standard object in a Dynamic Record Choice.

High-Level Solution

  1. Query the record with the desired fields including the picklist field(s) using a Record Lookup or Fast Lookup.
  2. Create “Current Picklist Formula” that has an expression like “If(IsBlank(record.PicklistField), ‘Select an option’, record.PicklistField) so the formula can be used to dynamically use either the record’s picklist value if there is one or ‘Select an option’ if it’s blank.
  3. On a screen, create a picklist input with the following settings:
    • Choice – Use the current picklist formula as the label and stored value
    • Dynamic Record Choice – Use the PicklistValueInfo standard object to query all the picklist values except the currently selected value.
    • Set the Default to the “current choice”.

Industry Example

Let’s create a flow that allows one to quickly update the Industry field on an account record in Lightning.

Create recordId Variable

Query Account Record

Use a Record Lookup or Fast Lookup to query the account or desired record using the recordId variable. In the screenshot below, a Record Lookup is used. Note how the current industry is stored in the “Current_Account_Industry” variable.

Create Industry Default Choice Formula

Now, let’s create the “Industry_Default_Choice” formula that uses

  1. The “Current_Account_Industry” variable if it’s not blank.
  2. “Select an Industry”, otherwise.

Create “Selected Industry” Variable

Another quirk that drives me crazy is having to create a variable for a dynamic record choice to be saved to before it’s created. That’s needed because a dynamic record choice doesn’t allow one to create a variable on the fly like most other places.

Create a “Selected_Industry” variable like:

Create the Industry Input Field

Let’s start with the finished “Industry” dropdown list input field.

To create this, add a Dropdown List Input field to the desired screen.

Next, create a new “Choice” through the Add Choice link using the following settings:

The “Industry_Default_Choice” formula is used for both the Label and the Stored Value so they both can be dynamic. I.E. if the account has an industry, then it’ll be defaulted. Otherwise, “Select an Industry” is used.

Next, create the “Industry_Picklist_Choices” Dynamic Record Choice with the following settings:

Let’s break this down a bit. The “PicklistValueInfo” standard object contains all the picklist values for every picklist field on every object in the org. The “EntityParticleId” column has values in the format of <Object_API_Name>.<Picklist_API_Name>. In this example, the “Industry” field from the “Account” object is used so “Account.Example” is used to query all the Industry picklist records.

The second filter of “Value  does not equal  {!Current_Account_Industry}” will exclude the current industry, if there is one. If no industry is selected, all the active Industry picklist values are shown.

Now, simply use the {!Selected_Industry} variable as needed in the flow to do something with the selected value.


  • The list of industry picklist values are dynamic and change automatically without having to alter the flow as the Industry picklist values change.
  • The inactive picklist values are automatically excluded.
  • There’s no duplicate value in the list.


  • The picklist values available per record type aren’t honored. The user sees all the active picklist values.

What did you think of the solution?


Overview of Integrating with Salesforce

For a while now, I’ve been meaning to write about integrating with Salesforce. What motivated me to do it is a colleague asking me today: “Hey Luke. I have a system that has to write data back to Salesforce. What are my options?”

What’s an Integration?

An integration is when two or more systems talk to each other to accomplish something.

Two common integration types are

  • Single Sign-On (SSO)
  • Data Exchange

Single Sign-On (SSO) Overview

With Single Sign-On aka SSO, a user signs into one system, typically using their username and password, and then they’re able to sign-in automatically to other systems that are connected to that system without having to sign-in again.

The system where one signs in is known as the “Identity Provider”, or in some circles the “IdP”.

SSO Common Examples

  • A company’s website uses Salesforce as an Identity Provider. When someone tries to access a secure webpage on the website without being signed-in, they’re redirected to the Salesforce login page or community login page. After successfully signing in, they’re redirected back to the requested, secure webpage and are able to view it.
  • A Salesforce community allows one to login to the community using their favorite social media site such as Facebook, Google, Twitter, LinkedIn, etc. This is commonly known as “Social Sign-On”. It’s still SSO but with a social network as the identity provider.
  • An employee has signed in to their work computer and are automatically signed in to Salesforce. The most common example of this is when a company uses Active Directory and when you sign-in to your computer, you’re also signing in to the employer’s network. Since Salesforce can be configured to use your employer’s Active Directory for SSO, it’s a seamless experience to automatically sign-in to Salesforce.

SSO Technical Options Overview

API / Forms Authentication 

A system has a login page in it that accepts a username and password. When someone clicks “Sign In” or “Login”, the system calls the identity provider’s API passing in the supplied username and password, and if they’re signed in, their user information is returned to the calling system and they’re signed in. This used to be the most common way to do it before Open Id and other more secure protocols were created.

OpenID with OAuth2

In my experience, OpenId with OAuth2 is now the default SSO protocol used because it’s more secure and has become widely adopted. The High-Level handshake goes like this:

  1. User tries to access secure webpage and isn’t logged in so user is redirected to the Identity Provider’s website.
  2. The Identity Provider asks the user if they’d like to authorize that system to connect to this system. If they “allow it”, then they’re redirected to the Login page.
  3. User signs in and is redirected to the originally requested secure webpage on the other system along with a user token aka a special sign-in value.
  4. The original system takes this user token and asks the Identity Provider for the user’s information. The identity provider passes back the user’s information such as their name, contact information and possibly security information so the system knows what they have access to.

The primary advantage that this protocol has over “Forms Authentication” is that the users are only entering their credentials on the Identity Provider and the third-party systems never see a user’s credentials. This makes it more secure.

That’s the very quick gist of OpenId. Take a look at the OpenID with OAuth2 Documentation for more information.


SAML is another common SSO protocol but seems to be less adopted than OpenId. It’s pretty similar to how OpenId works but uses XML and assertions instead of JSON. See the SAML SSO Implementation Guide for more info.

Data Exchange

Data exchange is when two or more systems share data. There are many reasons why two systems would share data. Some common examples are:

  • The company’s e-commerce site integrates with company’s back office system to grab product information and to handle order processing.
  • A company replicates its data from many systems into a central data warehouse so that Business Intelligence software can do various analytics on it.

Data Exchange Models

There are three common models for exchanging data between systems:

  • Push
  • Pull
  • Middleware

Push Model

In a “Push” model, one system tells another system directly here’s the data to use and do something with it such as insert, update, or delete it.

This is most often used for “Real-Time” integrations where as soon as something happens in System A, System B is notified by System A. This allows the two systems to remain synchronized faster. For example, an order is submitted on the e-commerce site and then the site immediately tells Salesforce there’s a new order for that customer so it gets saved in Salesforce too. Another example is an account record is created in Salesforce so Salesforce does a callout to the data warehouse to replicate the data.

Pull Model

In a “Pull” model, one system asks another system directly for information.

This is often used for synchronizing large amounts of data that doesn’t have to be updated frequently because it doesn’t change often or it’s ok if the data isn’t exactly the same for a little while. One example is the data warehouse asking Salesforce for all the latest CRM data that’s changed in the last day.


A third system sits between two systems that have to exchange data but the two systems don’t directly communicate with each other. All data flows through the middleware. This can be beneficial because this specialized software is able to handle large volumes of data using various methods and typically doesn’t require any coding. They also usually have pre-built integrations for commonly integrated systems.


Data Exchange Methods

Now that we’ve covered the high-level models, let’s talk about how the data is exchanged.

Importing & Exporting with Files

This manual process requires someone to generate a file with the data to exchange in System A and then manually import it into System B. One common format is a comma separated value aka CSV file. One can even manipulate the data using common tools such as Excel before importing the data into the target system.

With Salesforce, one can use reports and even listviews to generate export files that can then be imported into other systems.

  • Usually easy and fast to implement.
  • Good for data that doesn’t have to update often.
  • Salesforce has decent out-of-the-box features for exporting and importing data.
  • It’s manual so people are involved so this can be slow and error prone.

Application Programming Interfaces (APIs)

An API allows another system to programmatically talk to it without human intervention.  There are different types of APIs such as REST and SOAP but for this overview, we’ll be skipping over those technical differences.

The primary benefit of having an API is that one or more external systems are able to use it to communicate with the system using a standard set of “services”.

Salesforce Enterprise / Partner APIs

The Enteprise and Partner APIs are standard APIs provided by and maintained by Salesforce so that external systems can Create, Read, Update, and Delete records in Salesforce. They come in SOAP and REST versions and are good for handling up to thousands of records at a time.

Salesforce Bulk API

This Salesforce provided API was designed to handle up to billions of records. It’s asynchronous and typically harder to use than the Enterprise or Partner APIs because multiple services have to be used to accomplish a single operation.

Salesforce Custom APIs

Developers can use Apex to create custom APIs that external systems can use to talk to Salesforce. This is typically done for more complicated scenarios and processing that the Enterprise, Partner, and Bulk APIs can’t handle alone.

API Pros
  • Multiple external systems can use the same API to communicate with the system.
  • No human intervention required.
  • Could potentially be easily consumed with standard middleware tools without coding.
API Cons
  • Creating good APIs are hard and time consuming because
    • they require good documentation so other developers can easily use them.
    • it takes a while to design and implement.
  • Often require developer level technical abilities to use.

Salesforce External Objects

This declarative option allows Salesforce to connect to an external system’s API, as long as that external system uses the OData protocol, to create, read, update, and delete the external system’s data from within Salesforce. The data is read and manipulated in real time from within Salesforce without having it stored in Salesforce.

  • Declarative and fairly easy to set up.
  • Uses object tabs and listviews to interact with the data.
  • Expensive. I hear it’s like $3-4 thousand per external object. If I’m way off, please let me know.

Salesforce External Services

This declarative option allows one to provide a “service schema file” to Salesforce using a particular format and Salesforce is then able to call an external system’s API using Flows. At the time of this writing, this feature is still in Beta.

  • Declarative and looks easy to set up.
  • ?? – Let me know in the comments since I haven’t used this option.


There are other ways to integrate such as using Canvas Apps and inbound email services but they don’t seem to be used much in my experience.

What did you think of this overview? Are there other integration options? Let us know in the comments.