Skip to content
SteveTechArcSteveTechArc Courses

Who Makes the User?

Module 1 of 5 in the chapter Getting Users In and Out: Provisioning, chapter 12 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: How does a person get a Salesforce user in the first place, and how do you choose the way?

Signing in assumes a user

Section titled “Signing in assumes a user”

Every chapter so far has quietly assumed something. When Priya signs in, through SAML, an auth provider, or any OAuth flow, Salesforce logs her in as a user. Somebody, somewhere, made that user.

So here’s the question I ask the room. The identity provider says “this is Priya”, the assertion arrives at Salesforce, and there’s no Salesforce user for her. What happens? By default, the login fails: Salesforce matches, it doesn’t create (chapter 6, module 5). What can you configure to happen instead?

That’s user provisioning: getting users made, kept up to date, and switched off. In identity work, people call the three moments joiner, mover and leaver. In this course I’ll just say it plainly: someone joins, someone moves, someone leaves. Every one of them has to reach Salesforce.

Five ways in

Section titled “Five ways in”

There are five ways a Salesforce user gets made.

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
  1. By hand. An admin creates the user in Setup. It happens when someone does it, and only then.
  2. A data load. A file, or a batch job that runs every night. You can set up your own batch load from an HR system or a directory, and it’s good for many users at once: a go-live, a migration.
  3. Just in time. The identity provider puts her details in the SAML assertion, and Salesforce creates or updates her user “when users first log in” (S1). Module 2.
  4. A handler. Your own code, or a flow, runs at her login and decides: the SAML JIT handler, chapter 10’s registration handler, or chapter 11’s token exchange handler. Module 3.
  5. The identity provider pushes. The company’s identity provider sends users to Salesforce as they change there, with the open standard SCIM: create, update, deactivate (S4). Module 4.

How to choose

Section titled “How to choose”

Most orgs use more than one. There’s never one way. In class I say there are usually three or four ways of authentication in one Salesforce org; provisioning is the same, a blend. Admins are made by hand, and keep a direct login as a backup plan. Staff come from the identity provider. Customers register themselves, or come in through social sign-on (chapters 10 and 14).

So for each group of people, ask four questions:

Where does the truth live? If there’s one place that knows who works here, an HR system or the company’s identity provider, Salesforce should follow it, not be typed in by hand. If you have a bunch of secondary systems and someone changes their phone number, you don’t want to cascade that change into each one yourself.

How many, and how often? Five admins: by hand. Five thousand staff, joining and leaving every week: something automatic.

How fast must a change arrive? Just-in-time only runs when she logs in. If her data has to be right tonight, whether she logs in or not, that’s a batch, or the identity provider pushing.

Does anyone need a user before they ever log in? A manager who must own records on day one. A user who is assigned work before her first login. Just-in-time can’t help her: nobody who doesn’t log in gets a user. Make her another way.

And one more, which most designs forget until it hurts: how does leaving reach Salesforce? Just-in-time never removes anyone. A data load only removes people if you build it to. Module 4 is about that.

Test knowledge. In my experience, be ready to recommend a provisioning method for a scenario: by hand, a data load, just-in-time at login, a handler, or the identity provider pushing users, and why.

What’s next

Section titled “What’s next”

Module 2: just in time. Her user, made at her first login.

What an architect decides here

Section titled “What an architect decides here”
  • Where the truth about each group of people lives, and that Salesforce follows it.
  • Which way each group gets its users, usually a blend.
  • Who needs a user before they ever log in.
  • How leaving reaches Salesforce, for every group.

Explore

Section titled “Explore”

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.