Common Implementation Patterns

Once the SDK is installed and initialized (see Getting Started), the next decision is how you drive the onboarding flow. The React Native SDK supports three integration patterns. They differ in two ways: where the flow is defined (in your app code versus on the Incode Dashboard) and how much control your host application keeps while the flow runs.

This page explains each pattern and when to use it. Pick the one that fits your product, then follow its dedicated page for the full walkthrough.

Where flows are defined

The three patterns split into two configuration models:

• Configured locally. You build a flowConfig array in code, adding the modules you want and the order they run in. Patterns 2 and 3 use this model. See Modules for the catalog of modules you can add and their per-module configuration parameters.
• Configured online. The flow is defined on the Incode Dashboard as a Flow or a Workflow. Your code references it by configurationId, so you can change the configuration on the Dashboard without shipping a new app build. Pattern 1 uses this model.

The three patterns

1. Run flows configured online (recommended)

Define the flow on the Incode Dashboard as a Flow or a Workflow, then start it with startFlow(), startFlowFromDeepLink(), or startWorkflow(). The SDK pulls the modules and configuration from the Dashboard, so you do not define a flowConfig locally.

Make sure the Flow or Workflow is active on the Dashboard before starting the session:

• Workflows are automatically active when you click "Save & Publish." If a Workflow is paused, click the three dot menu in the Actions column > Activate Workflow.
• New Flows are saved as inactive by default. You can either click the three dot menu in the Actions column > Activate Flow or open the Flow and toggle Live Flow to activate it.

Active Flows and Workflows can also be paused on the Dashboard, which makes them unusable until they are re-activated.

Use this when you want to change the onboarding flow from Dashboard without releasing a new app version.

Walkthrough: Run Flows Configured Online

2. Configure flows locally and run end to end

Build a flowConfig array in code, then hand the whole flow to the SDK with a single startOnboarding() call. The SDK runs every module in sequence and returns control to your app when the flow finishes.

Use this when you want the simplest integration and the SDK can own the full onboarding experience from start to finish.

Walkthrough: Configure Flows Locally and Run End to End

3. Configure flows locally and run step by step

Build the flow as one or more sections in code and run each section with startOnboardingSection(). Control returns to your host application between sections, so you can insert your own screens or run business logic before starting the next section. The design also allows branching based on intermediate results, though this is not called out as an officially recommended pattern.

Use this when you need to interleave your own UI or logic with the SDK modules, or split a long flow into discrete steps.

Walkthrough: Configure Flows Locally and Run Step by Step

Choosing a pattern

Related pages

• Modules: the module catalog for building a flowConfig.
• Results: the result and error objects returned when a flow finishes.
• API Reference: the full specification of startOnboarding(), startOnboardingSection(), startFlow(), startWorkflow(), and their configuration objects.
• Face Login: authenticate a returning user after onboarding, separate from these onboarding-flow patterns.