The One Question That Decides Everything

We hear the same question from admins every week: "I already use Avonni in my Flows. Why would I need Dynamic Components too?"

Or the reverse: "Can't I just embed a Screen Flow on my record page and build everything there?"

The answer is simpler than you think. It comes down to one question: Where are you building?

⚡ Building on a Lightning page (record page, app page, home page)?
→ Use Dynamic Components

🌊 Building inside a Flow (guided steps, wizards, data entry)?
→ Use Flow Screen Components

That's it. That's the whole decision.

Both tools are powerful. Both are no-code. But they're designed for fundamentally different places in Salesforce, and using one where the other belongs leads to workarounds, performance issues, and maintenance headaches. Let's break it down.

What Each Tool Is Built For

⚡ Dynamic Components — Always On, Always Reactive

Where you build: Avonni Component Builder → Lightning App Builder
Where it lives: Record pages, app pages, home pages

Dynamic Components are what your users see the moment they land on a Salesforce page. They don't need to click a button or enter a Flow — the data is just there.

A custom Account page with pipeline charts next to key metrics. An interactive data table replacing the default related list. A Kanban board showing active tasks. All of it loads instantly, updates reactively when data changes, and never asks the user to "start" anything.

Under the hood, Dynamic Components have their own formula engine, their own query builder, their own interaction system, and full layout control. Build once, reuse across as many pages as you need.

Best for: Custom record pages, dashboards, interactive data tables, charts & metrics, redesigned related lists, always-visible UI.

🌊 Flow Screen Components — Guided, Step-by-Step Logic

Where you build: Flow Builder
Where it lives: Inside a Flow runtime

Flow Screen Components live inside Flow Builder. Their purpose is to make Flow screens look and behave better — richer inputs, better visual pickers, progress indicators, data tables for collecting user selections.

The power here is integration with Flow logic: every component binds to Flow variables, feeds into Flow decisions, and lets Flow Builder handle what happens next.

This is the tool for processes that have a beginning, middle, and end. A new-hire onboarding wizard. A multi-step case intake form. A bulk data entry screen where users select records, make changes, and confirm before saving.

Best for: Multi-step wizards, data entry forms, approval processes, guided intake, conditional steps, backend automation.

The Mistake We See Everywhere

Here's the pattern we see over and over: an admin needs a custom UI on a record page — say, a mission control dashboard, a redesigned related list, or a data visualization panel. They already know Flow Builder well and they already have Avonni's Flow Screen Components installed.

So they build it as a Screen Flow, drag all the components onto a single screen, and embed that Flow on the Lightning page.

It works. But it shouldn't be built that way.

Flow Builder is a process automation tool. It's designed to move users through steps, handle branching logic, and write data. When you use it as a page layout engine — embedding a single-screen Flow just to display a custom UI — you're working against its intended architecture.

Here's what happens in practice:

1. Performance overhead. The Flow runtime loads on top of the Lightning page. That means extra processing, extra loading time, and a heavier page — especially on record pages that already have other components.

2. No native reactivity. Dynamic Components update when data changes, automatically. A Screen Flow embedded on a page doesn't — it shows what it loaded and stays static unless the user refreshes or re-enters the Flow.

3. Layout constraints. Flow screens give you one column. Dynamic Components give you full layout control — grids, columns, tabs, panels, responsive breakpoints, and the ability to compose multiple components in any arrangement.

4. No reusability. A Screen Flow is tied to that specific Flow. A Dynamic Component can be activated once and dropped onto any Lightning page across your org — Account, Contact, Opportunity, custom objects, home pages.

The distinction is architectural, not cosmetic. If the user doesn't need to go through steps, doesn't need Flow logic to run in the background, and just needs a better-looking, more interactive page — that's exactly what Dynamic Components are for.

A Simple Way to Think About It

Flow Screen Components = the engine that powers a guided process (data entry, wizards, approvals).

Dynamic Components = the dashboard and layout system that powers what users see and interact with on a page (record views, data displays, custom layouts, actions).

They do fundamentally different jobs. Using one for the other is like using a spreadsheet to write a report — technically possible, but not what the tool was made for.

