If you've spent any time in Flow Builder, you've run into screen components. They're the building blocks of every Screen Flow — the inputs, displays, and layout elements that make up what your users actually see and interact with.

Most admins start with the native Salesforce components, which is the right call. They're free, supported, and for straightforward flows they get the job done. But at some point you hit a wall. A user needs to choose between options visually, not via dropdown. Someone wants a calendar instead of stacked date pickers. A stakeholder asks why users can't just edit cells in the table. That's when the native toolkit starts showing its limits.

This guide covers all of it: what Salesforce includes out of the box, where it stops, what changed in Spring '26, and your realistic options when you need more.

What Are Flow Screen Components?

A Screen Flow is one of Salesforce's five flow types — and the only one that puts a UI in front of the user. Rather than running quietly in the background like a Record-Triggered Flow, it presents screens that walk users through a process step by step. Case creation wizards, onboarding forms, field inspection checklists, appointment booking flows.

Flow screen components are what those screens are made of. Each component is self-contained: a text input, a date picker, a record table, a file uploader. You drop them onto a screen in Flow Builder, configure their properties, connect them to flow variables, and they handle the rest.

Three types:

• Input components — collect data from the user (text fields, picklists, lookups, file uploads)
• Display components — show information without collecting anything (formatted text, images, record tables)
• Layout components — organize the screen itself (sections, columns, tabs)

All three connect to flow variables, so data passes cleanly between screens and into your downstream automation logic.

Salesforce's official documentation covers the full spec for each component: Standard Flow Screen Components on help.salesforce.com.

How to Add a Component to a Screen Flow

Same process whether you're using a native component or one from a managed package. Six steps from blank screen to something wired and working.

1. Open or create a Screen element in Flow Builder. Click the + button between elements and select Screen, or click on an existing Screen element to open it. The Screen editor opens on the right.
2. Find the component in the sidebar. The left panel lists all available components — native ones grouped by type (Input, Display, Layout), managed package components below them. Search by name if you know what you're looking for. If you've installed Avonni, every component in the library appears there.
3. Drag it onto the canvas — or click to add. Drag from the sidebar onto the screen preview, or click the component name to drop it at the bottom of the screen. Components stack vertically by default. Add a Screen Column layout component if you want two side by side.
4. Configure its properties in the right panel. Click any component on the canvas to open its property panel — label, help text, required toggle, component-specific settings. For Avonni components, this opens the Component Builder: configure the label, set options, wire a variable, and see the result live without leaving the panel.
5. Wire it to a flow variable. Every input component has an API Name field — this maps to the flow variable it writes to. Set it to an existing variable or type a new name and Salesforce creates it. Whatever the user enters goes into that variable and carries through every subsequent screen and action in the flow.
6. Preview before saving. Click View in the Screen editor to see what the user will see, including how conditional visibility rules behave at runtime. For Avonni components, the live preview in the Component Builder makes this step redundant for most configuration work.

Variable naming tip: Prefix your variables consistently — something like inp_ for user inputs and rec_ for record queries. Flows accumulate variables quickly. Without a naming scheme, the variable picker becomes a wall of text before long.

The Native Salesforce Components

A complete reference of what ships with every Salesforce org today.

3-column card grid: Input (15 types), Display (4 types), Layout (2 types) — with pill tags for each component name and a count badge per category.

Where Native Components Fall Short

The standard library is solid. It is not complete.

No card-based selection. There is no visual picker, no card UI, no icon selector. When a user needs to choose between a handful of options and a dropdown doesn't feel right, native components don't help.

The Datatable is limited. It displays records and lets users select rows — that's about it. No inline editing, no custom column types, no bulk actions, no persistent sort. The moment someone asks whether users can edit cell values directly in the table, the answer with native is no. For flows built around reviewing or updating lists of records, this creates real friction. A proper data table for Salesforce flows handles these cases differently.

No calendar view. Scheduling-heavy flows — booking appointments, reviewing availability windows, picking date ranges — have no native calendar component. You stack date pickers and hope users piece it together. For anything where "show me available slots this week" is part of the UX, a dedicated calendar component for flows is the more honest answer.

No kanban. For stage-based processes — lead qualification, case routing, project milestones — there is no board view. Everything is flat.

No charts or metrics display. If you want to show a user their current stats before they take an action, you're stuck with Display Text and number fields.

Limited layout control. Sections and columns get you partway. Tabs, full accordions, stepped wizards with a progress indicator at the top — those need custom work or a third-party package.

