Flow vs. Dynamic Components
Short answer: if you are building inside Flow Builder, use Flow Screen Components. If you are building on a Lightning page, use Dynamic Components.
Avonni ships four component lines across three managed packages, so if Experience sites or your own LWC code are also in scope, the Selection Guide is the full picture. This page answers the one question it does not: what happens when a flow screen is asked to do a Lightning page's job.
The line between them
You build in
Flow Builder
Lightning App Builder
The user gets
a step in a process
a page that is always there
Best at
wizards, intake forms, approvals
dashboards, record views, data heavy layouts
Ships in
Avonni Flow Screen Components
Avonni Experience Components


Flow screens are for guided paths
Reach for Flow Screen Components when your users are following a defined path:
Multi-step wizards (case intake, employee onboarding, quote generation)
Approval workflows with user input at specific stages
Guided data entry where the next screen depends on previous answers
Quick actions that collect a few fields and run automation
Rule of thumb
If your screen has no "Next" button and nobody is moving through steps, you are building a page, not a process. Build it with Dynamic Components.
The mistake worth avoiding
The most frequent one we see is using Flow Screen Components as the layout engine for a full application page: a dashboard, a multi-tab record view, a data heavy layout. Flow screens were not designed for that, and three things follow.
Performance. Every component on a flow screen loads inside the Salesforce Flow runtime, and the flow's own complexity is part of what the screen has to wait for. The Performance Guide has the detail and the settings that help.
Reach. A Dynamic Component is built once and dropped on any page, where it reacts to the rest of that page natively. A flow screen only exists while its flow is running, and its layout belongs to that flow.
Effort. Page layout work is real work, and it has to be done a second time on the other side the day the page outgrows the flow.
Use both
Most orgs install both packages. They coexist with no conflict, and each ships its own Component Builder, so what you learn configuring one carries over to the other.
Build the page layout with Dynamic Components
Trigger the flow from it, with the Open Flow Dialog or Open Flow Panel interaction
Build the guided process with Flow Screen Components
Pages load fast, layouts stay reusable, and guided processes stay guided.
Last updated
Was this helpful?
