1 What Provisioning Actually Does
Provisioning is the process of creating or changing access to systems. SailPoint describes it as changing user access to systems and enterprise data, triggered through access requests, certifications, role assignments, or lifecycle events.
When HR hires David Chen as a Security Analyst starting 15 September, IAM can automatically create his Active Directory account, Entra ID identity, Microsoft 365 mailbox, Teams account, ServiceNow account, security tooling account, VPN access, and SOC application access — this is automated provisioning:
HR creates worker
↓
IAM imports worker
↓
Identity created
↓
Rules calculate access
↓
Accounts created:
Active Directory, Entra ID, Salesforce,
ServiceNow, SAP, other applicationsProvisioning covers more than just creating accounts:
2 Provisioning Connectors
Not every system supports the same integration method, and an enterprise IAM platform typically has to speak all of the following at once:
A modern system might just need IAM → SCIM API → Application. A legacy one might need IAM → generate CSV → secure file transfer → application batch process → account created overnight. An even older one might need IAM → ServiceNow task → administrator manually logs in → creates the account → marks the task complete. Large global companies still run all three models side by side.
3 Reconciliation & Authoritative Sources
Provisioning tells applications what IAM believes should exist. Reconciliation checks what actually exists. If IAM believes Alice should have Finance_User, but SAP actually shows Finance_User and SAP_Admin, that extra permission was likely assigned manually, outside IAM — reconciliation is what surfaces the discrepancy, which matters enormously for security.
IAM also has to know which system is trusted for a given piece of identity data — the authoritative source, or source of truth. For employees, that's usually the HR system (Workday, SAP SuccessFactors, Oracle HCM); for contractors, it might be a vendor management system, contractor database, or dedicated identity repository instead.
Different systems can be authoritative for different attributes at the same time: HR owns name/employee ID/department/manager/status, Active Directory owns username/Windows groups, IAM owns access roles, and the email platform owns the mailbox address. Poorly designed ownership creates synchronisation loops or lets one system silently overwrite another's valid data.
4 SCIM
SCIM (System for Cross-domain Identity Management) is an open standard for exchanging identity information between systems, providing standard representations for resources like users and groups and REST-style operations to manage them. Microsoft Entra ID and Okta both support SCIM 2.0 provisioning.
Before standards like SCIM, every application exposed a different proprietary API — POST /employees/create here, POST /api/adduser there, a SOAP request somewhere else — forcing IAM vendors to build a custom connector per application. SCIM gives them one common model instead.
The identity platform is the SCIM client; the application exposes the SCIM server. The same interface handles create, update and disable.
Typical SCIM operations
Create a user (POST /Users) with a JSON body carrying userName, name, emails, and active. Search for an existing user (GET /Users?filter=userName eq "alice@example.com") before creating a duplicate. Update via PATCH /Users/123456 for changes like department, manager, email, or status. Disable rather than delete, by setting {"active": false} — this preserves audit history, ownership information, and historical records while blocking login; permanent deletion typically happens later per retention policy. SCIM also manages groups (Finance Users, Security Analysts) the same way.
Authentication vs provisioning
An application frequently uses one protocol for login and a completely different one for account management — SAML (or OIDC) for authentication, SCIM for provisioning:
Okta
/ \
SAML SCIM
↓ ↓
Authentication Provisioning
↓ ↓
→ SaaS App ←SAML answers "is this user authenticated?"; SCIM answers "should this user have an account, and what attributes/groups should it contain?" Confusing the two is a common source of "why can Alice log in but has no permissions" tickets.
5 Common SCIM Problems
IAM engineers troubleshoot these constantly:
department mapped to departmentName incorrectly.employeeID (or vice versa) — a username change can then create a second identity instead of updating the first.401 Unauthorized / 403 Forbidden — distinguish these the same way Module 9 taught (authentication vs authorisation).active=false, but the application doesn't correctly process it.costCentre, employeeType, securityClearance, legalEntity.Understanding SCIM is genuinely useful for IAM engineers because provisioning problems usually require examining the actual HTTP requests and responses, not guessing from the UI.
Lab Lab 1 – Provision a User
Simulate the HR → IAM → Application flow. Create an employee record:
{
"employeeId": "10001",
"firstName": "Alice",
"lastName": "Smith",
"department": "Finance",
"status": "Active"
}🔮 Predict first
Using automation or a simple script, create the corresponding user account. What attributes from the HR record should map to the target system, and which ones shouldn't?
Reveal what to check
At minimum, name and department should flow through; employeeId should map to a stable internal identifier rather than being discarded, since it's what lets reconciliation match the account back to the right person later. Confirm the created account can be looked up by that stable ID, not just by name — the same lesson Lesson 5 revisits under "names are not reliable identifiers."
Lab Lab 2 – SCIM Create, Update & Disable
If possible, stand up or use a free/test SCIM server. Walk through GET /Users, then POST /Users, then PATCH /Users/{id}, then finally disable the user.
🔮 Observe at each step
The HTTP request, the response status code, the JSON payload, the assigned user ID, the attributes returned, and the active status.
Reveal why this matters
This is close to exactly what real IAM engineering work looks like day to day — not a UI with buttons, but reading and reasoning about raw HTTP requests and JSON payloads to figure out why an account didn't provision correctly.
Lab Lab 3 – SCIM Troubleshooting
Deliberately break your Lab 2 setup: first, use an invalid API token; then, use a valid token with insufficient permissions.
🔮 Predict first
What HTTP status code do you expect for each case, and what's the practical difference to an IAM engineer investigating the failure?
Reveal the answer
Invalid token → 401 Unauthorized (the request isn't authenticated at all). Valid token, wrong scope → 403 Forbidden (identity is known, but this action isn't permitted). Same distinction as Module 9's HTTP error section — an engineer who sees 403 and starts checking the credential itself is looking in the wrong place; the credential works, the permission doesn't.
Lesson Outcome
You should now be able to explain the full range of what provisioning covers (not just account creation), describe reconciliation and why authoritative sources matter, and walk through a SCIM create/update/disable flow along with the most common ways it breaks. Lesson 3 moves to what happens after the account exists: how users actually get into all these applications day to day via SSO and federation.