TL;DR. SCIM provisioning auto-creates new hire accounts the moment HR marks them hired, so day one stops being a scavenger hunt. The architecture is simple: your HRIS triggers your identity provider, your identity provider pushes accounts into every connected SaaS app, and your MDM rolls out the laptop on first login. 

The same protocol revokes access cleanly when someone leaves. The work is in mapping the right apps, scoping the right groups, and catching the SaaS tools that do not actually support SCIM.

What SCIM Actually Does

SCIM, System for Cross-domain Identity Management, is an open-standard protocol. It defines how identity systems talk to SaaS apps so user accounts can be created, updated, suspended, or deleted automatically.

In plain terms: when an authoritative source, your HRIS or identity provider, says this person exists, every connected app gets a synchronized account with the right role, group, and permissions, without anyone opening a ticket. The mechanics matter, because most automated onboarding setups stop at the calendar invite. SCIM is the thing that actually lights up the apps.

Under the hood, SCIM uses JSON over a REST API, and the operations map to the standard CRUD model: Create adds a user to an app, Read retrieves existing identity and group data, Update syncs changes across systems, and Delete deprovisions the account. A SCIM-enabled SaaS app exposes endpoints for each of those. Your identity provider, whether Okta, Entra ID, Google Workspace, Rippling, or JumpCloud, calls those endpoints whenever a user’s state changes. The whole loop runs in seconds.

SCIM vs SAML vs SSO

These three get confused constantly, and the confusion causes real provisioning failures, so it is worth being precise.

• SCIM provisions the account. It creates, updates, and deletes the user record in each app.
• SAML and SSO authenticate the user. They let someone log in to many apps with one set of credentials. They do not create the account in the first place.

They are complementary, not interchangeable. SCIM lays the groundwork that SSO depends on: SSO can only log a user into an app that already has an account, and SCIM is what puts the account there. This distinction matters in practice, because a vendor that advertises SSO support is not necessarily telling you it supports SCIM. More on that failure mode below.

The HRIS Trigger: Where Provisioning Starts

The cleanest provisioning chain starts in your HRIS, not your IdP. The HRIS knows the start date, the role, the manager, and the department. That metadata determines what apps the person needs.

When the HRIS flips someone’s status from hired to active on their start date, it pushes that event to the IdP. The IdP creates the directory account. Group membership is set by department, role, and location attributes.

That group membership is the single most important field in the whole chain. It determines which SaaS apps the person gets, which Slack channels they auto-join, and which Drive folders they can read.

Most provisioning failures we see at startups trace back to inconsistent attribute mapping between HRIS and IdP: a misspelled department, a missing manager field, a role that does not exist in a SCIM rule. Get the schema clean before you wire anything up. Our IT onboarding process guide walks through where to set those attributes.

IdP-to-SaaS Sync: Mapping the Account Graph

Once the IdP has the user, SCIM does the rest. The IdP pushes account creation to every connected SaaS app in parallel.

Productivity stack first: Google Workspace or Microsoft 365, Slack, Notion, Linear, Jira, GitHub. Then role-specific tools: Salesforce for sales, Figma for design, Stripe for finance.

The trick is that each connected app needs three things wired correctly: the SCIM endpoint URL, an OAuth or API token, and an attribute map that translates IdP fields to app fields. The map is where projects stall. You will find that one app expects department and another expects team, and you have to normalize.

Group-based assignment is non-negotiable. Never provision apps to users individually. Provision apps to groups, then put users in groups. That way you can add a new app to Engineering and it appears for every engineer on the next provisioning sync.

For SaaS tools that do not support SCIM, and this is more common than vendors admit, you have two fallbacks. Use a workflow automation tool such as Workato, Zapier, Tines, or your IdP’s lifecycle workflows to call the app’s API on user events. Or push those apps to a sunset list and find a SCIM-capable replacement at renewal.

MDM Enrollment Without Tickets

The laptop is where automation actually meets the user. Mobile Device Management (MDM), software that pushes apps, security policies, and configuration to company-owned hardware, is what makes a brand-new Mac usable from the unboxing.

