.png)
Connect Rippling and Salesforce to automate user provisioning, permission management, and SSO — so sales teams get the right CRM access on day one and former employees are locked out the moment they leave.
Before configuring the integration, we audit the client's existing Salesforce user list against their Rippling employee records. Personal email addresses, accounts for departed employees that were deactivated manually rather than deprovisioned, and permission sets that don't reflect current roles are all common findings that need to be resolved before Rippling provisioning goes live.
We then connect Salesforce through Rippling's App Shop, configure the provisioning rules using Supergroups that reflect the client's sales org structure, and map Salesforce permission sets and profiles to the appropriate Rippling role and department attributes. For companies with complex permission structures — different access levels by territory, product line, or seniority — we design the Supergroup logic to handle each case automatically.
We run a full provisioning and deprovisioning test before sign-off, confirming that new hire access is correct and that termination immediately deactivates the Salesforce account without requiring a manual step from RevOps or IT.
For US companies, the Salesforce System Administrator credentials required to connect the integration are often held by a third-party Salesforce admin or RevOps contractor rather than the HR team — coordinate access before the implementation session to avoid delays. For Canadian companies, Salesforce offers Canadian data residency options but Rippling employee data originates in the US by default; confirm how PII flows from Rippling into Salesforce against any PIPEDA obligations before configuring the integration. ROW companies should review applicable data residency requirements for their jurisdiction before enabling employee attribute sync.
Rippling manages Salesforce as an IT-provisioned application — when a new hire is added in Rippling, their Salesforce account is created automatically based on provisioning rules you define. Permission sets and profiles are assigned based on the employee's role and department in Rippling. When an employee leaves, their Salesforce account is deactivated immediately as part of the Rippling offboarding workflow, with no manual step required from Salesforce admins or RevOps.
No — Rippling's native Salesforce integration is focused on user lifecycle management: provisioning, deprovisioning, SSO, and attribute sync. It does not natively sync payroll data, compensation structures, or commission records into Salesforce objects. If you need bidirectional data flow between Rippling payroll and Salesforce CRM records, that typically requires a middleware tool like Make or a custom integration. thePeopleStack can scope and build this if required.
Rippling assigns Salesforce permission sets and profiles dynamically based on the employee's attributes in Rippling — role, department, location, or any custom field. When a sales rep is promoted to manager or moves to a different territory, their Salesforce permissions update automatically to match. This eliminates the manual permission management that typically falls to Salesforce admins or RevOps every time the org chart changes.
The most common issue is existing Salesforce accounts tied to personal email addresses rather than work emails. When Rippling attempts to provision a Salesforce account for a new hire or match an existing employee, a personal email on the Salesforce side creates a conflict that requires manual reconciliation before the sync runs cleanly. Audit your Salesforce user list for personal emails before enabling Rippling provisioning.
Yes — Salesforce is a common provisioning configuration in mid-market Rippling implementations, particularly for sales-led organizations. We handle the App Shop connection, provisioning rule design, permission set mapping, and reconciliation of any existing Salesforce accounts before go-live. We also configure the offboarding deprovisioning test to confirm access is cut correctly before the integration goes live.
.svg)
