Skip to main content
FlowPilot has a few moving parts. This page explains what each one does, then traces the path a flow takes from the moment you design it to the moment a user sees it on their phone.

​
The parts of the platform

There are three pieces you work with:
  • Dashboard and Flow Editor (web): where you design flows, manage placements, and run experiments. This is where flow builders spend their time.
  • Backend (hosted by FlowPilot): stores your flows, decides which flow to serve for a given placement and user, and ingests analytics events. You rarely call it directly.
  • iOS SDK (Swift): you add this to your app. It asks the backend what to show, then renders the flow natively on device.
You design in the dashboard, the backend stores and serves, and the SDK renders. You do not write rendering code for each flow. The SDK draws whatever the editor produced, using native views (no web view).

​
The data model

Everything in FlowPilot is scoped like this: 
workspace -> app -> flow / placement / experiment
  • Workspace: your organization. One workspace maps to one Clerk organization.
  • App: one platform target inside a workspace, for example your iOS app. An app owns its own flows, placements, and experiments. Each app has an App ID the SDK needs at launch.
  • Flow: an ordered set of screens plus logic. A flow has versions. You publish a version to make it servable.
  • Placement: a named trigger point in your app, for example onboarding. Your app asks the SDK about a placement, and the backend decides which flow, if any, to return.
  • Experiment: an A/B test attached to a placement. It splits traffic across variants, each pointing at a different flow version.
See Core concepts for the full vocabulary.

​
The lifecycle of a flow

1

Build in the editor

Design the screens and logic in the Flow Editor.
2

Publish a version

Publishing freezes the current design as a numbered version. A draft is never served.
3

Attach to a placement

Point a placement at the published version. Optionally put the placement behind an experiment so different users get different versions.
4

App asks the SDK

Your app calls the SDK with the placement key, for example onboarding.
5

The backend resolves the flow

The SDK sends a resolve request. The backend applies audience targeting and any experiment assignment, then returns the matching flow (or nothing).
6

The SDK renders natively

The SDK draws the flow on device using native views.
7

Interactions emit events

As the user moves through the flow, the SDK sends analytics events (screen views, completions, conversions) back to the backend.

​
Diagram

​
Flows update over the air

Because the SDK fetches flows at runtime, republishing a flow changes what users see without an App Store release. Edit the copy on a screen, publish, and the next resolve serves the new version.
Over-the-air updates are subject to caching. The SDK caches resolved flows (5 minutes in production by default), so a change can take a short while to reach every device. See Caching for the details and how to tune it.