Tag Archives: Admin

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?


Salesforce Field History Tracking

One of my favorite Salesforce features is Field History Tracking. Field History Tracking allows one to track a specified set of fields’ value changes over time. The field history is tracked up to 18 months by default.

Whenever a specified field is changed, Salesforce creates a new “History” record tied to the record in question. The History record contains the following information:

  • ParentId – The Id of the Salesforce record that had its field changed.
  • Field – The API name of the field that was changed.
  • OldValue – The old value of the field before the change was made.
  • NewValue – The new value of the field after the change was made.
  • CreatedById – The Id of the user who made the change.
  • CreatedDate – The UTC datetime of when the change was made.


On Standard Objects, field history tracking is setup by going to fields –> Set Field History Tracking –> Checking the fields to track and Saving.

On Custom Objects, one has to first enable field history tracking on the Object Definition page. Next, Click the “Set Field History Tracking” button, check the fields to track, and Save.

Account Setup Example


Note that the “(8 of 20 selected)” text is added from the Salesforce Boostr Chrome Extension, which is highly recommended.

Account Field History Example



  • Eases Troubleshooting – This allows an admin or developer to see what changes have happened to a record over time. When troubleshooting, this is a godsend because it allows one to see what happened to the data over various records in a given timeframe. For example, a particular user may be incorrectly entering data so that user needs additional training and/or the system needs additional validation.
  • Auditing – Certain industries require additional auditing of data for various reasons such as complying with governmental regulations. E.g Sarbanes-Oxley or HIPAA.
  • History Records don’t count towards record counts. Typically, an enterprise Salesforce org has a limit of 1GB or 500,000 records, since each record counts as 2KB. With many fields being tracked across objects, many history records can be created.
  • History Objects are queryable through SOQL. This is helpful because there are times when a bug in software has caused numerous records to be updated with wrong value(s). One can query all the parent records with their old values and reset the invalid field(s) to their former values with a data correction apex script.


  • Changes to fields with more than 255 characters are tracked as edited, and their old and new values are not recorded.
  • If a trigger causes a change on an object the current user doesn’t have permission to edit, that change is not tracked because field history honors the permissions of the current user.
  • Detail Objects part of a Master-Detail relationship can’t have their Field History Tracking used in Salesforce reports.
  • Other Caveats


  • Always enable Field History Tracking and specify the fields to track.
  • If there are 20 fields or less, track all the fields.
  • If there are more than 20 fields, choose the fields to track based on priority.
  • Know that more than 20 fields can be tracked per Object for an additional cost. Contact Salesforce for more information.
  • Know that Salesforce can retain history records for longer than 18  months if needed. Contact Salesforce for more information.

What other benefits, caveats, and recommendations do you have regarding Field History tracking?

Happy Coding,