Define the customer's first working day
Enterprise onboarding is complete when the customer's administrator can bring the intended people into the right workspace, give them the right access and remove that access when their responsibilities change. A successful SSO login is one step in that workflow. It does not establish that provisioning, group changes or employee departure work correctly.
Start a delivery discussion with the customer's operating task: "Our administrator can connect the identity provider, assign a pilot group and verify who can access this workspace." Then add the less comfortable task: "The administrator can disable a pilot user and demonstrate what happens to existing sessions and personal credentials." Those two statements expose dependencies that a feature list hides.
The acceptance brief in this article is a proposed planning artifact for a B2B SaaS product. It is not a claim about an existing Dreamtsoft capability or a completed customer implementation. Use it to agree scope among product, engineering, the customer's identity administrator and the people who will support the rollout.
Follow the user through identity changes
Single sign-on establishes an authentication path. Provisioning creates and updates application accounts or memberships. Authorization determines what a person may do after authentication. Session management controls how already established access continues or ends. The product has to connect these responsibilities without pretending that enabling one protocol completes the lifecycle.
| Customer event | Product decision to settle | Acceptance evidence |
|---|---|---|
| First administrator connects an identity provider | Who may establish the tenant's identity connection? | An authorized admin can configure and verify only their workspace |
| An assigned employee signs in | How is the external identity bound to an application identity? | The intended membership is created or matched without joining another tenant |
| The same email appears in another organization | Is identity keyed by a stable provider subject and connection? | The existing account is not silently reassigned by an email match |
| A group changes | Which group-to-role mappings are supported? | The effective permission change matches the agreed mapping |
| An employee leaves | What happens to membership, sessions and personal credentials? | Each access path follows the defined revocation behavior |
| The identity connection breaks | How does an authorized administrator regain control? | A documented, audited recovery path works under the agreed safeguards |
The SCIM core schema defines active as a user's administrative status and leaves its precise meaning to the service provider. That makes the application's behavior an acceptance question. A provisioning update alone does not tell a buyer what happens to an already issued application session, a personal API token or work queued under that user's identity.
Document the revocation point for each path. For an interactive session, decide where the application checks current membership and how server-side session invalidation occurs. For a personal credential, decide whether deactivation revokes it or disables its effective permissions. For a long-running export, decide whether a disabled user can still retrieve the completed file. OWASP's session guidance describes the need for server-side invalidation when a session ends. The integration still has to connect the provisioning event to that behavior.
Do not equate a user's removal from one customer workspace with deletion of that person's identity everywhere. A consultant may belong to several customer organizations. Conversely, a service account may belong to the organization rather than the employee who configured it. Put the ownership rule into the brief before implementing the departure flow.
Roll out identity enforcement in controlled stages
Begin with a pilot workspace or an explicitly selected pilot group. Verify the identity connection, account matching and default permissions before requiring the new login path for everyone. Existing invitations and users who already have a password-based account need a migration decision. An automatic merge based only on an unverified email can bind the wrong identity.
The pilot must include a failed path. Use an unassigned user, an expired invitation or a disabled membership to confirm that the application denies access and gives the administrator enough information to diagnose the issue without exposing another customer's data. Then rehearse the support procedure for a broken configuration.
Define who can switch enforcement on, who can reverse a faulty configuration and which actions require a second person or additional verification. The exact safeguards depend on the product's access model. A recovery path that silently lets ordinary users bypass enforced SSO defeats the control it is supposed to support.
Ask the customer to review the administrator experience during the pilot. Can they tell whether an account is unassigned, disabled or mapped to an unsupported role? Can they see the last successful provisioning event and a safe error explanation? A support team that needs unrestricted database access to answer every onboarding question becomes a permanent dependency in the workflow.
Replace feature labels with reviewable acceptance rows
Download the enterprise onboarding acceptance brief and its review table. The files describe proposed checks, owners and evidence to collect. Their presence does not mean a product has passed those checks.
Each row needs a trigger, an observable outcome, an owner and a place to record evidence. Add the supported identity-provider configuration and the product version when the check is executed. If a requirement has no agreed outcome, mark it unresolved instead of treating a screenshot of a settings page as acceptance.
| Feature label from a request | Acceptance statement to agree |
|---|---|
| SSO | A permitted pilot user reaches only the intended workspace through the configured connection |
| SCIM provisioning | Repeated account updates converge on the same membership and expose a diagnosable failure state |
| Role mapping | A supported group change produces the agreed permissions, including removal of obsolete grants |
| Audit logs | The authorized reviewer can find who changed the connection, what changed and the outcome |
| Administrator recovery | The designated operator can restore configuration under recorded verification and approval rules |
| Offboarding | Disabled membership, active sessions, personal credentials and pending results follow explicit access rules |
The brief separates acceptance ownership from implementation ownership. Engineering may implement a role mapping, while the customer's administrator confirms that its organizational group names have the intended meaning. Product owns the user-visible promise. Support owns the operating instructions it will need after the implementation team leaves.
Avoid one percentage that compresses the whole brief into "enterprise readiness." A missing recovery path and an unfinished optional group mapping are different release decisions. Record the consequence of each unresolved row and the person who can accept or reject that limitation.
Hand over an operating capability
When enterprise onboarding is part of a wider platform build, scope identity alongside tenant isolation, administration and operational visibility. Pharos Production's SaaS development services for SSO, SCIM and tenant onboarding describe custom SaaS work spanning these areas, including enterprise access controls and customer onboarding flows. Use the acceptance brief to ask which parts of the identity lifecycle and administrative handoff the engagement actually includes.
An implementation handoff should leave the operating team with the supported connection settings, role-mapping rules, troubleshooting procedure and evidence from the agreed checks. Keep credentials in the approved secret-management process rather than in the handoff document. Identify who maintains the integration when an identity provider changes behavior or the application adds a new permission.
The SaaS permission-matrix walkthrough can help turn role requirements into explicit access decisions. It addresses the authorization portion of this brief. Onboarding also needs an agreed account lifecycle, an administrator workflow and an observable support boundary.
Release when the owners can demonstrate the required paths and explain the remaining limitations. Do not attach a launch date to an undefined promise such as "SCIM support" and expect the meaning to become clearer during implementation. The next concrete step is to fill the brief with the pilot customer's actual connection, groups and acceptance evidence.
Sources
Documentation checked .