SPEC-PWF-ONB · v0.1
14 June 2026
Owner: Platform team

Onboarding

How an organization comes onto the platform, and how a live tenant grows. This is the manual for the onboarding sub-hierarchy: a customer front door and a partner front door — the same spine with two different gates — plus the capability change that lets one tenant gain a second role later. Read this overview first, then open the journey you need.

1The three journeys

One process per document, so no page carries the whole of onboarding. The customer and partner front doors each turn a sign-up or a provisioning action into a live, verified organization; capability & enrollment is the after — a live tenant gaining a second role on the same organization.

2One spine, two gates

The customer and partner front doors share a spine — choose an identity, become the tenant's fixed-full Owner, verify email, set up the organization — and differ in exactly one place: the gate that grants full access. A customer passes a light RiverSync legitimacy check; a partner's basic account goes live the moment email is verified, but the partner program (the Partners app and a channel subtype) waits on a formal RiverSync approval.

Where the journeys diverge — the partner-specific steps a customer never sees:

Dimension	Customer front door	Partner front door
Entry surface	Self sign-up at account.riversync.com, or Admin-provisioned off a won deal	Application at partner.riversync.com, or Admin-provisioned
Proof of legitimacy	Light check — domain match, no abuse	Business registration & tax ID submitted with the application
Gate to full access	RiverSync legitimacy check (TEN-4 ⚠); org held in a limited state until it clears	RiverSync program approval (PAR-7 ⚠) — distinct from account activation
When the account goes live	Org fully live once the check clears	Basic account live at email-verify; Partners app stays gated until approval
Channel subtype	—	Distributor or reseller, RiverSync-set on approval — never self-selected (PRT-9)
Surfaces touched	Account · Admin	Partners · Admin · Account

3The customer front door

Two entry forms that converge on the same outcome — owner self-sign-up, or an Admin-provisioned invite off a won deal — rejoining at email verification, then the legitimacy check. Full detail and the step table are in the customer onboarding drill-down (SPEC-PWF-CON).

4The partner front door

The same spine, with the program-approval branch as the partner-specific gate: the basic account activates at email-verify while RiverSync reviews the application and — on approval — assigns the channel subtype. Full detail is in the partner onboarding drill-down (SPEC-PWF-PON).

5After onboarding — gaining a second capability

Onboarding does not end at "live". A live tenant can gain a second role on the same organization — one org, one sign-in — never a second tenant (TEN-2, the Nera model). The two directions are symmetric: a customer upgrading to a partner runs the very same approval and subtype gate as the partner front door; a partner enrolling for customer features is self-serve, because the tenant is already verified. Full detail is in capability & enrollment (SPEC-PWF-ENR).

6Rules in play

The WF-rules that bind the onboarding journeys — the master holds the full set; the DM-rules (ERD) and SVC-rules (Domain) they extend stay with those documents.

7Traceability & open questions

What each journey realizes and the events it rides; no step stands without evidence (WF-2). The ⚠ gaps are the same the master ERD and PRD carry — onboarding surfaces them as lived process pain, it does not close them.

Journey	Realizes	Rides events
Customer onboarding	TEN-1 · TEN-4 ⚠ · ID-3 · ACC-1 · ACC-5 · ADM-1 · ADM-2	tenant.self-registered · tenant.provisioned · user.invited · user.email-verified
Partner onboarding	TEN-1 · PAR-7 ⚠ · PRT-9 · FED-8 ⚠ · AUTH-2 · ACC-5	tenant.self-registered · tenant.provisioned · user.email-verified · partner.approved
Capability & enrollment	TEN-2 · TEN-5 ⚠ · PAR-7 ⚠ · PRT-9 · PTL-1	partner.approved · tenant.capability-enabled

• ⚠ TEN-4 / PAR-7 / TEN-5 / FED-8 — owner-led onboarding is not yet in the model. Self-registration (TEN-4), partner self-application & program approval (PAR-7), post-onboarding capability change on the same tenant (TEN-5) and an explicit partner Owner role (FED-8) are proposed requirements that do not yet exist in the master PRD. To be added with traceability rows and ERD entities in the next cascade; until then the steps that need them are flagged, not silent.
• ⚠ ACC-5 — the email-verification gate spans all apps. The read-lock until EmailConfirmed is asserted for every org surface, not just Account; confirm scope in ACC-5 and the claims layer (SVC-12).
• ⚠ ACC-6 — no notifications consumer. Owner invite and verification emails ride the unbuilt notifications capability; each step marks the gap rather than inventing a channel.

8Revision history

Version	Date	Changes
0.1	14 Jun 2026	First draft — onboarding becomes a sub-hierarchy of the workflow set (SPEC-PWF-ONB). This overview/manual joins the three journeys — customer (SPEC-PWF-CON), partner (SPEC-PWF-PON) and capability & enrollment (SPEC-PWF-ENR) — now grouped under workflow/onboard/. No change to the journeys themselves; the doc-nav gains group support and renders the group inline.