This isn't a Salesforce problem so much as a scope decision. The native components cover most flows. The gaps show up on the 20% where UX actually matters.

Same flow screen side by side. Left: radio buttons, basic table, date picker. Right: Visual Picker cards, enhanced table with status badges + inline edit icons, full calendar widget.

What Changed in Spring '26: Reactive Screen Components

Before Spring '26, screen components on the same screen were isolated from each other. A picklist selection couldn't immediately filter the options in another picklist without navigating away first. Multi-field interactions required workarounds — multiple screens, decision elements, navigation loops that confused users.

Reactive screen components changed this. Components on the same screen can now respond to each other in real time, with no page navigation. A lookup selection filters a dependent picklist. A toggle shows or hides sections. A checkbox updates a displayed total — all immediately, without leaving the screen.

The official documentation covers setup and supported patterns: Reactive Screen Components in Flows.

In practice: fewer screens, simpler flow logic, less user confusion. What used to need four screens and a loop often becomes one screen with properly wired components.

Worth knowing: Third-party components including Avonni's support reactivity. A Visual Picker selection can drive what populates in a Datatable. A Kanban column change can update a metric card on the same screen. The combination of rich component types and reactive wiring opens up UX that wasn't practical before Spring '26.

How reactive wiring actually works

Every input component on a screen writes to a flow variable when the user interacts with it — that's always been true. What changed in Spring '26 is that other components on the same screen now re-read their properties in real time as those variables update. No navigation. No separate screen.

The wiring is just variable references. Set Component A's API Name to a variable. In Component B's properties, reference that same variable using {!variableName}. When the user interacts with A, B updates immediately.

Practical examples that work today:

• Toggle → conditional visibility. A toggle updates a boolean variable. Another component uses that variable in its Set Component Visibility rule. The component shows or hides the moment the user clicks — no navigation required.
• Radio buttons → Display Text summary. Radio button selection updates a variable. A Display Text component shows "Service type: {!selectedType}". As the user changes their selection, the summary updates live on the same screen.
• Picklist → dependent picklist. A Status picklist selection can filter the options shown in a sub-status picklist on the same screen — no multi-screen workaround needed.
• Slider → live number display. A slider updates a numeric variable. A Display Text shows the current value. The number updates as the user drags.

What reactive components don't do

Reactive screen components work within a single screen — component to component, via shared variables. They don't run Get Records queries or Apex actions in the background while the user stays on screen. If you need to query records based on a user's selection and show the results on the same screen, that still requires navigating to a next screen where the query runs, then returning to display results — or building a custom LWC that handles the data fetch internally.

Reactivity is automatic on Spring '26 orgs. There's no separate toggle to enable. Reference a variable in a component's property, and if another component on the same screen updates that variable, yours re-renders. The Salesforce docs have a list of which component properties support reactive updates — not all of them do.

Real-World Use Cases

• Case management intake. A support team uses a flow to triage incoming requests. Native components handle the text fields and lookups fine. The priority field — meant to let agents pick from three visually distinct options — ends up as a radio button. It works, but it's not what anyone designed. A Visual Picker component closes that gap without a developer involved.
• Field team inspection forms. Technicians fill out inspection checklists on a phone, sometimes offline. Native components hold up: text inputs, checkboxes, file uploads. The problem is layout. Twenty fields stacked vertically on a phone screen is genuinely hard to use. Sections and conditional visibility help. A mobile-aware layout component with tabs handles it properly.
• Appointment scheduling. A service team lets customers book slots through an Experience Cloud flow. Picking a date works fine with native. "Pick a slot from available times this week" is a different UX problem entirely — that's a calendar, not a date picker. Without a calendar component, you're either building workarounds or shipping something that frustrates users.
• Record enrichment flows. A sales team uses a flow to update multiple account records in bulk. Native Datatable lets them select rows. Actually editing cell values inline — updating a status, changing a field — requires inline editing, which native doesn't support. An advanced data table with inline editing turns what would be a multi-step navigation exercise into something that takes a few minutes.
• Location-based dispatching. Service dispatchers assign technicians to jobs based on proximity. A map component that shows job locations and available technicians on the same screen, with click-to-assign, is the right UX for this. Native has nothing close.

Community Components: UnofficialSF

Before commercial packages had much traction, the Salesforce community built its own. UnofficialSF, maintained by Alex Edelstein at Salesforce, is the main hub for free community-contributed flow screen components.