Apple Business Manager with Jamf, Kandji, or Mosyle handles macOS. Intune or Kandji handle Windows. The flow is the same: the device is purchased and assigned to your MDM at the depot, the new hire turns it on, signs in with their corporate identity, and the MDM pushes down apps, VPN, browser extensions, the security agent, and shell config.

No ticket. No here is the admin password. The first time the laptop hits the internet, it is already a company laptop.

The setup investment is real, a stretch of MDM configuration, identity tie-in, and shipping logistics, but it pays back within the first few onboardings. After that, every new hire is pure time saved.

What to Automate First

Do not try to SCIM everything at once. Sequence by usage frequency.

The short answer. Start with the four apps every new hire uses on day one: your IdP and SSO layer, your email and calendar suite, your chat tool, and your code or project repo. That covers the large majority of the day-one experience. Then layer in role-specific apps by team.

The order we recommend:

• Identity and SSO. Okta, Entra, JumpCloud. This is the spine.
• Email and calendar. Google Workspace or Microsoft 365.
• Chat. Slack or Teams, with channel auto-join by group.
• Repos and project management. GitHub, GitLab, Linear, Jira, Notion.
• Role-specific apps. Salesforce, Figma, Stripe, design tools, data warehouse access.
• Edge tools. Anything used by a small slice of the company. Often not worth a SCIM connection. Automate via API or accept manual.

A good rule: if an app is used by a large share of the company, it gets full SCIM provisioning. If it is used by a smaller share, it gets workflow-based provisioning. If it is used by only a handful of people, IT just provisions it on request.

Failure Modes Nobody Warns You About

The first failure mode is the silent SCIM sync. An app accepts the SCIM payload, returns a success code, then does not actually create the account. We have seen this with apps that turned out to be SAML-only despite advertising SCIM support. Always test with a fake user before going live. Always.

The second is attribute drift. Someone changes their last name. The HRIS updates, the IdP updates, most connected apps update, but one does not, because its SCIM attribute map only fires on creation, not updates. Now you have a stale name in Slack.

The third is group membership creep. Someone moves teams. Their group changes. SCIM revokes their old app access automatically. The marketing director loses Salesforce on day one of her new role because nobody added Marketing to the Salesforce assignment. The fix is to plan for transitions explicitly in your group strategy, with overlap windows for role changes, a pattern our team covers in the section on transitions in common IT onboarding mistakes.

The fourth is the contractor problem. SCIM works beautifully for full-time employees in your HRIS. Contractors, freelancers, and short-term roles often live in a different system. Build a parallel provisioning path for them before someone forgets to deactivate a six-week contractor.

Offboarding: The Other Half of the Protocol

Provisioning gets the attention because a slow day one is visible and embarrassing. Deprovisioning gets ignored because a lingering account is invisible until it is a problem. SCIM handles both, and the offboarding side is where the security payoff is largest.

When the HRIS flips someone to terminated, SCIM can suspend or delete their account in every connected app in the same sync that would have created one. No orphaned Salesforce login, no forgotten GitHub access, no former contractor still in the Slack workspace three months later. Those leftover accounts, the zombie accounts, are exactly the kind of unmonitored access that widens your attack surface.

Treat offboarding as a first-class part of the design, not an afterthought. Map the deactivation path for every app you map the creation path for. The same group structure that grants access cleanly is what revokes it cleanly.

Measuring the Time-to-Productivity Gain

The numbers that matter to your CFO are simple: how many hours of IT labor per hire, how many days until the new hire is fully tooled, and how many provisioning-related tickets you get per month.

Manual setup eats meaningful IT labor per new hire and several calendar days to full tooling, and provisioning tickets make up a large share of the IT queue. Done right, SCIM cuts the IT labor per hire to a brief human sanity check, full tooling is live before the new hire opens the laptop, and provisioning tickets drop to near-zero, because the system does not forget.

There is also a hidden cost most companies miss: incomplete onboarding compounds. If a new hire does not get a Stripe seat on day one, they ask for it on day three, get it on day five, then discover on day seven they also cannot access the analytics dashboard. Each missed app extends time-to-productivity. Automation removes the compounding. For a deeper look at how long onboarding actually takes once it is instrumented, see our piece on onboarding timing benchmarks.

