Standard JIT attributes and registration handler provisioning
How users get created and kept current at login: the attributes standard SAML JIT requires for internal and Experience Cloud users and the order it matches users, contacts and accounts, moving existing users to Federation ID JIT, how registration handlers create, update and confirm users for authentication providers, and the per-user permission that turns on delegated authentication.
Given a scenario, identify the ways that users can be provisioned in Salesforce to enable SSO and apply access rights.
~7 min read · 10 practice questions ·
What the exam expects
- Build a standard JIT assertion: the required
User.attributes, a profile name or ID inUser.ProfileId, optional fields such as the role. - Add the
Contact.andAccount.attributes Experience Cloud JIT needs, and predict whether it matches or creates the user, contact and account. - Turn on JIT for an org that already has users without creating duplicates.
- Choose where registration handler logic goes: createUser, updateUser or confirmUser, and know when a custom SAML JIT handler is needed instead.
- Grant Is Single Sign-On Enabled so delegated authentication applies to a user.
Key terms: standard JIT (Salesforce creates and updates users from SAML assertion attributes); Custom SAML JIT with Apex handler (a class implementing Auth.SamlJitHandler provisions instead); registration handler (the Apex class or flow an authentication provider runs to create or update the user); third-party account link (the stored link between a Salesforce user and a provider identity).
Key facts
- Detail
- Email, LastName, ProfileId, Username (insert only)
- Detail
- Profile name or ID; IDs differ between orgs
- Detail
- Assertion contains the Federation ID from the User object
- Detail
- Standard JIT only
- Detail
- Contact.Email + Contact.LastName when User.Contact is absent
- Detail
- Account.AccountNumber + Account.Name when Contact.Account is absent
- Detail
- Runs when a user who logged in before with the provider logs in again
- Detail
- Runs before updateUser for linked users; null return fails login
- Detail
- Applies only to users with Is Single Sign-On Enabled
Sources for this section (6)
- JIT Fields for Salesforcehelp.salesforce.com (opens in a new tab)
- Enable JIThelp.salesforce.com (opens in a new tab)
- JIT Fields for Experience Cloudhelp.salesforce.com (opens in a new tab)
- RegistrationHandler Interfacedeveloper.salesforce.com (opens in a new tab)
- ConfirmUserRegistrationHandlerdeveloper.salesforce.com (opens in a new tab)
- Configure Delegated Authenticationhelp.salesforce.com (opens in a new tab)
- Why does a returning user's access not change when permission set logic lives only in createUser?
- When does an authentication provider need Auth.ConfirmUserRegistrationHandler?
- Which URL connects an existing Salesforce user to their provider identity once?
- When does Experience Cloud JIT create a new account?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Platform Identity and Access Management Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 25 lessons of the Platform Identity and Access Management Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (10 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams