Skip to content

Generated SaaS Workflows

Target Architecture — Final-State Design

This page describes the common runtime workflows of a Generated SaaS Product, centered on tenant provisioning and onboarding. Workflows are coordinated as MassTransit sagas/state machines over the canonical event envelope, with each step idempotent and compensatable. Products add domain-specific workflows; the onboarding flow below is universal.

The most important generated workflow is tenant onboarding — turning a sign-up into a fully provisioned, billable, ready-to-use tenant. It exercises the SaaS spine end to end: tenancy, identity, subscriptions, configuration, notifications, and audit. The flow is orchestrated, observable by traceId, and resilient to partial failure through compensation.

Tenant provisioning & onboarding sequence

sequenceDiagram
    participant Admin as Signup / Admin Portal
    participant GW as API Gateway
    participant Tenant as Tenant Management
    participant Bus as Service Bus
    participant Sub as Subscription & Billing
    participant Identity as Identity Service
    participant Config as Configuration Service
    participant Notif as Notification Service
    participant Audit as Audit Trail

    Admin->>GW: POST /tenants (RegisterTenant)
    GW->>Tenant: RegisterTenant (tenant-scoped)
    Tenant->>Tenant: create Tenant (Provisioning)
    Tenant->>Bus: TenantRegistered
    Bus->>Audit: AuditEntryRecorded
    Bus->>Sub: TenantRegistered
    Sub->>Sub: create Subscription (Trial/Active)
    Sub->>Bus: SubscriptionActivated
    Bus->>Config: SubscriptionActivated
    Config->>Config: apply edition entitlements + default flags
    Bus->>Identity: TenantRegistered
    Identity->>Identity: create owner User (Invited)
    Identity->>Bus: UserInvited
    Bus->>Notif: UserInvited
    Notif->>Notif: send activation email
    Notif->>Bus: NotificationSent
    Sub-->>Tenant: provisioning step complete
    Config-->>Tenant: provisioning step complete
    Identity-->>Tenant: provisioning step complete
    Tenant->>Tenant: all steps complete -> Active
    Tenant->>Bus: TenantProvisioned
    Bus->>Audit: AuditEntryRecorded
Hold "Alt" / "Option" to enable pan & zoom

Tenant onboarding state machine

stateDiagram-v2
    [*] --> Registered
    Registered --> Provisioning : begin provisioning steps
    Provisioning --> Provisioning : step completed
    Provisioning --> Active : all steps succeeded
    Provisioning --> ProvisioningFailed : a step failed
    ProvisioningFailed --> Provisioning : retry after remediation
    ProvisioningFailed --> Decommissioned : abandon + compensate
    Active --> Suspended : payment past due / policy
    Suspended --> Active : reinstated
    Active --> Decommissioned : tenant closed
    Suspended --> Decommissioned : tenant closed
    Decommissioned --> [*]
Hold "Alt" / "Option" to enable pan & zoom

Failure handling

  • Saga orchestration. Tenant provisioning is a MassTransit saga: the Tenant aggregate tracks ProvisioningSteps, and the saga only transitions to Active once every step publishes success.
  • Idempotency. Each step consumer deduplicates on eventId, so redelivery never double-provisions (e.g. a second SubscriptionActivated is ignored).
  • Compensation. If a step fails irrecoverably, the saga issues compensating actions (e.g. cancel the half-created subscription, disable the invited user) and moves the tenant to ProvisioningFailed.
  • Bounded retry + DLQ. Transient failures retry with backoff; exhausted messages dead-letter with the full envelope for operator replay.
  • Timeouts. A provisioning timeout transitions the saga to ProvisioningFailed and emits a TenantProvisioningTimedOut event for alerting.
  • Audit on every transition. Each state change emits AuditEntryRecorded, so the onboarding history is reconstructable and compliant.

Implementation Notes

Because all steps are enveloped events correlated by correlationId, the entire onboarding flow for a given tenant can be visualized end to end in the product's observability dashboards and traced back through the factory's Observability & Feedback platform.

How workflows contribute to the pillars

  • Traceability — correlationId ties every step of onboarding into one reconstructable flow; causationId builds the causal chain.
  • Reusability — the onboarding saga is generated from the same template across products; only domain steps differ.
  • Autonomy — the saga and its compensations are generated from the blueprint workflow definition.
  • Governance — every transition is audited; suspension and decommission encode policy.
  • Observability — saga state and step durations are emitted as metrics and traces.
  • Multi-tenant scale — each tenant's onboarding is an isolated saga instance; thousands run concurrently without interference.