With nested flows, you can import a flow inside another flow, creating reusable hierarchies up to 4 levels deep. This article covers common patterns where nesting is the right approach and situations where keeping flows flat is a better choice.
When to nest
Layered flow composition
If multiple tests share a common workflow that’s made up of smaller, reusable parts, nesting lets you compose those parts without duplicating steps.
For example, imagine you have a “Add item to cart” flow and an “Enter payment info” flow, each used in several tests on their own. You can nest both inside a “Complete checkout” flow that captures the full checkout sequence. When the payment form changes, you update the “Enter payment info” flow once, and every test that uses the checkout flow — or the payment flow on its own — gets the change.
This pattern works best when:
- The inner flows are genuinely reusable outside the parent flow
- The parent flow represents a real user workflow, not just a container for grouping steps
Data grid testing
Nested flows can combine loops at multiple levels to iterate through complex data structures like tables and grids.
For example, you can create an outer flow that loops through rows in a table, then nest an inner flow that loops through columns or dropdown values within each row. This approach handles scenarios like:
- Verifying that each row in a results table contains the expected values
- Selecting options from a dropdown in every row of a form
- Parsing and validating data across a multi-column grid
Authentication chains
Applications with layered authentication steps benefit from nested flows where each layer handles one part of the login process.
For example:
- An “MFA verification” flow handles the multi-factor authentication prompt
- A “Login” flow wraps the credential entry and nests the “MFA verification” flow
- A “Session setup” flow nests the “Login” flow and adds session configuration steps
Each layer is independently maintainable. If your MFA provider changes, you update the “MFA verification” flow without touching the login or session setup logic. Teams that support multiple login methods can swap or reconfigure individual layers without rebuilding the entire chain.
Conditional logic with repetition
Use nested flows inside conditional steps to create branching workflows that repeat across tests without duplicating the branch logic.
For example, a login flow can contain a conditional step that checks whether a user is an admin or a standard user. Each scenario in the flow contains a nested flow with role-specific actions. The conditional structure and nested flows are reusable together, so you don’t need to rebuild the branching logic in every test that handles role-based behavior.
When not to nest
Nesting is powerful, but it adds complexity. A failure three levels deep is harder to trace than a failure in a flat flow. Before nesting, consider the following:
Is the inner flow reusable on its own? If a flow only exists inside one parent flow and you don’t plan to use it anywhere else, those steps may belong in the parent flow directly. Nesting is most valuable when the inner flow has a life of its own.
Are you nesting for organization or for reuse? If your goal is to group related steps for readability, step groups are a lighter-weight option. Step groups provide collapsible labels without the overhead of versioning and parameter management that comes with flows.
Are you approaching the depth limit? Flows and step groups share a 4-level nesting depth limit. If you’re already at 3 levels and considering another, take a step back. Deep nesting can signal that a test is doing too much. Consider splitting the test into multiple tests that each focus on a specific scenario.