☁️ Salesforce
Salesforce — provisioning target for users and permission sets.
Salesforce ships as a target: the platform reads its users and permission sets, and writes permission-set assignments and user state. Profiles, permission set groups and public groups are real Salesforce access-object kinds the platform does not yet read — see the breakdown below. It is not an authoritative source for anyone by default — the people come from your HR system or your directory, and Salesforce is one of the places their access lands.
Identification
- vendor key:
salesforce - engine:
salesforce - default role:
target - type: Out-of-the-box vendor
- vendor docs: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/
Supported auth methods
oauth2_client_credentialsoauth2_auth_code
Those are the labels the onboarding wizard offers. What the connector actually
performs is the OAuth 2.0 username-password flow: it posts a password
grant to your org's token endpoint with the Connected App's consumer key and
secret plus a dedicated integration user's username and password, and receives
back an access token and the instance_url that becomes the data API base. If
you supply the integration user's security token as a separate field, the
platform appends it to the password itself, which is what Salesforce expects
from an untrusted IP address.
That token is cached and reused until a call comes back 401, at which point
the connector re-authenticates once and retries. There is no polling of a
token endpoint on a timer, and no refresh token.
⚠ Note
This is worth stating precisely, because the two labels above invite the wrong conclusion. Whichever of them you pick, the engine performs the password grant. Salesforce's client-credentials flow is not implemented for this connector; neither is the browser-redirect authorization-code flow, nor a JWT or SAML bearer-assertion flow. Enabling client credentials on the Connected App will not make the connection work — the org-wide "allow OAuth username-password flows" setting is what this connector depends on. An earlier version of our own setup guide described the wrong flow; we found it in live use on 30 July 2026 and corrected it, and we would rather publish that than let you rediscover it.
The platform does implement a signed SAML bearer assertion exchange — building a short-lived assertion, signing it with an established XML-signature library rather than hand-rolled crypto, and trading it for an access token — but that flow belongs to the SAP SuccessFactors connector, whose API clients are configured for exactly that shape. It is not wired to Salesforce.
Where the credentials live
The connector runs either in the control plane or through a tier-3 agent in your own network. In agent mode the credentials are resolved locally by the agent and never cross the wire; the control plane sends configuration and receives results. Tunnel mode — bridging HTTP through the agent while the engine runs centrally — is not available for this connector; it is offered for the generic REST and SCIM engines only. See Tier-3 Hybrid Architecture.
Importable objects (5)
Object types the wizard offers to import out of the box.
Users
- name:
users - iga_target:
identity - path:
/services/data/v60.0/query?q=SELECT+Id,Username,Email,FirstName,LastName,Name,IsActive,Title,Department,ProfileId,UserRoleId,ManagerId+FROM+User
All Salesforce users (active + inactive).
Default field mappings:
| IGA field | Expression | Required |
|---|---|---|
business_id |
{{ Id }} |
✓ |
identity_id |
{{ Username }} |
✓ |
email |
{{ Email }} |
|
first_name |
{{ FirstName }} |
|
last_name |
{{ LastName }} |
|
display_name |
{{ Name }} |
|
function |
{{ Title }} |
|
department |
{{ Department }} |
|
status |
{{ 'active' if IsActive else 'suspended' }} |
|
manager_id |
{{ ManagerId }} |
|
native_account_name |
{{ Username }} |
✓ |
identity_business_id |
{{ Email|lower }} |
|
is_privileged |
{{ false }} |
|
salesforce_id |
{{ Id }} |
|
profile_id |
{{ ProfileId }} |
|
role_id |
{{ UserRoleId }} |
Profiles
- name:
profiles - iga_target:
entitlement - path:
/services/data/v60.0/query?q=SELECT+Id,Name,Description,UserLicenseId,UserType+FROM+Profile
Salesforce profiles — determine permissions + UI access. One per user.
Default field mappings:
| IGA field | Expression | Required |
|---|---|---|
business_id |
{{ Id }} |
✓ |
name |
{{ Name }} |
✓ |
description |
{{ Description }} |
|
native_identifier |
{{ Id }} |
|
risk_level |
{{ 'high' if ('Admin' in (Name or '') or 'System' in (Name or '')) else 'low' }} |
|
user_type |
{{ UserType }} |
|
privileged |
{{ 'Admin' in (Name or '') or 'System' in (Name or '') }} |
Permission Sets
- name:
permission_sets - iga_target:
entitlement - path:
/services/data/v60.0/query?q=SELECT+Id,Name,Label,Description,LicenseId,IsCustom+FROM+PermissionSet
Permission Sets — fine-grained permissions stacked on top of Profiles.
Default field mappings:
| IGA field | Expression | Required |
|---|---|---|
business_id |
{{ Id }} |
✓ |
name |
{{ Label|if_null(Name) }} |
✓ |
description |
{{ Description }} |
|
native_identifier |
{{ Id }} |
|
risk_level |
'medium' |
|
is_custom |
{{ IsCustom|to_bool }} |
Permission Set Groups
- name:
permission_set_groups - iga_target:
entitlement - path:
/services/data/v60.0/query?q=SELECT+Id,DeveloperName,MasterLabel,Description,Status+FROM+PermissionSetGroup
Bundles of permission sets — efficient for role-based access.
Default field mappings:
| IGA field | Expression | Required |
|---|---|---|
business_id |
{{ Id }} |
✓ |
name |
{{ MasterLabel|if_null(DeveloperName) }} |
✓ |
description |
{{ Description }} |
|
native_identifier |
{{ Id }} |
|
risk_level |
'medium' |
|
status |
{{ Status }} |
Public Groups
- name:
public_groups - iga_target:
entitlement - path:
/services/data/v60.0/query?q=SELECT+Id,Name,DeveloperName,Type+FROM+Group+WHERE+Type+IN+('Regular','Role','RoleAndSubordinates')
Sharing groups — for data-access rules.
Default field mappings:
| IGA field | Expression | Required |
|---|---|---|
business_id |
{{ Id }} |
✓ |
name |
{{ Name }} |
✓ |
description |
Sharing group type: {{ Type }} |
|
native_identifier |
{{ Id }} |
|
risk_level |
'low' |
|
type |
{{ Type }} |
Four access objects — one governed today, three on the roadmap
Salesforce spreads access across four object types, and the difference between them shapes what governance can do. Only the second is read and governed by this connector today — the other three are real Salesforce concepts worth understanding, not yet synced:
- A profile is mandatory and exclusive — every user has exactly one, and it sets the baseline permissions and UI. Because it is a slot rather than a collection, "grant a profile" is a replacement, not an addition. Not yet read.
- A permission set is additive. Users can hold many, and this is the object the platform grants and revokes. Governed today. The read explicitly excludes the profile-shadow permission set Salesforce mints one per profile, and the hidden aggregate permission set a permission set group is backed by — neither is a permission set an admin ever picks by hand.
- A permission set group bundles permission sets, which is how larger orgs keep the additive layer manageable. Not yet read — an assignment made via a group is currently skipped during sync rather than misattributed to its hidden aggregate permission set.
- A public group governs data sharing rather than functional permission. Not yet read.
The default risk mapping marks a profile as high-risk when its name contains "Admin" or "System". Like every name-based heuristic in the catalogue, that is a starting point for triage rather than a classification — refine it once you can see your own estate. (This heuristic ships in the catalogue ahead of the profile read above landing — it takes effect once profile access is synced.)
Reading: SOQL, and how paging is handled
Reads run as SOQL queries against the org's data API. Salesforce returns a
first page along with a nextRecordsUrl whenever more records exist, and the
connector follows that chain until it is absent — so a result set larger than
one page is retrieved in full rather than silently truncated at the first page.
Three correlation keys come off the user record: the eighteen-character
Salesforce Id (stable across renames, and used as the account's external
id), the Username (unique across all Salesforce orgs, used as the native
account name), and the lower-cased Email (the usual join key to an identity).
Which one your account rules should correlate on depends on how your org
provisions usernames — see Account Rules.
Writing: assignments, state, and idempotency
The write path covers four operations, and each is idempotent in the way that matters for reconciliation — running it twice does not produce an error or a duplicate:
| Operation | What it does in Salesforce | Repeat behaviour |
|---|---|---|
| Grant | Creates a PermissionSetAssignment |
Salesforce's duplicate error is settled as success |
| Revoke | Finds the assignment, then deletes it | No assignment found is settled as success |
| Disable | Sets IsActive to false on the user |
Naturally idempotent |
| Enable | Sets IsActive to true on the user |
Naturally idempotent |
| Update | Patches mapped attributes on the user | An empty change set is a no-op |
That idempotency is not a convenience — it is what lets reconciliation converge safely. The engine's job is to make the actual state match the expected state, and it must be able to re-assert a decision after a partial failure without the second attempt failing for the wrong reason. See Reconciliation.
The integration user needs enough permission to do all of this: API access, user management for the enable/disable/update operations, permission-set assignment for grant and revoke, and — easy to miss — the ability to read setup and configuration. Without that last one, permission sets and profiles come back as empty results rather than an error, which looks like an org with no access objects rather than a permission problem.
What this connector does not do
- It does not create Salesforce users. The connector governs users that already exist; a new user is created by your own process and picked up on the next sync.
- It does not delete anything. A leaver's Salesforce user is deactivated, never removed, so the record and its history survive.
- It does not write profiles, roles or group membership. Permission-set assignment is the write surface. Profiles, the role hierarchy and public groups are not yet read either (see "Four access objects" above); changing them stays a Salesforce administration task.
- It reports no activity signal. Salesforce exposes a last-login date as an importable attribute, but this connector does not feed the platform's activity ingest. Grants on Salesforce are therefore treated as usage unknown, not as dormant — the platform will not assert that an assignment is unused on a system it has never watched. That rule, and why it exists, is explained under Microsoft Entra ID.
- It reports no MFA state. Salesforce accounts contribute nothing to MFA coverage; they are neither counted as registered nor as unregistered.
- It scans no unstructured content. Files and content in Salesforce are out of scope for the unstructured lens.
Onboarding setup checklist
Create a Connected App in Salesforce with the OAuth 2.0 username-password flow, give it the 'API Enabled' + 'Manage Users' + 'Assign Permission Sets' permissions, and collect the Consumer Key + Secret along with the integration account's username, password and security token.
Estimated time: ~20 min. The wizard exposes this checklist as a drawer (📋 button) during onboarding. See the Onboarding wizard walkthrough for context.
Further reading: