# Okta + Salesforce integration > Sync user access, provisioning, and customer data between Okta and Salesforce to cut manual overhead and close security gaps. **Canonical page:** https://tray.ai/connectors/okta-salesforce-integrations/ **Okta connector:** https://tray.ai/connectors/okta-integrations/ **Okta documentation:** https://tray.ai/documentation/connectors/service/okta **Salesforce connector:** https://tray.ai/connectors/salesforce-integrations/ **Salesforce documentation:** https://tray.ai/documentation/connectors/service/salesforce ## Overview Okta and Salesforce are two of the most relied-upon platforms in any modern enterprise stack — one governing who has access to your systems, the other housing your most important customer relationships. When they operate in silos, IT and RevOps teams burn hours manually provisioning accounts, reconciling user data, and chasing down access requests. Connecting Okta with Salesforce on tray.ai enables real-time, bi-directional data flows that keep identity management and CRM operations in sync. Organizations that rely on Salesforce as their CRM and Okta as their identity provider need a reliable bridge between the two to enforce least-privilege access, speed up onboarding and offboarding, and maintain a single source of truth for user data. Without it, a new sales rep might wait days for Salesforce access while IT manually maps their Okta profile to the right permission sets. A rep who leaves the company may keep Salesforce access long after their Okta account is deactivated — a real security and compliance problem. Connecting Okta and Salesforce through tray.ai lets teams automate lifecycle events end-to-end, from the moment a user is provisioned in Okta to the exact Salesforce role, profile, and permission set they receive, while also surfacing Salesforce contact and account data back into Okta for richer user context and smarter access policies. ## Use cases ### Automated User Provisioning and Deprovisioning When a new employee is added to Okta, tray.ai automatically creates a corresponding Salesforce user with the correct profile, role, and permission sets based on their Okta group membership. When that user is deactivated in Okta, their Salesforce account is immediately suspended — no orphaned licenses, no unauthorized access. - Cut time-to-productivity for new sales hires from days to minutes - Eliminate orphaned Salesforce licenses that drive up costs - Enforce zero-touch offboarding to reduce insider threat exposure ### Role-Based Salesforce Access Governed by Okta Groups Map Okta groups directly to Salesforce profiles and permission sets so access always reflects a user's current organizational role. As employees move between teams or get promoted, Okta group changes automatically cascade to the correct Salesforce entitlements — no IT ticket required. - Maintain consistent least-privilege access across the entire sales org - Reduce IT ticket volume for access change requests - Pass compliance audits with a clear, automated access trail ### Salesforce Contact Enrichment from Okta User Profiles When a new user is provisioned in Okta, tray.ai can create or enrich a corresponding Salesforce contact or lead record with verified profile data — name, email, department, manager. Your CRM stays populated with accurate internal stakeholder data without any manual entry. - Keep Salesforce contact records in line with current, verified directory data - Support account-based workflows with accurate internal stakeholder mapping - Reduce duplicate and stale records caused by manual entry ### Automated Salesforce License Reclamation tray.ai monitors Okta deactivation events and triggers a workflow to suspend or deactivate the corresponding Salesforce user, reclaim their license, and log the action for audit purposes. Finance and IT teams get real-time visibility into active license counts without manual reconciliation. - Recover unused Salesforce license costs automatically - Maintain an auditable log of every license reclamation event - Remove the dependency on manual IT processes during offboarding ### Multi-Factor Authentication Compliance Enforcement in Salesforce Use Okta's MFA status and authentication policy data to trigger conditional access workflows in Salesforce. If a user's MFA device is removed or their Okta authentication policy changes, tray.ai can automatically restrict their Salesforce session or flag the account for IT review. - Enforce consistent MFA compliance across all Salesforce users - Automatically flag non-compliant accounts before they become a problem - Reduce manual security audits with continuous policy monitoring ### New Salesforce Opportunity Alerts Routed by Okta Identity When a high-value opportunity is created or updated in Salesforce, tray.ai uses Okta identity data to route alerts to the correct account owner, manager, or approver — so notifications reach the right person based on verified org structure rather than stale CRM role data. - Eliminate misrouted opportunity alerts caused by outdated CRM roles - Use Okta's authoritative directory as the routing source of truth - Accelerate deal review cycles with identity-aware notifications ### Audit and Compliance Reporting Across Okta and Salesforce tray.ai pulls together Okta access logs and Salesforce user activity into a unified compliance report, giving security and compliance teams a complete picture of who has access to Salesforce, what they're doing, and whether their access lines up with current Okta policies — no manual data pulls needed. - Simplify SOC 2, ISO 27001, and Salesforce Shield compliance reporting - Detect access anomalies by correlating Okta and Salesforce event logs - Deliver audit-ready reports on demand without IT involvement ## Templates ### Provision Salesforce User on Okta Activation This template watches for new user activation events in Okta and automatically creates a fully configured Salesforce user with the correct profile, role hierarchy, and permission sets derived from the user's Okta group membership. Connectors used: Okta, Salesforce ### Deprovision Salesforce User on Okta Deactivation Automatically suspends or deactivates a Salesforce user the moment their Okta account is deactivated, reclaims the Salesforce license, and generates an audit log entry — no manual steps required during offboarding. Connectors used: Okta, Salesforce ### Sync Okta Group Changes to Salesforce Permission Sets Monitors Okta group membership changes in real time and updates the corresponding Salesforce user's profiles and permission sets to reflect their new role — access stays current without an IT ticket. Connectors used: Okta, Salesforce ### Enrich Salesforce Contacts with Okta Directory Data When a new user is provisioned in Okta, this template creates or updates the matching Salesforce contact record with verified directory attributes, keeping internal stakeholder data in the CRM accurate and current. Connectors used: Okta, Salesforce ### Weekly Salesforce License Audit Against Okta Active Users Runs a scheduled comparison between active Okta users and active Salesforce licenses to surface discrepancies — such as active Salesforce users who no longer have an active Okta account — and routes findings to IT for remediation. Connectors used: Okta, Salesforce ### Okta MFA Non-Compliance Alert and Salesforce Access Restriction Detects when a Salesforce user's Okta MFA enrollment lapses or is removed and automatically restricts their Salesforce session while notifying the security team — continuous MFA compliance without manual monitoring. Connectors used: Okta, Salesforce ## Challenges Tray.ai solves ### Mapping Okta Groups to the Right Salesforce Profiles and Permission Sets Salesforce has a layered access model — profiles, roles, permission sets, and permission set groups — while Okta organizes access through groups and app assignments. Mapping between these two models consistently and at scale, without hard-coding logic, gets complicated fast, especially as org structures change. **How Tray.ai helps:** tray.ai's data mapping and conditional logic tools let teams build dynamic mapping tables that translate Okta group memberships into the correct combination of Salesforce profiles and permission sets. These mappings can be updated centrally in tray.ai without rewriting integration logic, so it's straightforward to adapt as the organization grows. ### Handling Salesforce API Rate Limits During Bulk Provisioning Events During large-scale onboarding events — an acquisition, a new team buildout — hundreds of Okta activation events may fire at once, each triggering Salesforce API calls that can quickly exhaust rate limits and cause provisioning failures. **How Tray.ai helps:** tray.ai includes built-in rate limit handling, request queuing, and retry logic that automatically throttle Salesforce API calls to stay within allowed limits. Bulk provisioning events are processed in controlled batches, so every user gets provisioned correctly without manual intervention or failed records. ### Ensuring Bi-Directional Data Consistency Without Infinite Loops When both Okta and Salesforce can write to shared fields — user email or department, for example — a change in one system can trigger an update in the other, which then triggers another update back. These loops corrupt data and generate noise in both platforms. **How Tray.ai helps:** tray.ai provides event deduplication, source-of-truth flagging, and conditional workflow branching to prevent loop scenarios. Teams can define which system owns each field and configure tray.ai to skip updates when incoming data matches what's already stored, keeping data clean without runaway workflows. ### Keeping Salesforce User Records in Sync After Okta Profile Updates When an employee changes their name, department, or role, Okta is typically updated first by HR systems. Those changes often don't reach Salesforce in time, resulting in stale user records that cause misrouted reports, incorrect opportunity ownership, and broken approval flows. **How Tray.ai helps:** tray.ai listens for Okta profile update events in real time and immediately pushes the relevant attribute changes to the corresponding Salesforce user record. Field-level mapping ensures only the relevant Salesforce fields are updated, reducing the risk of overwriting CRM-specific customizations. ### Auditing and Proving Compliance Across Two Separate Systems Compliance frameworks like SOC 2 and ISO 27001 require organizations to demonstrate that access to sensitive systems like Salesforce is provisioned and deprovisioned in a timely, documented way. Pulling that evidence manually from two separate platforms is slow and error-prone. **How Tray.ai helps:** tray.ai logs every provisioning, deprovisioning, and access change event with a full audit trail — the trigger, what changed, the timestamp, and the acting system. These logs can be exported on demand or routed automatically to a SIEM or compliance reporting tool, giving auditors what they need without manual data assembly. ## Learn more - Intelligent Integration: https://tray.ai/platform/intelligent-ipaas/ - Merlin Agent Builder: https://tray.ai/platform/merlin-agent-builder/ - Agent Gateway for MCP: https://tray.ai/platform/agent-gateway/ - Book a demo: https://tray.ai/contact/