User Provisioning Checklist for SaaS Onboarding (2026)

To provision users for a SaaS onboarding you need four things from the customer: a roster with seven fields per person (work email, full name, product role, team, license type, go-live wave, and status), a decision on how people will sign in (local passwords, SSO, or SSO plus SCIM), a named owner on the customer side who can get answers from their IT team, and a freeze date after which changes wait for the next wave. Ask for all four at kickoff, because the roster is a customer deliverable like any other and it is usually the last one to arrive. This checklist covers what to collect, how to get it on time, how to design roles that survive contact with real job titles, what to ask IT about SSO and SCIM, how many seats to create at go-live, and what to do with the accounts afterwards.

What do you need from the customer to provision users?

Four inputs, in this order: the roster, the sign-in method, a customer-side owner, and a freeze date. Everything else (role design, seat counts, MFA policy) is a decision you make together once those four exist.

The roster is the list of people who will have an account on day one, with enough detail per person to create the account without a follow-up question. The sign-in method is a binary decision with a long tail: either users authenticate through the customer's identity provider (Okta, Microsoft Entra, Google Workspace) or they get a username and password in your product. The owner is one named person, usually the project lead, who can escalate to IT when the SAML metadata is three days late. The freeze date is the day the list stops changing for wave one.

The scale of the IT side explains why this needs structure. Okta's 2025 Businesses at Work report puts the average number of apps per company at 101, the first time it has crossed 100, so your product is one more integration in a long queue for the same identity team. Zylo's 2025 SaaS Management Index found companies with 1 to 500 employees run an average of 152 apps. Nobody on the customer side is waiting for your provisioning request with a clear calendar.

Why does user provisioning slip so often?

It slips because three different customer groups own a piece of it and none of them owns the whole. The business sponsor knows who should use the product but does not know their license type. HR or the team leads have the current org chart but sit outside the project. IT owns the identity provider and treats every new vendor as a security ticket with its own queue. Your onboarding manager is the only person who sees all three pieces at once, and usually finds out about the gap when a user cannot log in at training.

Scenario: you are three days from training, the roster arrived with 84 names and 31 have no role assigned, and the customer's IT admin replied to the SSO request with a link to their vendor security questionnaire. Nothing in the contract said who does what, so every step is a negotiation.

Money adds friction. Many SaaS vendors gate SSO behind a higher tier, a practice tracked by the independent SSO Premium Index: across the vendors it live-verifies, the median premium to turn on SSO is 150% over the base plan, with Slack going from $7.25 to $12.50 per user (72% more) and GitHub from $4 to $21 (425% more). If your own pricing does this, expect the customer's first question about SSO to be about cost, and expect procurement to reopen the deal at the exact moment you need IT to move.

The list itself is unstable too. People join, leave, and change teams during a 60 to 90 day implementation, and a roster exported in week one is partly wrong by week eight. Without a freeze date and a wave column, every change is an edit to a spreadsheet somebody already used to create accounts.

The result shows up in the go-live checklist as a single line, "users provisioned", that hides a dozen dependencies. Treat it as a customer deliverable with an owner and a date, tracked alongside data files and integration credentials, and the slippage becomes visible early enough to fix. Our guide to tracking customer deliverables during onboarding covers the register format.

What should the user roster template contain?

Seven fields per person, no more. Every extra column lowers the chance the customer fills the sheet in, and every missing one produces a follow-up email per user.

Ask for the roster as an export from the identity provider or HR system rather than a hand-typed sheet. An Okta, Entra, or Google Workspace group export already has correct emails and display names, and it gives IT a reason to create the group you will later map to a role. If the customer runs a phased rollout, the wave column is the field that saves you the most time; see our guide to phased rollout versus big bang for how to cut the waves.

Version the file. Name each delivery with a date, keep the previous one, and diff them. When 12 names change between the March 3 and March 17 versions, you want to know which ones without re-reading 200 rows.

How do you get the user list from the customer on time?

Ask for it in the kickoff meeting, with a due date two weeks before training, and put it on the deliverables register with a named owner. The register is what makes the date real; a request in a meeting is a suggestion.

• Ask at kickoff rather than at configuration. The roster needs HR or team leads, who take a week to respond. Kickoff agendas that include "who will use this and how will they sign in" as a standing item avoid the late scramble. Our kickoff meeting agenda has the slot.
• Accept an 80% list. Wave one only needs the people who will be trained first. Insisting on the complete org before you create any account delays everyone for the sake of the stragglers.
• Set a freeze date. Changes after the freeze go into wave two. This is the single rule that stops the list from being edited the night before go-live.
• Tie it to something the customer wants. Training invitations go to the roster. No roster, no invitations, which the sponsor notices faster than a status report.
• Route the IT parts separately. SSO metadata and SCIM tokens come from a different person than the roster. Two requests, two owners, two dates.

When the list still does not arrive, the cause is usually that nobody on the customer side has been told it is their job. Name the owner in writing, in the shared channel, and put the date next to it. The playbook in what to do when a customer goes dark applies to a missing roster exactly as it does to a missing data file.

How do you design roles without creating a mess?

Start with three roles (admin, standard user, read-only), map every customer job title to one of them, and add a fourth role only when a real permission conflict appears. Role sprawl is the quiet cost of implementation: every role you create at go-live is one you will maintain, document, and explain for the life of the account.

Build the mapping as a table the customer signs: job title or IdP group on the left, product role on the right, a one-line reason in the middle. It turns "who should be an admin" from a debate into a lookup, and it becomes the rule an automated provisioning connector follows later. A practitioner thread on the Adobe Workfront community shows what goes wrong without it: auto-provisioned users landed in the default access level, the customer needed a different one, and it took several support contacts to map an Active Directory field to the right license. Decide the default role and the mapping field before the connector is switched on.

Two rules keep the model honest. First, least privilege at go-live: give the smallest role that lets the person do their day-one job, and promote later on request. Demotions after launch feel like punishment; promotions feel like progress. Second, no shared accounts. A "team login" for the warehouse floor is a credential nobody rotates and nobody can be held to in the audit log.

Document the three roles in plain language the customer can paste into their own training deck. If you cannot explain a role in one sentence, it is two roles or it is unnecessary. Role decisions belong in the project's decision log; our guide to tracking decisions in customer Slack channels covers how to keep them from vanishing into a thread.

SSO, SCIM, or local logins: what should you ask the customer's IT team?

Ask which identity provider they use, whether they want SAML or OIDC single sign-on, whether they want automated provisioning through SCIM, which IdP group maps to which product role, and what should happen to a user's account and data when they are deactivated. Send the questions as one written intake, because IT answers tickets and forgets Slack threads.

SCIM is the standard that lets the customer's directory create, update, and deactivate accounts in your product automatically; it is defined in IETF RFC 7644. With SCIM the roster stops being a spreadsheet and becomes a group in the customer's IdP, which is the state you want by the end of hypercare.

The security case for SSO is short. Microsoft reports that more than 99.9% of compromised accounts do not have MFA, and SSO inherits whatever MFA policy the customer already enforces. Verizon's 2026 Data Breach Investigations Report, as summarized by SecurityWeek, found credential abuse still opened 13% of breaches in 2025, and that 48% of breaches involved a third party, a 60% increase in a year. Your product is that third party from the customer's point of view, which is why their IT review asks about your MFA support before it asks about your features. Our guide to passing the customer IT security review covers the questionnaire side.

If the customer chooses local logins, follow the current NIST rules rather than the folklore. NIST SP 800-63B-4, finalized in August 2025, requires a 15-character minimum for single-factor passwords (8 when the password is one factor in MFA), and states that verifiers shall not require periodic password changes; a forced change is reserved for evidence of compromise. Customer IT teams know this document, and quoting it correctly is a fast way to earn trust in the review.

Two practical details from the same Workfront thread: the customer's IT had to allow-list the vendor's IP addresses before SSO worked, and users kept logging out and trying to log back in through the product's own login page instead of the SSO portal. Put the allow-list request in the intake, and put "sign in from the portal" in the training deck.

What should you send the customer's IT team before they ask?

Send a one-page provisioning pack with your side of the integration, so IT can open one ticket instead of five. It should contain:

• Your service provider metadata or OIDC configuration, and the exact fields you consume from the assertion (email, name, groups).
• The SCIM endpoint documentation and which attributes you support, including how deactivation is represented.
• The IP ranges and domains to allow-list for sign-in, email notifications, and webhooks.
• Your MFA and session policy for local logins, written against NIST SP 800-63B-4 so the reviewer can check it in a minute.
• The default role for auto-provisioned users and the group-to-role mapping template with the three roles already filled in.
• A test plan: one test user per role, one deactivation test, and the date you want to run it.

