Customer onboarding

The job

A customer signs up for a SaaS product. Their account needs an identity record, a tenant, service configuration, and verification before it becomes usable. Staff need to see which customers are ready and which are waiting on something. Completion means an activated account with the required setup confirmed.

This is an application pattern built around durable steps and waits. The application supplies provisioning APIs, verification policy, and the product’s account model. Ironflow coordinates the work between those pieces.

The flow

Signup emits an onboarding request with a stable customer identifier. The run creates a tenant, configures services, and sends the verification request. Independent service setup can run in parallel when its dependencies permit. A durable wait holds for a matching verification event. Once checks pass, the application activates the account and emits a completion event.

A projection can derive a setup checklist for the customer and a queue for staff. Record the domain events you want that view to contain, including requests, successful setup stages, verification, and activation.

The difficult moment

The identity provider succeeds, but a storage provider fails. Restarting the entire signup path risks duplicate identities and confusing partial accounts. Completed durable steps preserve their results, so the run can continue with the unfinished service setup.

A provider can accept a create request just before the worker loses its connection. Use stable idempotency keys or provider-side lookup/reconciliation to handle that uncertain result. Saved step results cover completed work; they cannot close a provider’s acceptance window by themselves.

Ironflow’s role

Durable steps coordinate provisioning and notification. Parallel steps support independent setup. Correlated event waits handle verification without holding a worker. Entity streams can record explicit customer lifecycle events, and projections can derive the current setup state.

Define recovery policy in application code. A temporary outage can be retried; a terminal eligibility failure may require registered compensation to release resources. Cancellation and compensation have distinct behavior, so decide how abandoned accounts are cleaned up. Your access-control and verification services remain responsible for their own checks.

Implementation sketch

This is an illustrative flow:

1. Accept and validate signup using a stable onboarding ID.
2. Provision required services in durable steps with provider idempotency.
3. Record successful setup events for the status view.
4. Send verification and wait for a matching response.
5. Validate activation requirements and activate the account.
6. Handle terminal rejection through explicit cleanup or compensation.

Starting point

• Step primitives provides durable calls, parallel work, sleeps, and correlated event waits.
• Sagas and compensation explains the failure conditions that run registered undo steps.
• Projections shows how to build a status checklist from the onboarding events your application records.