Separate single sign-on from user provisioning in a finance software purchase

Single sign-on can simplify authentication without explaining how a person receives an account, obtains the right role or loses access when their job changes. During procurement, ask the vendor to show the complete user lifecycle. A successful login is only one event in that process.

Microsoft's Entra documentation distinguishes application provisioning, which creates and maintains user identities and roles, from the protocols used for single sign-on. It also includes removal as part of provisioning. Use that distinction to make the vendor's proposal precise, even if your company uses a different identity provider.

Describe the groups who need access: employees, external accountants, temporary reviewers and administrators. Their accounts may follow different routes. The company should know which routes are supported and which require a manual step before assuming that one identity integration covers everyone.

Choose a few events to demonstrate: a new accountant joins, a manager moves departments, a reviewer receives temporary access and an employee leaves. For each, identify the company system that records the change, the person who approves it and the application role that should result.

Keep authentication and authorization separate in the discussion. Proving who a person is does not decide whether they may approve a payment, post a journal or view another entity. Ask how identity groups map to application roles and how exceptions to the mapping are controlled.

Consider combinations of roles. A person may legitimately hold several responsibilities, but the resulting access should be reviewed as a whole. Test the company's intended combination rather than assuming that individually appropriate groups always produce the intended result when combined.

Record who owns the mapping after launch. Identity administrators understand the connection, while finance owners understand the business authority. Both need a clear role when a department or approval structure changes.

Use named test users and the proposed identity configuration. Add a user through the normal route, then observe when the application account appears and which permissions it receives. Record any delay or approval step that the operating team must allow for.

Change the test user's department or group and inspect the resulting access. Check whether prior access is removed as well as new access added. A process that only grants new roles can leave a person accumulating permissions as their job changes.

Ask how the system handles a failed or incomplete provisioning event. The administrator should be able to identify the affected user and determine whether access is pending, unchanged or partially updated. A general sync-success indicator may conceal an exception for one important account.

Confirm how existing accounts are matched when the integration is introduced. The implementation should avoid creating duplicate identities or attaching the wrong person's history to an account. Use the vendor's supported matching process and review the result before a broad rollout.

Test a changed name or email address for an existing person. Ask which stable identifier preserves the connection and whether earlier approvals remain attributable to the same user. This helps distinguish a legitimate profile update from the creation of a new account with an unrelated history.

Assign someone to review failed provisioning events after launch. The company needs to notice a rejected removal or role change, not only discover it when a user reports a sign-in problem.

Remove the test user's assignment through the intended company process and verify the application's supported response. Ask what happens to active sessions, mobile access and any separately issued credentials or service connections. Do not infer that every route closes immediately from the fact that a new login is blocked.

Identify records that must outlive the user: approvals, posted work, comments, scheduled reports and ownership of open tasks. The company needs to retain appropriate attribution while transferring ongoing responsibilities. Deleting an account and disabling access can have different consequences, so confirm the documented behavior.

Check what happens to a scheduled integration or report owned by the departing user. A clean access removal can still interrupt finance if important automation depends on that identity. Assign a supported ownership model before relying on the integration in production.

Separate access removal from billing. Ask whether disabling or deprovisioning a user also changes the paid seat count and when that change affects the invoice. The operational and commercial actions may be different, and both need an owner.

Ask how external advisers are invited and removed, whether they use their own organization identity and how their access is limited to the agreed assignment. Confirm the process when an adviser changes firms or no longer has the identity originally used for the engagement.

Discuss how authorized administrators recover access if the identity connection fails. The company should use the vendor's supported method with appropriate safeguards and monitoring. Avoid inventing an informal shared login that becomes a permanent route around the normal controls.

Assign the support boundary between the identity provider, application vendor and implementation partner. A failed sign-in can originate in several places. The finance user needs one intake route, while the technical parties need enough evidence to determine where the problem belongs.

Document which exceptions remain manual. A small company can operate a careful manual process when automation is unavailable, but the quote should not describe the lifecycle as automatic if staff must complete essential removal or role-change steps themselves.

Confirm the application tier, identity-provider entitlements, setup work and ongoing administration needed for the demonstrated behavior. Ask whether single sign-on and provisioning are sold together or separately. Avoid comparing proposals using only the cost of ordinary user seats.

Retain the tested lifecycle events, observed timing, role mappings and exception procedure with the implementation record. Give the operating administrators and finance owner access to the relevant parts. The evidence should describe the configuration the company will actually use.

The buying decision is complete when the company can explain how the right person gets the right access, how that access changes and how it ends. A smooth sign-in experience is useful, but the full lifecycle determines whether the application remains manageable.