Test accounts and shared data

A rerun should know which account and data it is exercising. Use named generated values and Mailbox inboxes when a journey needs the same identity across plans, applies and partial reruns. Use your application’s fixture or setup command to create the corresponding account.

Choose a setup path

What the journey needs	Where to start
A signup address, email code or magic link	Mailbox plugin.
Your application’s seed or cleanup command	LocalBash or DockerUbuntu.
A database check or explicitly enabled setup write	PostgreSQL plugin.
A repeatable random name, number or expression	Generated values.

Connect the remote mailbox

Mailbox connection settings now live in the Mailbox plugin guide. Keep its run-scoped token in a private binding, and use the address returned by the service rather than assuming a public mail domain.

Receive a code as an ordinary variable

Follow the complete email-code flow. Capture the cursor and trigger the email in the same step, then wait with sender and subject filters. This excludes messages from an earlier attempt.

Export the account address or generated identifier from a producer flow, and reference it through needs in consumers. The producer and consumer example shows the typed declarations and references.

Named generated values and mailbox identities belong to the selected execution group and its current test-data generation. Shared groups agree across devices; device groups remain separate. Selecting another target in the same group keeps its named data. Give a different environment its own group.

Taint retains these identities. A changed generator definition needs a new name or an explicit reset. Expressions follow their inputs; observed application values refresh when their step executes. Use Mailbox names to separate concurrent email journeys.

Start with fresh test data

reflow reset
reflow plan
reflow apply

Reset replaces the selected group’s named mailboxes and generated values. Old addresses stop accepting mail. Plans using the earlier generation must be refreshed; random-generating and plugin-invoking steps and their dependents rerun. Plugin commands receive the generation even when their return value is not captured. Reset preserves execution history and does not delete users, orders or other data in your application.

Use reflow taint <flow> to rerun checks with the same address and generated values. Changed expressions follow their inputs; observed application data is read again when its step executes. A reset refuses an owned group or unresolved unknown execution outcomes: inspect and reconcile those before resetting.

If a reset response is interrupted, repeat reflow reset to reconcile its saved request. The CLI retains the request identity until the result is confirmed. If another device has since reset the group, inspect reflow status --json. To deliberately request another reset, supply both --expected-epoch with the current target.testDataEpoch and --idempotency-key with a new UUID. This replaces the pending request and rotates the current generation again.

Existing browser-run mailboxes

The older browser-run/device-job mailbox path has a separate run-scoped lifecycle. See Mailbox execution paths before mixing those commands with named plan/apply inboxes.

Seeded accounts and third-party authentication

Use your application’s test fixture or idempotent setup flow for an existing account. Keep credentials in the private input/connection mechanism supported by your execution path; remote browser runs can use team environment variables. Browser context isolation does not reset backend data.

Third-party OAuth providers can add bot detection. A first-party email/password, magic-link or OTP path is usually easier to control in a test environment.