Project setup

Set up your Data Twin

Verified against Soffi ·

Your Data Twin stands in for your app's backend in Soffi, so every screen renders with realistic data and, by default, previews don't touch your real services or production data. Each Project has one Data Twin. Its baseline is set up once, with the Project, and every Workspace builds on top of it.

Turn it on

The Data Twin switch sits beside your repository picks when you create a project, and it's on by default. Leave it on if your app talks to a backend. Turn it off when the app needs no backend at all, or when you'd rather run against a real backend whose repository you've included in the Project.

What Soffi builds

While it sets the app up, Soffi reads your repositories to learn which endpoints the app calls and what the responses look like, then builds the Data Twin's endpoints and fills them with realistic data. In the Data Twin, endpoints are data: adding a response to it is enough to add an endpoint, which keeps the Data Twin easy for Soffi to extend later.

The readiness check

Before the Data Twin becomes the Project's baseline, Soffi checks that it actually carries the app. It opens the app's main routes, signed in, and judges each one by what it shows:

ResultMeaning
Realistic dataThe page renders with data that looks real.
No realistic dataThe page renders, but empty or stuck on its loading state.
Renders an errorThe page shows an error.
Bounced to sign-inThe page sent the user to sign in.
Not assessed yetThe route hasn't been judged.

The check passes when enough of those routes show realistic data (80% by default) and none bounce to sign-in. Setting the app up isn't finished until it passes, and a passing check is what makes the Data Twin the baseline.

You can see the result on the Project's Overview, in the Data Twin's baseline card: the current baseline, the share of main routes with data against what's needed, and the routes that fell short. Admins can run the check again with Check readiness.

How Workspaces add to it

Each Workspace gets its own copy of the Data Twin on top of the baseline. When someone needs a state the baseline doesn't have, like an empty list, a failed payment, or a new endpoint for the feature they're building, they tell Soffi in their Workspace and she adds the endpoint or data there. Nobody else's preview changes.

Today that's how the Data Twin is edited: through Soffi, in a Workspace. The Data Twin's tab under Configure shows whether the Project has one.

In a Workspace, the Verify panel shows how the Data Twin holds up against the app's API contract and its test suites, including any responses it had to invent.

When a pull request merges

When a Workspace's pull request merges into the Project's base branch, Soffi merges that Workspace's Data Twin additions back into the baseline. It deploys the result, runs the same readiness check, and only promotes it if no route that had data before has lost it. Workspaces already running keep the baseline they started from.

The baseline card lists each merge and where it got to. Conflicts are never resolved automatically: a merge that conflicts stops at Needs reconcile with the conflicting files listed, and the baseline stays as it was. Admins can try again with Retry merge.

Was this helpful?