For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

Flow Screen Components
Dynamic Components

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

In Flow Builder: the component is added to a flow screen from the palette, and that screen is one step of the process.
In the Dynamic Component Builder: the component is designed once, then placed on any Lightning page.

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.

  1. Build the page layout with Dynamic Components

  2. Trigger the flow from it, with the Open Flow Dialog or Open Flow Panel interaction

  3. Build the guided process with Flow Screen Components

Pages load fast, layouts stay reusable, and guided processes stay guided.

Last updated

Was this helpful?