Outbound Platform SSO: Test Provisioning and Access Removal Separately From Login

Evaluate SSO, provisioning, role assignment, and access removal as separate controls. Successful single sign-on establishes an authentication path. It does not, by itself, establish how workspace membership is created, which role a new user receives, or how existing access is removed when someone leaves.

For an outbound platform, those distinctions affect shared CRM connections, prospect data, sequences, mailboxes, and scheduled work. A vendor's identity-provider logo is a starting point for evaluation, not evidence that the entire joiner-and-leaver process is automated.

This guide provides a proposed identity-lifecycle review and a blank acceptance matrix. It uses current Unify documentation as one concrete reference without inferring SCIM, just-in-time provisioning, or a session-revocation guarantee from SSO support.

Define four separate identity operations

Write the required process before reviewing the vendor's feature list. Name who authenticates the user, who creates membership, who assigns a role, and who removes application access. Those responsibilities may sit with different administrators or systems.

Use these as acceptance requirements, not a claim that every vendor exposes four settings with these exact names. The implementation can differ while still satisfying the business need, provided the responsibilities and demonstrated effects are clear.

Do not merge authentication and authorization into a single “SSO passed” result. A user can authenticate successfully and still enter the wrong workspace, receive the wrong role, or retain access that the organization intended to remove.

Establish the supported SSO configuration

Unify's Sign-in and SSO guide describes email and password, Google sign-in, and enterprise SSO. Enterprise SSO is a paid add-on available upon request; the account team coordinates setup and confirms pricing.

The documentation names enterprise connections including Okta, Microsoft Entra ID, SAML, and OpenID Connect. Setup requirements depend on the provider. Confirm the exact provider and configuration for your organization rather than assuming every identity flow behaves identically.

Record the workspace, sign-in domains, identity administrator, and current membership email addresses. Email mismatches can prevent the intended user from reaching the correct membership. Resolving that mismatch is different from creating a second account and hoping it inherits the right permissions.

Ask what sign-in methods remain available before and after enforcement. The Unify guide says that once SSO is enforced, workspace members use that identity provider to sign in. It also directs customers to coordinate changes to an enforced connection, provider, or sign-in domains with Unify.

The review should establish the documented configuration and the controlled result, not a broader promise that an identity-provider integration automatically governs all application access.

Verify sign-in before enforcement

Use an approved test identity or authorized member to confirm that the configured SSO path reaches the intended workspace. Record the identity-provider account, application membership email, workspace, and resulting role.

Do not enforce a new sign-in requirement across the team before resolving mismatches and confirming the intended path. Unify's documentation explicitly calls for testing the connection before enforcement. Coordinate the change with the identity administrator and the vendor account team.

Ask the vendor to explain the supported recovery process for a configuration error. Record who can request help and which evidence is needed. Do not assume an undocumented bypass or break-glass method exists simply because it would be convenient.

A successful authentication check is a bounded result. It says that this identity reached this workspace under this configuration at the recorded time. It does not establish membership automation, role synchronization, or removal behavior.

Keep the evidence appropriate to the review. An identity or workspace identifier and the observed result are usually more useful than copying sensitive authentication material. Do not store secrets, certificates, or tokens in a procurement worksheet.

Inspect how membership is created

Unify's Members and roles guide describes administrator invitations and access-request approval. Administrators select Admin or Non-Admin, review any seat charges, and invite teammates. Invitees remain pending until onboarding is complete.

The cited SSO guide tells customers to continue managing membership and roles through those controls after SSO setup. That is evidence of separate application membership responsibilities. It should not be rewritten as a promise of automatic identity-provider provisioning.

If your requirement is automated provisioning, ask specifically about the supported mechanism, plan, provider, attribute mappings, and failure behavior. SCIM and just-in-time creation are distinct mechanisms; neither follows automatically from support for SAML or OpenID Connect.

Determine whether assigning someone to the identity-provider application creates membership, merely permits authentication, or requires an additional administrator action. Ask the vendor to demonstrate the exact joiner path in an approved environment. If it remains undocumented or untested, record it as unresolved.

