| name | screen-flow-choice-component-selection |
| description | Use when picking which Screen Flow component collects a choice from users — Picklist, Radio Buttons, Radio Button Group (Summer '26), Multi-Select Picklist, Checkbox Group, Choice Lookup, Dependent Picklists, or Data Table — and which Choice resource (Choice, Record Choice Set, Picklist Choice Set) populates it. Covers single- vs multi-select semantics, the Loop/Transform incompatibility of the multi-select components, and set-size/searchability tradeoffs. NOT for building the choice-set resource internals from records or picklist fields (use flow/flow-dynamic-choices), NOT the deep configuration of one component (see flow/screen-flow-radio-button-group, flow/flow-data-tables), and NOT general screen UX, navigation, or input validation (see flow/screen-flows, flow/flow-screen-input-validation-patterns). |
| category | flow |
| salesforce-version | Summer '26+ |
| well-architected-pillars | ["Operational Excellence","Performance"] |
| triggers | ["choosing the right choice component for a flow screen when users pick one option","deciding between Checkbox Group and Multi-Select Picklist for a multi-select flow screen","picking a screen component that scans well when a radio button list is too long","letting users search and select one value from a large set on a flow screen","figuring out why a multi-select picklist can't feed a Loop or Transform element"] |
| tags | ["screen-flows","choice-components","single-vs-multi-select","choice-resources","component-selection"] |
| inputs | ["The screen requirement: what you collect, single vs multiple selection, and where the choices come from (static list, filtered records, an existing picklist field, or a field dependency)","Expected size of the choice set and whether the selection must be iterated downstream in a Loop or Transform element","Target surface (desktop vs mobile) and any picklist field dependencies already defined in the org"] |
| outputs | ["A recommended screen component (Picklist, Radio Buttons, Radio Button Group, Multi-Select Picklist, Checkbox Group, Choice Lookup, Dependent Picklists, or Data Table) with the reason","The matching Choice resource type (Choice, Record Choice Set, or Picklist Choice Set) or field dependency to populate it","Downstream-compatibility warnings (e.g. Loop/Transform incompatibility) and a fallback design"] |
| dependencies | [] |
| version | 1.0.0 |
| author | Pranav Nagrecha |
| updated | "2026-07-08T00:00:00.000Z" |
Screen Flow Choice Component Selection
This skill activates when a builder must pick which Screen Flow component presents a set of options — and which Choice resource feeds it. Salesforce ships at least seven choice-oriented screen components plus a record-selection Data Table, each with different single/multi-select semantics, downstream compatibility, and set-size ergonomics. Salesforce maintains a dedicated decision-guide article for exactly this call, and Flow Builder even lets you swap between choice components after the fact — evidence that builders regularly pick the wrong one. Use this skill to make the choice deliberately instead of reaching for a Picklist by reflex.
Before Starting
Gather this context before working on anything in this domain:
- Confirm the selection cardinality. With the Picklist and Radio Buttons (and Radio Button Group) components, users select only one choice. With the Multi-Select Picklist and Checkbox Group components, users can select multiple choices. This is the first fork in the decision and it constrains every other option.
- Identify where the choices come from. Three Choice resource types feed the components: a Choice (manually entered values), a Record Choice Set (a filtered set of records), or a Picklist Choice Set (values from an existing org picklist field). Dependent Picklists is different — it reuses an existing field dependency, not a Choice resource.
- Ask whether the selection must be iterated. The Checkbox Group, Choice Lookup, and Multi-Select Picklist components are incompatible with Transform and Loop elements. If a downstream Loop or Transform has to process each selected value, those three are off the table — model with a Data Table over a record collection instead.
- Know the Radio Button Group maturity. The Radio Button Group component was introduced in the Summer '26 release notes. Its release-note title carries no "(Beta)" or "(Pilot)" qualifier (unlike sibling Beta features shipped the same season), which is consistent with GA — but the docs do not print the literal phrase "Generally Available" for it. Do not assert a maturity label the release notes don't state; confirm exact wording before promising GA behavior to a customer.
Core Concepts
The component catalog
Every choice-collection decision resolves to one row of this catalog. Cardinality and Loop/Transform compatibility are the two properties that most often force the choice:
| Component | Selection | Best when | Loop / Transform |
|---|
| Picklist (dropdown) | Single | Medium list; save vertical space | Compatible |
| Radio Buttons | Single | Short list; show all options at once | Compatible |
| Radio Button Group (Summer '26) | Single | Short list; compact stacked layout | Compatible |
| Choice Lookup | Single | Large list; user searches then picks one | Incompatible |
| Dependent Picklists | Single (chained) | Options depend on a prior picklist value | Compatible |
| Checkbox Group | Multiple | Few options; show all as checkboxes | Incompatible |
| Multi-Select Picklist | Multiple | Many options; compact multi-select | Incompatible |
| Data Table | Single or multiple rows | Select record(s) from a record collection | Collection output is Loop-friendly |
Choice resources — what populates a component
A component is the widget; a Choice resource is the data. You mix and match:
- Choice — "Give users simple values to choose from." You enter each value manually (Yes/No, High/Medium/Low).
- Record Choice Set — "Present users with a filtered set of records to choose from" (e.g. products in a family, contacts on an account). Because it surfaces live records, it must respect the running user's record access and field-level security.
- Picklist Choice Set — "Present users with a set of values that are defined in an existing picklist." This reuses an org picklist field, so the flow tracks the field's values instead of a hand-maintained copy.
The same Record Choice Set can back a Picklist, Radio Buttons, or a Checkbox Group — the resource and the component are independent decisions. Dependent Picklists and Choice Lookup are the exceptions: Dependent Picklists reads an org field dependency directly, and Choice Lookup draws from a choice source you configure on the component.
Single-select layout is a UX choice, not a behavior change
Picklist, Radio Buttons, and Radio Button Group are behaviorally identical — the user picks exactly one value. They differ only in layout. Radio Buttons render a vertical list where every option is visible; Radio Button Group "presents horizontally (desktop) or vertically (mobile devices) stacked choices that are compact and easier to scan" and "functions like the traditional Radio Buttons component where users select a single option at run time." A Picklist collapses the list into a dropdown to save space. Choice Lookup adds typeahead search for cases where even a dropdown is unwieldy. Because these are interchangeable at the data layer, Flow Builder lets you switch between choice components (the "Let Users Select Multiple Options" toggle also flips a single-select component to its multi-select equivalent) without rebuilding the screen.
Common Patterns
Right-size the single-select widget to the set size
When to use: the user picks exactly one value and you're deciding between Radio Buttons, Radio Button Group, Picklist, and Choice Lookup.
How it works: scale the widget to the number of options. A handful of options → Radio Buttons or Radio Button Group so every choice is visible at a glance (Radio Button Group when horizontal/compact scanning matters). A medium list → Picklist to reclaim vertical space. Dozens or hundreds of options → Choice Lookup, which "lets users search for and select one option from a set of choices on a flow screen" instead of forcing a scroll.
Why not the alternative: a Radio Buttons list of 40 options is unscannable and pushes the rest of the screen below the fold; a Picklist of 200 options is a scroll marathon. Matching widget to set size is the core of this skill.
Choose the multi-select component by downstream needs, not looks
When to use: the user selects several values and you're deciding between Checkbox Group and Multi-Select Picklist.
How it works: if the choice set is small and you want every option visible, use Checkbox Group; if it's long and you want a compact control, use Multi-Select Picklist. But first check what happens to the selection: all three multi-value components (Checkbox Group, Multi-Select Picklist, Choice Lookup) are incompatible with Loop and Transform elements. If a later Loop or Transform must process each selected value, neither multi-select component works — restructure around a Data Table over a record collection, whose selected-rows output is a collection a Loop can iterate.
Why not the alternative: teams pick Multi-Select Picklist for the compact UI, wire a Loop to the selection, and only discover at build time that the Loop can't reference it. Deciding on iteration before the component avoids a rebuild.
Reuse an existing field dependency instead of hand-building cascades
When to use: the value list for one picklist depends on the value chosen in another (Country → State, Product Family → Product).
How it works: the Dependent Picklists component "displays picklists in a flow screen where the options for one picklist depend on the selected value of another picklist using an existing field dependency in your org." Define the field dependency in Setup first, then drop the component on the screen — it reads the dependency automatically. The controlling field must be a picklist (with at least one and fewer than 300 values) or a checkbox on the same object.
Why not the alternative: simulating the cascade with two independent Picklists plus Decision elements or reactive formulas re-implements logic the platform already maintains, and drifts whenever the field dependency changes.
Decision Guidance
| Situation | Recommended Approach | Reason |
|---|
| Pick exactly one, short list (~2–7) | Radio Buttons or Radio Button Group | Every option visible; Radio Button Group stacks compactly (Summer '26) |
| Pick exactly one, medium list | Picklist (dropdown) | Compact; reclaims vertical screen space |
| Pick exactly one, large/searchable list | Choice Lookup | Typeahead search for one option among many |
| Options depend on a prior picklist value | Dependent Picklists | Reuses an existing org field dependency |
| Pick several, few options | Checkbox Group | Checkbox layout shows all options |
| Pick several, many options | Multi-Select Picklist | Compact multi-select control |
| Selection must feed a Loop or Transform | Data Table over a record collection — not Checkbox Group / Multi-Select Picklist / Choice Lookup | Those three are incompatible with Loop and Transform |
| Select one or more records (rows) | Data Table | Row selection with a Loop-friendly collection output |
| Choices are filtered records | Any component + Record Choice Set | Presents a filtered set of records (respect record/FLS access) |
| Choices mirror an existing picklist field | Any component + Picklist Choice Set | Tracks the field's values instead of a copy |
| Choices are a small fixed list | Any component + Choice resource | Manually entered values |
| Choices contain rich text or markup | Checkbox Group, not Multi-Select Picklist | Multi-Select Picklist doesn't support rich text and hides text between < and > |
Recommended Workflow
Step-by-step instructions for an AI agent or practitioner working on this task:
- Characterize the requirement — confirm single vs multiple selection, where the choices originate (static list, filtered records, an existing picklist field, or a field dependency), the expected set size, and whether the selection must be iterated in a Loop or Transform.
- Pick the cardinality lane — single-select (Picklist, Radio Buttons, Radio Button Group, Choice Lookup, Dependent Picklists), multi-select (Checkbox Group, Multi-Select Picklist), or record-row selection (Data Table).
- Choose the component within the lane — apply the Decision Guidance table, weighting set size, scannability, search, dependency, and target surface (desktop vs mobile).
- Choose the Choice resource — Choice, Record Choice Set, or Picklist Choice Set (or a field dependency for Dependent Picklists) to populate the component. Confirm a Record Choice Set exposes only records/fields the running user may see.
- Check downstream compatibility — if a Loop or Transform must process the selection, reject Checkbox Group / Multi-Select Picklist / Choice Lookup and redesign around a Data Table + record collection.
- Validate on target surfaces — verify layout on desktop and mobile, confirm no unstated maturity assumption for Radio Button Group, and run
scripts/check_screen_flow_choice_component_selection.py against the flow metadata to catch Loop/Transform incompatibilities and oversized single-select lists.
Review Checklist
Run through these before marking work in this area complete:
Salesforce-Specific Gotchas
Non-obvious platform behaviors that cause real production problems:
- Multi-select components can't feed Loops or Transforms — Checkbox Group, Multi-Select Picklist, and Choice Lookup are incompatible with Transform and Loop elements. You discover this only when you try to wire the Loop, after the screen is built. Decide on iteration first.
- Multi-Select Picklist silently swallows markup — it doesn't support rich text and "doesn't show text between the
< and > characters," so choice labels containing angle brackets render blank or truncated. Use Checkbox Group when labels carry markup.
- Dependent Picklists needs the dependency defined first — the component reads an existing org field dependency; without one defined in Setup it has nothing to display. Also, hidden picklists inside a Dependent Picklists component aren't set to null on conditional visibility unless the whole component is hidden — unlike other screen inputs.
Output Artifacts
| Artifact | Description |
|---|
| Component + resource recommendation | The chosen screen component and the Choice resource (or field dependency) that populates it, with the reason |
| Downstream-compatibility note | Whether the selection can feed a Loop/Transform, and the Data Table fallback design if not |
templates/screen-flow-choice-component-selection-template.md | A selection worksheet that walks the cardinality → source → size → iteration decision to a recommendation |
scripts/check_screen_flow_choice_component_selection.py | Stdlib checker that flags multi-select components fed to Loop/Transform and oversized single-select choice lists in flow metadata |
Related Skills
flow/flow-dynamic-choices — build the Record Choice Set / Picklist Choice Set / dependent choice resources this skill selects a component for.flow/flow-resource-patterns — the full Choice / Record Choice Set / Picklist Choice Set resource model and where each lives in scope.flow/screen-flow-radio-button-group — deep configuration of the Summer '26 Radio Button Group component once this skill has selected it.flow/flow-data-tables — the Data Table row-selection mechanics used as the Loop-friendly fallback for multi-select scenarios.flow/screen-flows — general screen navigation, commit timing, and UX once the component is chosen.
