Just in Time
Module 2 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 can Salesforce create her user at the moment she first logs in?
A neat little term
Section titled “A neat little term”There’s a neat little term for user provisioning with the SAML assertion: JIT. What does JIT stand for? Just in time.
Remember the SAML assertion from chapter 6? Besides saying who she is, it can carry extra fields, called attributes. What extra information might the identity provider put in? Her first name, her last name, her title, her phone. Maybe what role she should have, what profile. If it sends enough, and she doesn’t exist in Salesforce yet, Salesforce can create a brand-new user for her, on the fly, and log her in.
That’s just-in-time provisioning. It creates and updates users “when users first log in to Salesforce with SAML single sign-on” (S1).
At her first login
Section titled “At her first login”Here’s chapter 6’s single sign-on picture, in the same places. Look at steps 3 and 4.
Everything is chapter 6 until step 4. Then Salesforce looks for a user with her Federation ID and doesn’t find one. Without JIT, that’s where the login fails. With JIT, Salesforce creates her user from the attributes, and the login carries on as if she’d always been there.
What the assertion must carry
Section titled “What the assertion must carry”The identity provider sends her details “in an Attributes statement in a SAML assertion”, and each User field takes the User. prefix: User.Username, User.Email (S2). Four fields are required (S2):
| Attribute | What it holds |
|---|---|
User.Email | Her email address |
User.LastName | Her last name |
User.ProfileId | Her profile; “pass the ProfileName” if the ID differs between orgs, which it does |
User.Username | Her Salesforce username; used only when the user is created |
And the subject of the assertion is her Federation ID: “JIT provisioning requires a Federation ID as the user type” (S1). That’s chapter 6’s matching value. It’s how Salesforce knows, next time, that this is the same Priya.
Many more are optional: her first name, title, phone, department, manager, employee number, her role, whether she’s active, and custom text fields (S2). Talk with whoever runs the identity provider about which ones it will send, and in exactly which format.
Turning it on
Section titled “Turning it on”In Salesforce, it’s one section of the single sign-on setting you built in chapter 6 (S1):
- From Setup, Single Sign-On Settings, edit the SAML setting.
- Under Just-in-time User Provisioning, select User Provisioning Enabled.
- For User Provisioning Type, choose Standard: “Provisions users automatically using attributes in the SAML assertion.”
- For SAML Identity Type, choose Assertion contains the Federation ID from the User object.
You need Customize Application and Modify All Data. Standard JIT is available even in Professional Edition; the custom handler in module 3 isn’t (S1).
Every login after
Section titled “Every login after”JIT doesn’t stop at creating her. Every time she logs in, the same attributes update her user. Change her phone number in the identity provider, and at her next login it’s updated in Salesforce too. That’s “JIT create, update”.
That’s a nice thing when you have a bunch of systems behind one identity provider. Change her details once, at the identity provider, and each system that uses JIT picks them up when she next arrives.
What it can’t do
Section titled “What it can’t do”Here’s the catch, and it’s a big one. It only happens when she logs in.
- Nobody who never logs in gets a user. If she must own records before her first login, make her another way (module 1).
- Changes wait for her next login. If her data has to be right tonight, whether she logs in or not, you need a batch, or the identity provider pushing (module 4).
- It never removes anyone. When she leaves, she stops logging in, so JIT never hears about it. Her user stays active until someone does something (module 4).
- No permission sets. The standard fields include her profile and her role, but there’s no field for a permission set (S2). Module 3 handles that.
So JIT is a great way in. It isn’t, on its own, a way to keep users right, or a way out.
Test knowledge. In my experience, know that just-in-time provisioning creates or updates a user from the SAML assertion’s attributes at login, and that it needs the Federation ID.
Watch it on video
Section titled “Watch it on video”In 2023 I made a video of just-in-time between two orgs: the phone attribute set at the identity provider, seen in the SAML tracer, and the user updated at login, with a custom handler. The note under the video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”Module 3: when the standard rules aren’t enough. Create user, update user, everywhere.
What an architect decides here
Section titled “What an architect decides here”- Which groups get their users just in time, and which need users before they log in.
- Which attributes the identity provider sends, in what format, and who owns that list.
- Which profile and role each person gets, and from which attribute.
- How leaving is handled, because JIT won’t.
Explore
Section titled “Explore”- Enable Just-in-Time Provisioning (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Just-in-Time SAML Assertion Fields for Salesforce (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)