Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

A record choice set fills a screen component’s options from records returned by a query you configure on the resource itself, and a picklist choice set fills them from the active values of a picklist field. Record choice sets are for choosing a record. Picklist choice sets are for keeping a screen in step with a picklist someone else maintains. Both are configured on the resource, not on the component, which is where most of the confusion starts.

Record choice sets

Create a new resource of type Record Choice Set and you configure an object, filter conditions, a sort field and direction, a maximum number of records, and then two important settings: which field supplies the label the user reads, and which field supplies the value the flow stores.

Almost always the value should be Id. Storing the Name means you then have to query the record again to do anything with it, and it breaks the moment two records share a name.

The resource also lets you store additional field values into flow variables when a choice is selected. That saves a Get Records after the screen. Configure it for the two or three fields you genuinely need rather than everything on the object.

The record limit is not optional

The choice set asks for a maximum number of records, and leaving it blank does not mean unlimited. Every record in the result is loaded into the screen at render time, so a choice set over a large object produces a slow screen and an unusable list of options long before it produces an error.

Set the limit deliberately, filter as tightly as the requirement allows, and sort so the likely answer is near the top. If the user genuinely needs to pick from thousands of records, a choice set is the wrong component. Use a Lookup screen component, which searches server-side as the user types.

Picklist choice sets

A picklist choice set points at an object, a record type, and a picklist field. The screen then shows that field’s active values, and when someone adds a value in Setup the screen picks it up without anyone editing the flow. That is the whole reason to use one.

Things to know:

  • Inactive values are excluded, which is correct and occasionally surprising when historic data uses one.
  • The record type you select governs which values appear. Choosing the master record type when your users are all on a specific one shows values they should not see.
  • Dependent picklists do not behave as dependent picklists here. Selecting a controlling value does not filter the dependent choice set. Build that with component visibility or separate choice sets and a Decision.
  • Multi-select picklist fields store their selections as one semicolon-joined string, so a Decision comparing the stored value with Equals against a single option will not match when the user picked two.

Collection choice sets

The third option is worth knowing because it solves a problem the other two create. A collection choice set builds its options from a record collection that already exists in the flow, typically from a Get Records element you ran earlier.

Use it when the flow has already queried the records for another reason, when the filter is too complex for the choice set’s own condition builder, or when the list depends on an answer from an earlier screen. It also gives you Collection Filter and Collection Sort to shape the list before it reaches the screen, which the record choice set’s own configuration cannot match.

Reading the answer back

The screen component stores the selected value, not the choice object. For a radio button group or a picklist component bound to a record choice set, the component’s value is whatever you set as the value field, so {!Screen1_ChooseAccount} holds an Id if you configured it that way.

For a multi-select checkbox group the component holds a collection of values, and you loop it or pass it straight into a Get Records with an In filter.

Frequently asked

Why is my choice set empty? The filter matched nothing, or the running user cannot see the records. A screen flow launched from a record page runs in user context by default, and sharing applies.

Can I add a “None” option? Add a standalone Choice resource and place it alongside the choice set on the component. Components accept several choice resources in order.

Can I refresh the choices based on an earlier field on the same screen? Not with a record choice set, whose filter is fixed at design time. Use reactive screen components with a collection choice set, or split the flow across two screens.