The list is long and genuinely useful: Quick Lookup, Quick Choice (an improved picklist), Flexcard, an LWC Datatable significantly better than native, Barcode Scanner, Signature Capture, Rich Text Input, and dozens more.

Quality and maintenance vary by component. Some haven't been updated in years. Others depend on a single developer staying interested. In enterprise orgs — especially those with strict AppExchange security policies — unmanaged community code is often a blocker. Some organizations simply won't allow it.

For personal projects, internal tooling, and quick prototypes, UnofficialSF is excellent. For production flows in regulated industries or large orgs, you want something with a support contract behind it.

Custom LWC vs. a Managed Package: Which Makes Sense?

If native and UnofficialSF both fall short, you have two remaining paths: build a custom Lightning Web Component, or install a managed package. Admins sometimes assume a developer is the only answer. It depends.

Build a custom LWC when:

The component needs behavior that doesn't exist anywhere — a very specific interaction tied to proprietary business logic, a deeply branded UI that no package will let you match, or an integration with an internal system that a managed package couldn't reach. Custom LWCs are the right call when uniqueness is the requirement.

The real cost: a custom LWC is a software artifact. It needs a developer to build it, someone to test it across Salesforce releases, and a process to maintain it when something breaks. If your admin team owns the flow but a developer owns the component, you've introduced a dependency that slows every future change.

Use a managed package when:

The component you need already exists in the package's library, and the use case is recognizable — a calendar, a data table with inline editing, a card picker, a kanban board. These are solved problems. A managed package gives you a tested implementation on day one, with upgrades handled by the vendor and support available if something breaks.

The practical test: if you can describe what you need in a sentence a product manager would recognize, a managed package almost certainly has it. If you're describing something genuinely unique to your org, that's a custom LWC conversation.

For most admins building production flows, the managed package path is faster, cheaper over time, and keeps the flow fully maintainable without a developer in the loop for every change.

Commercial Packages on the AppExchange

The AppExchange has a handful of paid flow screen component packages. They vary in library size, release cadence, and what support actually looks like when something breaks. Before committing to one, the useful things to compare: how many components are included, whether the package has been updated within the last six months, and whether there's a real support contract or just a community forum.

Avonni Flow Screen Components — the largest managed library on the AppExchange, with 70+ components across data input, display, and layout. Every Avonni component opens a configuration panel with live preview, so admins can style components, wire interactions, and test behavior without writing code. That Component Builder is what makes the difference day-to-day — most packages give you components with property panels, Avonni gives you a visual editor where you see exactly what you're building.

What's in the Avonni library that native doesn't have, just to name a few:

• Visual Picker — card-based selection with images, icons, and descriptions
• Kanban Board — drag-and-drop stage management inside a flow screen
• Calendar — full date/event calendar with click interactions wired to flow variables
• Advanced Datatable — inline editing, multi-sort, custom column types, bulk row actions
• Rich Text Editor — full WYSIWYG input, not just a text area
• Metric Cards — KPI display with visual context before the user acts
• Timeline — chronological activity display for audit trails or approval histories
• Tabs, Accordions, Stepped Wizards — real layout control for multi-section forms
• Combobox with Multi-Select — enhanced selection with search, icons, and multi-select in one component
• Signature Capture — managed, no external dependency

Components work in any screen flow context: Flow Builder for internal users, Experience Cloud for external users, App Builder pages with embedded flows. Pricing is per-org and scales from single-org installs to enterprise agreements — the AppExchange listing has current details. There is a free trial.

How to Choose

Start native. Free, supported, handles most flows. Build it first with what's available — you'll know quickly when you've hit a real limit.

If you hit that limit on a non-critical flow, check UnofficialSF. Good chance someone already built what you need, for free.

If you're building flows at scale — multiple teams, customer-facing flows, flows that need to match a design standard, flows that a stakeholder described as needing to feel like a real product — a managed package makes sense. Consistent components, vendor support, a library you can rely on across dozens of flows without auditing each one individually.

The cost math shifts fast. A developer building a custom kanban component is a multi-day project. An admin configuring the same component in 20 minutes with a managed package is a different calculation. The breakeven tends to happen sooner than people expect.

Tips for Better Flow Screens

Use sections and columns. A single-column screen with 15 stacked fields is exhausting — group related inputs, use two columns for short fields, break long forms into labeled sections.

Lean on conditional visibility. Hiding irrelevant fields based on prior inputs keeps screens focused. Most components support it natively. Use it aggressively — the fewer fields a user sees at any one moment, the better.