Review seat and billing implications separately from access. An invitation or reactivation may require a seat purchase. The operational team should know which step grants access and which step incurs a charge, rather than treating both as an invisible consequence of SSO.

Verify role assignment and subsequent changes

Record the intended initial role and who controls it. In Unify, Admin includes management of members, workspace settings, billing, shared integrations, and plays, alongside everyday work. Non-Admin covers everyday activities such as companies, people, lists, audiences, sequences, research agents, and personal connections.

The role is not the entire permission model. The documentation also points to record sharing, engagement policies, and connected CRM permissions. Evaluate these layers where they affect the required access, without treating the identity-lifecycle article as a complete data-security assessment.

For example, list sharing controls who can view or edit a list, while engagement policies govern account claiming and outreach. A Non-Admin label does not by itself answer every question about which records the rep can see or contact.

Ask whether role changes are manual, provider-driven, or supported through another documented process. If a vendor demonstrates a group-to-role mapping, record its scope and configuration. Do not generalize it to every plan or identity provider without evidence.

Review what happens when a user changes teams. The expected outcome may involve a role, list access, an engagement policy, or several controls. The test should identify each required change and its owner rather than assuming the sign-in system performs all of them.

Separate identity-provider removal from workspace removal

Ask what action removes the user's application membership and what action blocks authentication at the identity provider. They may be coordinated, but the buyer should establish both effects rather than infer one from the other.

Unify documents removal through Settings → Users, where an administrator confirms the member's name and email. Removing a user revokes workspace access and removes their scheduled chats and personal context. The workspace must retain an administrator, and users cannot remove their own account through that control.

That documented behavior does not establish every possible session or token consequence. If the organization requires a particular active-session revocation behavior, API credential treatment, or provider-side timing, ask for the exact evidence. Do not describe an immediate universal session kill unless the vendor establishes it.

The workspace setup guide and workspace overview provide the broader administration context. Use the membership documentation for the actual removal action and its stated effects.

A controlled removal check should use an approved test identity and a planned recovery path. It should not casually remove an active seller or administrator whose work is still needed. The acceptance matrix defines what to verify, not authorization to disrupt the team.

Review connected access and owned work as dependencies

Before removal, Unify advises reviewing and reassigning owned sequence enrollments, tasks, and accounts, and checking mailboxes and personal CRM connections. That handoff planning is separate from the identity control that revokes workspace access.

Use sequence enrollments, task management, and mailbox operations to identify the relevant objects. Do not assume removing the user automatically transfers every active workflow to a new owner.

Connected CRM identities add another dependency. Salesforce connection preferences and HubSpot connection preferences distinguish personal and workspace connections. Review their ownership and requirements separately from SSO configuration.

Scheduled chats can execute for selected users with each user's permissions and context. Because member removal removes scheduled chats and personal context, do not assume those schedules continue unchanged or automatically transfer to a manager.

Keep this dependency review focused on acceptance of the identity lifecycle. A full business handoff of conversations and accounts is a separate operating process. The buying decision should identify who owns that process and which product effects must be understood before removal.

Use an identity-lifecycle acceptance matrix

The table below is blank for a documented review or authorized demonstration. It contains no performed joiner, role-change, or removal test.

Record the provider, workspace, plan, configuration, test identity, and review time. State which results were demonstrated and which are supported only by documentation. Leave missing evidence visible rather than converting it into an assumed pass.

For a requirement that is not supported natively, document any proposed manual process and its owner. A manual process can be acceptable for some teams, but it should be evaluated as manual work with its own failure modes, not described as automated provisioning.

If the organization tracks evaluation completion, define the denominator as the mandatory lifecycle requirements at the review cutoff. Count as complete only requirements with sufficient evidence and a reviewed decision. Report unresolved and not-reviewed requirements separately; with no requirements in scope, report not applicable.

Decide on the complete operating process

Compare vendors on the process your team needs to run: who joins, how they receive access, what changes when their role changes, and how access ends. A shorter feature checklist can miss a material gap between sign-in support and membership administration.