Day-One vs 30-60-90: Where Automation Lives

Day-one provisioning is the foundation. A 30-60-90 day plan layers on top of it, but it is a different problem.

Day one is about access: accounts, apps, devices. The 30-60-90 plan is about ramp: training, project assignments, team integration. SCIM handles day one cleanly. The 30-60-90 plan needs human design, with checkpoints at 30 days (system access fully validated), 60 days (first project shipped), and 90 days (autonomous on core responsibilities).

If you are building this from scratch, the onboarding best practices playbook has the human side covered, and shipping logistics, especially under current tariff conditions, is in our tariff and onboarding piece. For the foundational view of what IT onboarding actually means at a startup, our what is IT onboarding primer is the starting point.

Frequently Asked Questions

What is SCIM and what is it used for?

SCIM, System for Cross-domain Identity Management, is an open-standard protocol that automates the flow of identity information between an identity provider or IAM system and cloud apps. It uses JSON over a REST API, and its operations map to the CRUD model: create, read, update, and delete user accounts. It is used to provision and deprovision accounts automatically and provides the groundwork that single sign-on depends on.

What is the difference between SCIM and SAML or SSO?

SCIM provisions the account: it creates, updates, and deletes the user record in each app. SAML and SSO authenticate the user, letting them log in to many apps with one set of credentials. They are complementary. SSO can only log a user into an app that already has an account, and SCIM is what creates that account. A vendor advertising SSO support does not necessarily support SCIM.

How long should IT onboarding take?

Once SCIM provisioning is in place, IT onboarding takes a brief human sanity check per new hire and is fully live before the new hire opens the laptop. End-to-end time-to-productivity on tooling should be effectively zero by start time. Without automation, the same process consumes hours of IT labor and several calendar days, costing real billable productivity from the new hire.

What should be included in an IT onboarding checklist?

A complete checklist covers identity (SSO account, group membership), communications (email, calendar, chat with auto-joined channels), core productivity tools, role-specific apps, hardware (MDM-enrolled laptop, peripherals, shipping confirmed), the security baseline (MFA enrolled, password manager, security training), and access validation. SCIM should automate the identity, communications, and tooling items. Hardware and security validation stay human-supervised.

How do I ensure new hires are productive on day one?

Provisioning has to be complete before start, not on start. That means SCIM-driven account creation triggered ahead of the start date, MDM-enrolled hardware delivered and tested in advance, and a buddy or manager scheduled for the first hour. Day-one productivity is an architecture problem, not a willpower problem. Manual provisioning will always cost a day.

How do I provision SaaS apps for new employees?

Use SCIM where the app supports it: connect each app to your identity provider, map attributes from your HRIS and IdP, and assign apps to groups instead of individuals. For non-SCIM apps, build workflow-based provisioning via Workato, Tines, Zapier, or your IdP’s native lifecycle automation. Individual ticket-based provisioning should be the exception, not the default. Always test a new SCIM connection with a fake user before going live.

How does SCIM help with offboarding?

When the HRIS marks someone as terminated, SCIM can suspend or delete their account across every connected app automatically, in the same sync that would have created one. This prevents orphaned or zombie accounts, the unmonitored leftover access that widens your attack surface. Map the deactivation path for every app you map the creation path for, so offboarding is as clean as onboarding.

How do I create a 30-60-90 day IT onboarding plan?

Day one is automated provisioning: accounts, apps, devices. By day 30, validate that every system access works and any role-specific tools are added. By day 60, the new hire should have shipped their first piece of real work, with no IT-related blockers. By day 90, they are autonomous. Build checkpoints with the manager, not just IT, since ramp is a joint responsibility.

Get SCIM Provisioning Live in Six Weeks

Interlaced builds and runs the provisioning architecture for SaaS startups. We map your HRIS, wire your IdP, connect every SCIM-capable app, and design the workflow fallbacks for the ones that are not.

You do not need to hire a head of IT to make this real. You need someone who has done it many times and knows where each vendor breaks. That is us.

If new hire chaos is costing you a real day-one experience, talk to our IT onboarding team. We will scope the gap and run the rollout.