Checkpoint challenge

Original, hands-on practice. Never modeled on actual exam questions. This closes the chapter Getting Users In and Out: Provisioning, chapter 12 of Securing Salesforce: Identity and Access.

Scenario

Your two lab orgs from chapters 6 and 7 already do single sign-on: Priya logs in at the identity provider org and lands in the service provider org, matched by her Federation ID. But someone made her user in the service provider org by hand, in chapter 6.

Now a new person joins: Leo Okafor. He has a user in the identity provider org, and none in the service provider org. In part 1, his user gets made the moment he first logs in. In part 2, you add your own logic, and Priya’s phone number follows her from one org to the other at every login.

Requirements

• The identity provider org’s app sends Leo’s details as attributes in the assertion.
• Standard JIT in the service provider org creates Leo’s user at his first login.
• A custom SAML JIT handler updates a user’s phone at every login.
• Leo’s leave, at the end: his user deactivated.

Constraints

• Lab orgs only. No company data, nothing personal.
• Never for an admin. Both admins keep a password and MFA, and never use single sign-on.
• The same SAML app as chapter 7, deployed from the same project folder.
• Leo’s username in the service provider org must be unique across all of Salesforce, so use your own suffix (step 3).

Your task

Part 1: standard JIT

1. Check where you are. Priya can log in from the identity provider org to the service provider org, as at the end of chapter 7. You have chapter 7’s project folder.

2. Make Leo, in the identity provider org only. Create a user, Leo Okafor, with a profile he can log in with, and set his Federation ID to E10443. Assign him the permission set “SSO to the service provider org” from chapter 7. Don’t create him in the service provider org: that’s the point. If the org has no Salesforce licence left for him, Company Information shows the licences it has; use one that’s free.

3. Send his details as attributes. In chapter 7’s project, open ServiceProviderOrgSaml.ecaSamlPlcy-meta.xml. Before the closing tag, add the four required attributes (S2), as custom attributes with a key and a formula:

    <customAttributes>
        <key>User.Email</key>
        <formula>$User.Email</formula>
    </customAttributes>
    <customAttributes>
        <key>User.LastName</key>
        <formula>$User.LastName</formula>
    </customAttributes>
    <customAttributes>
        <key>User.ProfileId</key>
        <formula>"Standard User"</formula>
    </customAttributes>
    <customAttributes>
        <key>User.Username</key>
        <formula>$User.FederationIdentifier &amp; ".YOUR-SUFFIX@splab.example"</formula>
    </customAttributes>

User.ProfileId takes a profile name here, which is easier than an ID that’s different in each org (S2): use one that exists in the service provider org and has a licence free. User.Username builds a new username from his Federation ID and your own suffix, such as your initials and today’s date. Deploy it again, as in chapter 7. In these formulas, a text value goes in double quotes and & joins two values; if the deploy says a formula is wrong, the error names it.

4. Turn on just-in-time in the service provider org (S1). From Setup, Single Sign-On Settings, edit the SAML setting from chapter 6. Under Just-in-time User Provisioning, select User Provisioning Enabled, and for User Provisioning Type, choose Standard. Check that SAML Identity Type is Assertion contains the Federation ID from the User object. Save.

5. Leo’s first login. Open a private window and turn on your SAML tracer. Go to the service provider org’s My Domain login page, click the button for the identity provider org, and sign in as Leo. You land in the service provider org. Leo has a user now.

In the tracer, find the assertion and its Attributes: User.Email, User.LastName, User.ProfileId, User.Username. Then, as the service provider org’s admin, open Setup, Users: there’s Leo, with that profile, his Federation ID E10443, and the username you built.

Part 2: your own logic

6. Switch to a custom handler (S1). Edit the same SAML setting. For User Provisioning Type, choose Custom SAML JIT with Apex handler. Click Automatically create a SAML JIT handler template, and for Execute Handler As, choose the service provider org’s admin. Save. Then open the generated Apex class and replace its updateUser method with module 3’s sketch, which copies the phone. The template Salesforce generates can change from release to release: keep its class name and its other methods as they are, and replace only updateUser.

7. Send the phone too. In the same SAML policy file, add one more attribute, and deploy again:

    <customAttributes>
        <key>User.Phone</key>
        <formula>$User.Phone</formula>
    </customAttributes>

8. Watch it follow her. In the identity provider org, change Priya’s phone to 555-0142. In the service provider org, set her phone to something else, 999-0000. Now, in a private window, log in to the service provider org through the identity provider org, as Priya. Check her user in the service provider org: her phone is 555-0142. Every login carries it across.

9. Leo leaves. In the identity provider org, deactivate Leo. Try to log in as him: you can’t. Now look at the service provider org: his user is still active. That’s module 4. Deactivate him there too, and you’ve done by hand what an identity provider pushing users would do for you.

Discussion

Why did Leo’s user appear, when chapter 6 said Salesforce matches and doesn’t create? Because you turned on just-in-time. The Federation ID found no one, and the attributes were enough to make him.

What if Leo had never logged in? He’d have no user in the service provider org. If he had to own records before his first day, just-in-time couldn’t help.

Why send a profile name, and not a permission set? Standard JIT has a field for a profile and a role, and none for a permission set (S2). For permission sets, you need your handler, or the identity provider managing them.

Who should decide Leo’s profile: the identity provider, or Salesforce? In this lab, the identity provider sent Salesforce’s profile name. In a real design, it should send who he is, his department, and let Salesforce decide what that means (module 3).

In step 9, why was Leo still active in the service provider org? Because just-in-time only runs at login, and leaving isn’t a login. The leave never reached Salesforce until you took it there.

Check your lab

• The attributes: User.Email, User.LastName, User.ProfileId, User.Username, then User.Phone, in the assertion.
• Part 1: Leo’s user created at his first login, with his Federation ID.
• Part 2: a custom handler running as the admin, and Priya’s phone updated at her login.
• The leave: Leo deactivated in both orgs.

Exam objectives exercised

• IDC-4 (recommending a provisioning method) and TPI-4 (provisioning users for single sign-on): just-in-time, standard and custom.
• AMB-2 (profiles and permission sets during single sign-on): the profile from an attribute, and why not permission sets.

Explore

• Enable Just-in-Time Provisioning (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
• Integrate a SAML SSO Service Provider as an External Client App (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)