Signs You're Using the Wrong Tool

If any of the following feel familiar, you're likely using a Screen Flow where a Dynamic Component would serve you better:

• Your Flow has only one screen. If there's no "Next" button, no branching logic, and no multi-step process — it's not really a Flow. It's a page layout pretending to be a Flow.
• You embedded it on a record page just to display data. If the primary goal is to show information (not collect it), Dynamic Components are purpose-built for this.
• Users don't interact with it step-by-step. If users land on the page and everything should just be there — metrics, tables, charts, buttons — that's a page component, not a process.
• You're fighting the layout. If you're using workarounds to get columns, tabs, or custom spacing inside a Flow screen, you're fighting Flow's single-column design. Dynamic Components give you all that natively.
• It doesn't update in real time. If users have to refresh the page to see updated data, the embedded Flow isn't reactive. Dynamic Components query data and update automatically.
• You want to reuse it on other pages. Screen Flows are one-off. Dynamic Components are build-once, deploy-anywhere.

Side-by-Side Comparison

Here's a detailed look at how the two tools compare across every dimension that matters. This isn't about which one is "better" — it's about which one is right for your specific use case.

Real Scenarios, Clear Answers

Still not sure? Here are the use cases we see most often, with a clear recommendation for each.

"I want to redesign the related lists on my Account record page"

→ ⚡ Use Dynamic Components. This is a page layout improvement. The data should be always visible, reactive, and part of the standard record page. Build a Data Table with search, filters, conditional formatting, and row actions.

"I need a 5-step wizard for onboarding new clients"

→ 🌊 Use Flow Screen Components. This is a guided process with sequential steps, conditional logic, data creation, and approvals. Flow Builder manages the orchestration; Avonni components make each step look great.

"I want a mission control dashboard on a record page"

→ ⚡ Use Dynamic Components. Compose metrics, charts, data tables, and timelines into a custom layout with reactive data. Everything loads with the page. No Flow needed.

"I need a bulk data editing screen where users select, edit, and save records"

→ 🌊 Use Flow Screen Components. The key words are "confirm and save." This is a data entry process with a write operation at the end that Flow handles.

"I want a custom page with charts and a Kanban, plus the ability to launch processes from buttons"

→ ✨ Use Both Together. Build the page with Dynamic Components. Use interactions to launch Screen Flows when users need to take action. Best of both worlds.

The Power Move: Use Them Together

The two tools aren't competing — they're complementary. Here's the pattern our power users follow:

1. Custom Record Page — Dynamic Component shows metrics, tables, and charts on the Lightning page
2. User Takes Action — Clicks a button, row action, or card — triggers "Open Flow Dialog" interaction
3. Flow Dialog Opens — Screen Flow with rich inputs handles data entry and backend logic
4. Page Auto-Updates — Dialog closes. Dynamic Component refreshes automatically with new data

For example: a custom Opportunity page with a pipeline chart, key metrics, and an interactive data table. When a user clicks "Log Activity" on the table, a Flow dialog opens with rich inputs and a date picker. When they save, the dialog closes and the Dynamic Component refreshes automatically.

Dynamic Components for the view. Flow Screen Components for the action.

Both packages coexist in the same org. Installing one never affects the other.

Quick Decision Guide

Ask yourself these four questions:

1. Am I building on a Lightning page or inside a Flow?
Lightning page → Dynamic Components
Inside a Flow → Flow Screen Components

2. Does the user need to go through steps?
Yes, sequential steps → Flow Screen Components
No, everything at once → Dynamic Components

3. Is the primary goal to display data or to collect/process it?
Display & interact → Dynamic Components
Collect & process → Flow Screen Components

4. Do I need a custom page layout AND a guided process?
Yes, both → Use them together

The Bottom Line

You don't have to choose one forever. Most Avonni power users install both packages:

Dynamic Components to build what users see on a page.
Flow Screen Components to build what users do inside a guided process.

Together, they cover every no-code use case in Salesforce.

Ready to build with the right tool? Both packages install in minutes — free to install, and they coexist in the same org.

Install Dynamic Components →

Install Flow Screen Components →

Read the full Selection Guide →