The pack answers the questions the security questionnaire will ask anyway, and it moves the request from "please set up SSO" to "please review and approve this configuration", which is a ticket IT can close.

How many seats should you provision at go-live?

Provision the wave-one roster and nothing more. Creating every contracted seat on day one feels generous and produces a list of accounts nobody has logged into, which is exactly what the customer's renewal review will find.

The waste is measurable. Zylo's 2025 index reports organizations waste an average of $21 million a year on unused SaaS licenses, up 14.2% year over year, from data covering more than 40 million licenses. A customer that provisioned 300 seats and activated 140 will remember the 160 when your renewal comes up, whatever the contract says. Stipulate has no per-user pricing, but most tools in the customer's stack do, and their SaaS management team is counting.

Measure activation per wave instead: accounts created, first login within 7 days, first meaningful action within 14. Those three numbers tell you whether the roster was right, whether training landed, and whether the role mapping blocked anyone. They also feed the onboarding metrics your leadership already tracks, and they are the earliest warning that adoption is slipping before hypercare ends.

What happens to accounts after go-live?

Someone has to deactivate them, and by default nobody does. Provisioning has an owner because it blocks go-live; deprovisioning has no deadline, so it waits for an audit or a breach.

The numbers are unflattering. Orchid Security's August 2026 report on orphan and local accounts, citing Varonis, found 44% of organizations report more than 1,000 orphaned accounts and 26% of all accounts may be stale, meaning unused for more than 90 days. The same report cites Trustle's finding that 27% of cloud breaches in 2024 involved misuse of dormant credentials, and Orchid's own analysis found 44% of applications have authentication paths that bypass the corporate identity provider. Every local account you create at go-live is one of those paths.

The fix gets decided during onboarding, while the customer still has a project team. Write three things into the runbook you hand over at the end of hypercare:

1. The deactivation trigger. With SCIM, removal from the IdP group deactivates the account within minutes. Without it, name the person who will send you leavers and how often.
2. The data rule. What happens to a deactivated user's records, ownership, and open items: reassign to a manager, keep read-only, or delete after a set number of days. Decide once.
3. The quarterly review. A 30-minute check, owned by the customer admin, comparing active accounts to the current roster. Put the first one on the calendar before you leave.

This is where the cost of a breach becomes the customer's own argument for doing the work. IBM's 2026 Cost of a Data Breach Report puts the global average at $4.99 million, a 12% increase and a record. A dormant account with a standing password is cheap to close and expensive to explain.

How do you track user provisioning as a customer deliverable?

Give it a row in the deliverables register, with the four inputs as sub-items: roster (owner, due date), sign-in decision (owner, due date), SSO or SCIM configuration from IT (owner, due date), and the freeze date. Status per line, reviewed in every weekly call, escalated the same way as a late data file. Our go-live checklist shows where it sits.

The reason this matters is that the commitments are made in the least trackable places. "IT will send the SAML metadata by Friday" is said on a call. "We need read-only for the finance team" is a Slack message at 6pm. Whoever runs the project has to catch each one, write it down, and follow it up. This is the part Stipulate does for implementation teams: it reads the customer Slack channel and call transcripts, records each promise as an action item with its owner and its source message, and gives the lead a per-engagement health read, so a late SSO deliverable surfaces as a risk in the dashboard the week it slips rather than at training. The roster, the metadata, and the SCIM token still come from the customer; what changes is that nobody has to remember who promised them.

Next steps

1. Add "user roster, sign-in method, IT owner, freeze date" to your kickoff agenda as a standing item.
2. Replace your current user template with the seven-field roster and ask for it as an IdP or HR export.
3. Write a one-page SSO and SCIM intake for the customer's IT team: identity provider, protocol, group-to-role mapping, default role, deactivation rule, IP allow-list.
4. Send your own provisioning pack (metadata, SCIM docs, IP ranges, MFA policy, test plan) with the intake so IT reviews one ticket.
5. Define three roles and a title-to-role mapping table the customer signs before any account is created.
6. Provision wave one only, and track accounts created, first login within 7 days, and first action within 14.
7. Hand over a deprovisioning runbook with a trigger, a data rule, and a quarterly review already on the calendar.