Salesforce
Governing Salesforce profiles, permission sets and licenses.
SailPoint uses the Salesforce API to aggregate users, profiles and permission sets and provision changes.
- Salesforce connector type: a REST/API-based connector
- Onboarding: aggregate then correlate
- SailPoint can create/deactivate Salesforce users and manage profiles and permission sets.
- Common issues covered in troubleshooting
Salesforce is often a crown-jewel SaaS application holding sensitive customer and commercial data, so governing who has access, and at what profile and permission-set level, matters. SailPoint aggregates Salesforce users and their access and provisions changes through the lifecycle.
Connector type and how it connects
The Salesforce integration is a REST/API-based connector. It uses the Salesforce API authenticated with OAuth. As with every connector, the flow is the same: authenticate to Salesforce, read accounts and entitlements during aggregation, and write changes during provisioning.
Onboarding the source
- 1. Configure the connection and credentials for Salesforce.
- 2. Map the account schema, mapping Salesforce users, profiles, permission sets and (where relevant) license types to SailPoint accounts and entitlements.
- 3. Set the correlation logic so Salesforce accounts attach to the right identities (typically on a stable key such as employee ID or email).
- 4. Run account aggregation and confirm accounts and entitlements load.
- 5. Verify correlation, watching for uncorrelated/orphan accounts.
Provisioning capabilities
SailPoint can create and deactivate Salesforce users and manage profiles and permission-set assignments, driven by roles, requests and lifecycle events. Deactivation on leaver is especially valuable given per-user licensing costs.
Entitlements and what to govern
Govern profiles and permission sets, which together determine what a Salesforce user can see and do. Note that profiles are broad and permission sets additive; certify both.
Troubleshooting
When Salesforce aggregation or provisioning fails, work through the usual causes in order:
- Confirm the OAuth connected-app credentials are valid.
- Verify the integration user has admin rights for user and permission management.
- Check API access and any IP restrictions on the Salesforce org.
- Validate profile/permission-set schema mapping.
Common pitfalls
- Credential expiry (tokens/secrets) silently breaking the connector.
- Insufficient rights on the Salesforce service account for the operations you need.
- Schema or correlation misconfiguration leaving accounts uncorrelated.