Skip to content
SteveTechArcSteveTechArc Courses

Getting Users In and Out: Provisioning

Chapter 12 of Securing Salesforce: Identity and Access, Part 2: Accepting and Providing Identity. Start with chapter 6 if the Federation ID is new to you.

Every chapter so far has quietly assumed something: when Priya signs in, Salesforce logs her in as a user. Somebody made that user. And when she leaves, somebody has to switch it off.

This chapter is that somebody’s job: how users get made, kept up to date, and switched off. In identity work they call it joiner, mover, leaver. Here it’s plain: someone joins, someone moves, someone leaves, and each one has to reach Salesforce.

The ideas in this chapter

Section titled “The ideas in this chapter”
  • Five ways to make a user: by hand, a data load, just-in-time at login, a handler at login, or the identity provider pushing users. Most orgs use a blend.
  • Just in time creates her user from the SAML assertion’s attributes at her first login, and updates it every login after. It needs four fields and the Federation ID, and it can’t set permission sets.
  • It only happens at login: nobody who never logs in gets a user, and it never removes anyone.
  • Create user, update user, three times: the SAML JIT handler, the registration handler and the token exchange handler do one job: decide which Salesforce user she is, and whether she gets one at all.
  • The identity provider says who she is; Salesforce decides what that means.
  • The login stops, the user doesn’t: switching her off at the identity provider leaves her Salesforce user active until the leave reaches Salesforce: deactivate, or freeze first.
  • SCIM lets the identity provider push joins, moves and leaves into Salesforce.
  • Salesforce as the source can provision other apps, through connected apps only, today. Identity Connect is retiring, with no replacement.

The picture

Section titled “The picture”

Here’s the chapter’s picture: five ways to make a user, and when each one arrives.

Five ways to make a user Five ways to make a Salesforce user, each with when it arrives and what it's good for. By hand, by an admin in Setup, arrives when someone does it, and only then; good for a few users, such as admins, a pilot or an exception. A data load, a file or a batch job, arrives when the job runs, nightly, weekly or once; good for many users at once, such as a go-live or a migration. Just in time, from the SAML assertion, arrives at her login, never for someone who doesn't log in; good for users who sign in through single sign-on, made the first time they arrive. A handler, your code or flow at login, arrives at her login, through SAML, an auth provider or a token exchange; good for rules the standard can't do, such as matching, permission sets and checks. The identity provider pushes, with SCIM into Salesforce, arriving when it changes there, for joins, moves and leaves; good for staff with one source of truth, where leaving reaches Salesforce as it happens. Footnote: most orgs use more than one; the question is where the truth lives, and how fast a change must reach Salesforce. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-05", "id": "DGM-IAM-PRV-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} THE WAY WHEN IT ARRIVES GOOD FOR By hand an admin in Setup When someone does it and only then A few users admins, a pilot, an exception A data load a file or a batch job When the job runs nightly, weekly, once Many users at once a go-live, a migration Just in time from the SAML assertion At her login never for someone who doesn't log in Users who sign in through SSO made the first time they arrive A handler your code or flow, at login At her login SAML, an auth provider, a token exchange Rules the standard can't do matching, permission sets, checks The identity provider pushes SCIM, into Salesforce When it changes there joins, moves and leaves Staff with one source of truth and leaving that reaches Salesforce arrives good for arrives good for arrives good for arrives good for arrives good for Most orgs use more than one. The question is where the truth lives, and how fast a change must reach Salesforce. HOW TO READ IT leaving reaches Salesforce as it happens © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The path through this chapter

Section titled “The path through this chapter”

Five modules, each standing on its own, and a practice.

  1. Who Makes the User? Signing in assumes a user; five ways in; how to choose.
  2. Just in Time At her first login; what the assertion must carry; turning it on; every login after; what it can’t do.
  3. Create User, Update User, Everywhere The custom JIT handler; three doors, one job; who decides her access.
  4. Out, as Well as In The login stops, the user doesn’t; freeze or deactivate; what else to tidy; the identity provider pushes.
  5. Salesforce as the Source User provisioning to other apps; a hard truth, with a date; Identity Connect.

Then the practice: just-in-time between your two lab orgs, in two parts, and a leave.

Check what stuck with the study guide.

What an architect decides here

Section titled “What an architect decides here”
  • Where the truth about each group of people lives, and how Salesforce follows it.
  • Which way each group gets its users, and who needs one before they ever log in.
  • Who maps who she is to what she can do, and how a move changes it.
  • How every leave reaches Salesforce, and who tidies up after it.
  • Which system is the source for other apps.

Beyond the exam: what AI changes. Agents need users too, and leaving has to reach them: an agent user nobody remembers is still a way in. Chapter 17 takes it further.

Explore

Section titled “Explore”

Each module lists its own sources, each checked 2026-11-07. Two to start with:

Next: External Client Apps, Tokens and Their Lifecycle.

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.