Wire variables before styling. Configuring a component's appearance before figuring out how its value flows downstream always costs time later. Do the variable mapping first.

For multi-field interactions, use reactive components. If one field's value should change what a user sees elsewhere on the same screen, reference that variable in the dependent component's properties and it updates automatically. Simpler logic, better UX.

If your users are in the field, test on mobile before you go live. Flow screens that look fine on desktop regularly fall apart on the Salesforce mobile app. Discover this before your users do.

More screens with fewer fields is almost always better than one overwhelming form. Users finish multi-step flows. They abandon walls.

Common Screen Flow Problems — and How to Fix Them

Seven issues that come up constantly. The causes are almost always the same.

Component doesn't appear at runtime

Visible in Flow Builder, gone when the flow runs. Either a conditional visibility rule evaluates to false on load, or the component depends on a variable that's null at that point. Do a debug run and inspect variable values at that screen. If the variable is null, initialize it with a Default Value or an Assignment element before the screen element.

Flow works in preview but breaks for end users

Preview runs as the admin. Production runs as the user. If the running user's profile lacks access to a record, field, or object the flow references, it errors silently or throws a generic message. Check FLS and object permissions for the target profile, then use Flow Debug with Run As set to a test user in that profile to see exactly what they see.

Mobile layout is broken

Screen Column components don't stack on mobile — they stay side by side on small screens, which makes narrow columns unusable. Test on the Salesforce mobile app, not just a resized browser window. For mobile-first flows, drop Screen Column and use Section components to group related fields. Keep each screen to five or fewer inputs.

Third-party component not showing in Flow Builder

Package installed, component missing from the sidebar. Usually a missing permission set — most managed packages require one before the components appear. Check the AppExchange listing for required permission sets. For Avonni, the permission set is called Avonni Components and needs to be assigned to anyone building or running flows with Avonni components.

Experience Cloud flow errors for external users

Works internally, breaks for guest users. Verify the flow has Make available for Experience Builder sites enabled in Setup → Flows. Then audit the Guest User profile's object and field permissions against everything the flow touches — Get Records queries included. Guest users have no access by default; every record, field, and object the flow needs must be granted explicitly.

Reactive component not updating

Wiring looks right but the dependent component doesn't refresh. Confirm the source component's API Name matches the variable name you're referencing in the dependent component's property exactly. Also check the Salesforce documentation for which specific properties on each component support reactive updates — not all properties on all components are reactive even on Spring '26 orgs. Run a debug session and watch the variable value after each interaction.

Frequently Asked Questions

Can you use Lightning Web Components in screen flows?

Yes. Any LWC that implements the lightning/flowSupport interface can be registered as a flow screen component. Third-party packages like Avonni work this way — every component is an LWC built for flow screen use. You can also build your own, but that requires a developer and maintenance work across each Salesforce release.

What's the difference between a Screen Flow and other Salesforce flow types?

Salesforce has five flow types: Screen Flow, Record-Triggered Flow, Scheduled Flow, Autolaunched Flow, and Platform Event-Triggered Flow. Screen Flows are the only type with a user-facing UI — the only type where screen components matter at all. If someone can see and interact with it, it's a Screen Flow. The others run in the background automatically.

What are reactive screen components, and do I need them?

Reactive components (Spring '26) let components on the same screen respond to each other without navigation — a toggle shows a section, a picklist filters another picklist, a slider updates a live display. The wiring is variable references: one component writes to a variable, another reads from it. You need them when one component's value should change what the user sees elsewhere on the same screen. For simple linear forms with no cross-component dependencies, they're not necessary.

When should I build a custom LWC instead of using a managed package?

Build custom when the behavior is genuinely unique to your org — proprietary logic, a deeply specific integration, or a design requirement no package can match. Use a managed package when the component you need is a recognized pattern (calendar, data table, card picker, kanban). Custom LWCs add developer dependency and maintenance overhead; managed packages stay maintainable by admins across every release.

One More Thing

The native components cover most of what you'll build. For the flows where UX actually matters — where someone is going to use this every day, or where a customer is going to see it — that 20% gap is worth taking seriously.

The decision isn't complicated: native first, UnofficialSF if it's free and fast, managed package when you're building at scale or the stakes are higher. Most orgs end up using all three at different points.

If you want to see what the managed side looks like, the Avonni Flow Screen Components library has a free AppExchange trial.