Skip to content
SteveTechArcSteveTechArc Courses

Salesforce as the Source

Module 5 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: What if Salesforce is the place that knows who works here, and other apps need the accounts?

The other way round

Section titled “The other way round”

Modules 2 to 4 brought users into Salesforce, from the identity provider. Chapter 7 turned Salesforce into the identity provider, so people log in to other apps with their Salesforce login. Now put those together. If Salesforce is the identity provider, someone still has to create Priya’s account in those other apps. Can Salesforce do that too?

It can, through a connected app: user provisioning for connected apps. It “simplifies account creation and links your Salesforce users’ accounts to their third-party accounts” (S5).

How it works

Section titled “How it works”

Salesforce’s own example is a G Suite connected app (S5). Assign the Employees profile to the app. When you create a user with that profile, she’s provisioned in G Suite. When she’s deactivated, or her profile changes, she’s deprovisioned there.

Salesforce as the source Salesforce as the source, in three columns: in Salesforce, the connected app, and the other app. When she joins, as a user with the app's profile or permission set, that triggers user provisioning on the connected app, a request and then a User Provisioning flow, which calls the other app's API and creates her account there, linked to her user. When she moves or leaves, with a new profile, frozen or deactivated, the same flow sends another request, and her account there is updated, frozen or deprovisioned. Green marks one place to manage her, with the other app following. Footnote: a connected app feature, not available on external client apps, and new connected apps are restricted since Spring '26. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-05", "id": "DGM-IAM-PRV-05", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} IN SALESFORCE THE CONNECTED APP THE OTHER APP She joins a user with the app's profile or permission set User provisioning a request, then a User Provisioning flow Her account there created and linked to her user She moves or leaves a new profile, frozen, or deactivated User provisioning the same flow, another request Her account there updated, frozen or deprovisioned triggers calls its API triggers calls its API A connected app feature: not available on external client apps, and new connected apps are restricted since Spring '26. HOW TO READ IT one place to manage her, the other app follows © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge
  • Who: only “users with a profile or permission set that grants them access to the connected app” (S5).
  • When: events in your org become requests. Create, update, disable, enable, freeze, unfreeze and reactivate a user; change her profile; assign or remove a permission set (S5).
  • How: each request is a UserProvisioningRequest record, processed straight away or after an approval, by a flow of type User Provisioning that uses an Apex UserProvisioningPlugin class to call the other app’s API (S5).
  • Seeing it: reports show who has accounts in which apps, in one place (S5).

It’s module 4’s SCIM idea, pointed the other way: the place that knows tells the app that needs to know.

A hard truth, with a date

Section titled “A hard truth, with a date”

Here’s the part to know before you design with it. User provisioning is a connected app feature. On the comparison of connected apps and external client apps, Salesforce lists user provisioning as “Available” for connected apps and “Not available” for external client apps (S6). And since Spring ‘26, new connected apps are restricted: “If you must continue creating connected apps, contact Salesforce Support” (S5).

So, as of November 2026:

  • Existing connected apps with user provisioning keep working. “You can continue to use existing connected apps” (S5).
  • A new design can’t use it on an external client app. Check the comparison page again when you design: it may change.
  • The usual answer today is to provision from the identity provider: if Salesforce isn’t the only source of truth, the company’s identity provider, or the other app’s own provisioning, is often the better place to run it.

That’s not a criticism; it’s where the platform is right now, and the date is on it.

Identity Connect, a legacy note

Section titled “Identity Connect, a legacy note”

You may still see Identity Connect in older designs, and in the exam guide. It was a small Salesforce product that connected a company’s on-premises Active Directory to Salesforce: user provisioning, and optionally single sign-on. If you had a client with a single Active Directory who didn’t want to pay for a big identity provider, it was a cheap way to stand it up.

It’s retiring. In Salesforce’s words: “Salesforce is retiring Identity Connect and will continue to honor your existing Identity Connect subscription and provide support until your subscription ends. Moving forward, Identity Connect will only receive security updates” (S9). And: “Salesforce isn’t building a replacement for Identity Connect” (S9). Why? Because most customers have moved to the cloud, few still have on-premises Active Directory, and “several companies offer high-quality user provisioning solutions” (S9). Salesforce’s notice names Microsoft’s connector for Salesforce as one path for companies moving to Microsoft’s cloud directory (S9).

If you find it in an org: plan the move before the subscription ends.

Test knowledge. The exam guide aligns to Summer ‘23 and still lists Identity Connect (SID-1). In my experience, know what it did, Active Directory to Salesforce, and that it’s retiring.

What’s next

Section titled “What’s next”

That’s the chapter. The practice builds just-in-time between your two lab orgs, in two parts. Then chapter 13: External Client Apps, Tokens and Their Lifecycle.

What an architect decides here

Section titled “What an architect decides here”
  • Which system is the source of truth for each group of people, and which apps follow it.
  • Whether to provision from Salesforce, knowing it’s a connected app feature today, or from the identity provider.
  • What to do with Identity Connect, if you find it, before its subscription ends.

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.