arrows-rotateComponent Lifecycle in Flow

How Salesforce Flow Handles Components on Screen

When a user navigates through a Flow, Salesforce doesn't keep all components of every screen alive in the background. Each time the user moves to a new screen or leaves and returns, Salesforce destroys the old screen's components and rebuilds them from scratch.

This is standard Salesforce platform behavior — it applies to all Flow Screen components, not just Avonni.

Understanding this matters because it affects selections, scroll positions, expanded rows, and any other component state not stored in a Flow variable.


What Survives and What Doesn't

When Salesforce rebuilds a screen, two things happen:

  1. Flow variables persist. Anything stored in a Flow output variable (selected record IDs, text inputs, checkbox values) survives the rebuild. The Flow runtime holds these values.

  2. Internal component state is lost. Anything that lives inside the component but isn't mapped to a Flow variable gets reset. This includes scroll position, expanded/collapsed sections, column sort order, and visual selection highlighting.

What persists (Flow variables)
What resets (internal state)

Selected record IDs in an output collection

Visual checkmarks on rows

Text field values

Scroll position

Checkbox/toggle values

Expanded/collapsed row groups

Combobox selected value

Column sort order

Any value mapped to a Flow variable

Hover states, focus, active tabs


When This Becomes a Problem

Visibility rules

The most common scenario where this catches people off guard is conditional visibility. When you set a visibility rule on a component (like "show this Data Table only when a checkbox is checked"), Salesforce destroys the component whenever the condition is false and rebuilds it whenever the condition becomes true again.

If a user selects 5 rows in a Data Table, the table is hidden by a visibility rule and then shown again; the table reloads with zero visual selections—even though the output variable still holds the 5 record IDs.

This is not a bug. The component was destroyed and recreated. It has no memory of its previous state.

Screen navigation

The same thing happens when users navigate away from a screen and come back. The components on the original screen are destroyed. When the user returns, Salesforce rebuilds them. Flow variables are restored, but the visual state is gone.


How to Work Around This

Keep stateful components visible

The simplest fix: don't put conditional visibility on components that hold important state (Data Tables with selections, components with expanded sections, sorted columns). If you need to show/hide content, consider using a separate screen instead of a visibility toggle.

Use output variables for everything that matters

If a piece of state matters to your process, map it to a Flow output variable. Selections? Map the selected IDs to a collection variable. Sort order? Store it in a text variable. This way, even when the component rebuilds, the values are available.

Consider Dynamic Components for persistent UIs

If your use case requires components that stay mounted and never lose state — dashboards, interactive data views, multi-tab layouts — Avonni Dynamic Components are a better fit. Dynamic Components on a Lightning Page don't get destroyed and rebuilt the way Flow Screen components do.

See Dynamic vs. Flow Components for guidance on choosing the right approach.


Common Symptoms of Lifecycle Issues

These are all normal behaviors caused by component lifecycle — not bugs:

  • Data Table checkmarks disappear after navigating away and back, or after a visibility toggle. The selected IDs are still in your Flow variable, but the component was rebuilt without visual selection state.

  • Grouped rows collapse when you return to a screen. The grouping configuration reloads, but the expanded/collapsed state of individual groups isn't persisted.

  • Sort order resets to the default column after screen navigation.

  • Active tab resets in a Tabs component after a visibility toggle.

If you're seeing one of these behaviors, check whether a visibility rule or screen navigation is triggering a rebuild before reporting it as a bug

Last updated

Was this helpful?