Record contractual or plan dependencies explicitly. If an SSO add-on is required, include it in the commercial scope. If provisioning is unresolved, do not hide that gap behind a successful login demonstration. If removal requires an application administrator, include that action in the organization's documented leaver process.

The broader RevOps evaluation guide can incorporate these findings alongside workflow and data requirements. The identity conclusion should state exactly what is documented, what was demonstrated, and what remains the customer's responsibility.

Ask distinct provisioning questions during procurement

Start with membership creation: what exact event creates the application member, and what happens if that step fails? Then ask which system supplies the initial role, whether the role can be changed centrally, and whether the application reports a failed update. These questions should be answered for the selected provider and plan, not for an unspecified enterprise deployment.

Next ask about membership removal. Does disabling the identity-provider assignment remove the application member, prevent new sign-ins, or do something else? Which documented action is required to revoke existing workspace access? If the customer must complete a separate administrative step, name it explicitly in the leaver process.

Ask about reactivation as a separate operation. Reusing the same email can restore membership under a documented process, but the team still needs to review the intended role and workflow assignments. Do not assume the returning user's old responsibilities are automatically appropriate for the new role.

These questions do not imply that Unify supports a particular provisioning protocol. They define the evidence a buyer should request when automation of membership is a requirement. If the cited documentation establishes only invitations and manual role management, retain that narrower conclusion until additional evidence is available.

Check administrative continuity

Identity changes need an administrator who can carry them out. Record which team owns the application membership controls and how it coordinates with the identity-provider administrator. If those responsibilities belong to different teams, define the handoff for a joiner, a role change, and a leaver.

Unify requires the workspace to retain an administrator and prevents a user from removing their own account. Incorporate those documented constraints into the process. Do not create a review plan that depends on the sole administrator removing themselves or losing access before another authorized administrator is available.

Ask how the organization will review administrator membership over time. This is an internal operating responsibility rather than a claim about a native review feature. The relevant requirement is that someone can identify the current administrators and perform needed changes through the supported controls.

Coordinate provider changes carefully. Switching identity providers or sign-in domains can affect existing membership matching. The Unify SSO guide directs customers to contact the account team before changing an enforced connection. Include that dependency in a migration plan rather than treating a provider switch as a routine role edit.

Make the demonstration representative without disrupting users

A useful demonstration follows the intended lifecycle with an approved test identity. Verify the initial membership and role, then inspect the documented change and removal behavior in a controlled setting. Capture the result for each step separately so a successful login does not mask an unverified removal requirement.

Record any difference between the test environment and the proposed production configuration. The identity provider, plan, enforcement mode, or connected services may differ. Those differences limit what the demonstration establishes and may require documentation or another approved check before rollout.

If an active-session requirement is material, ask the vendor to demonstrate or document that exact behavior. Do not infer it from the inability to start a new session. Existing sessions, personal connections, and other credentials may have distinct lifecycle rules that need separate evidence.

After the review, remove or retain the test identity according to the agreed plan and record the final state. The evaluation should leave the workspace in an intentional condition, with any temporary access and seat implications accounted for.

The final procurement record should make clear which lifecycle operations are automated, which require an administrator, and which remain unresolved. This allows the organization to estimate the ongoing administrative work and decide whether the process fits its control requirements without overstating what SSO alone delivers.

Frequently asked questions

Does SSO support imply SCIM provisioning?

No. Authentication and provisioning are separate capabilities. Ask for the exact supported mechanism and evidence for membership creation and removal.

What does Unify currently document for enterprise SSO?

Enterprise SSO is a paid add-on arranged with the account team. The guide describes provider setup, testing before enforcement, and continued management of workspace membership and roles.

Does removing a Unify member preserve their scheduled chats?

The membership documentation says removal revokes workspace access and removes scheduled chats and personal context. Review owned work before removing access.

Can a removed teammate return?

Unify documents that an administrator can invite the same email address again to reactivate membership. Review the person's role and workflow assignments when they return.