Salesloft Salesforce Integration: How It Works, What Broke in 2025

Yes. Salesforce is Salesloft's primary CRM integration, and it runs through Salesloft's native CRM Sync rather than a third-party connector. Per Salesloft's own integration pages, the sync is real-time and bidirectional, keeping leads, contacts, accounts, and opportunities updated and accurate across both platforms automatically. The practical effect is that reps work in Salesloft, running cadences, making calls, sending emails, while Salesforce remains the system of record. Every call made and email sent in Salesloft is automatically recorded as an activity in Salesforce, so managers and RevOps see engagement without anyone logging it by hand. Admins control the whole thing through field mapping with logic rules, configurable field permissions, automation rules, and a customizable sync speed that pulls Salesforce updates every 1, 5, or 10 minutes. There is also a Salesloft Connect Chrome extension for working with Salesloft directly inside Salesforce.

Think of it as two lanes. From Salesforce into Salesloft, the sync imports leads, contacts, accounts, and opportunities, including standard and non-standard account fields, and it detects converted leads so data remaps correctly when a lead becomes a contact. From Salesloft into Salesforce, activity flows back as tasks. Salesloft states that each call, email, and completed cadence step writes to Salesforce with over 30 activity properties, including call duration, call disposition and sentiment, email activity counts, and cadence identifiers, so reporting in Salesforce can distinguish a connect from a voicemail and a first touch from step six of a cadence. Everything is visible in the sync log, which records fields, records, time, and direction for each transfer, and lets admins retry failed syncs and troubleshoot mapping errors instead of guessing why a record did not update.

When someone says the Salesloft Salesforce integration is down, it is rarely a vendor outage. The usual culprit is the connection itself, an OAuth link between a Salesloft user or team and Salesforce that stops working when a token expires or is revoked, often after a Salesforce password change or a deactivated integration user. The second culprit is permissions, where Salesforce field-level security or a missing API permission blocks Salesloft's writes, and the third is field mapping conflicts. The fix path is consistent, check the sync log for failed syncs and their error reasons, retry them, and if the connection is dead, re-authenticate through Salesloft's Settings, then Integrations, then Salesforce, which is exactly the re-auth path Salesloft pointed customers to in August 2025. And once in the integration's history, down was deliberate, when every Drift token was revoked at once.

Between August 8 and August 18, 2025, a threat actor that Google Threat Intelligence Group tracks as UNC6395 used stolen OAuth and refresh tokens tied to Salesloft's Drift chat product to access Salesforce instances belonging to Salesloft Drift customers. Per GTIG's advisory, the actor ran queries against Salesforce objects including Accounts, Opportunities, Users, and Cases, exported data at volume, and then searched the stolen text for credentials, specifically AWS access keys, passwords, and Snowflake access tokens. The actor deleted its query jobs to cover tracks, though logs survived. On August 20, Salesloft and Salesforce revoked all active access and refresh tokens for the Drift application, and Salesforce removed Drift from AppExchange while the investigation ran. The Hacker News reported over 700 potentially impacted organizations. Mandiant's investigation later traced initial access to Salesloft's GitHub environment starting in March 2025, from which attackers pivoted into Drift's AWS environment and obtained the tokens.

Salesforce was not breached in the usual sense, and this was not a platform vulnerability. The attackers presented valid OAuth tokens issued to a legitimate integration, and Salesforce did what any API does with a valid token, it answered. The real issue was what those tokens were allowed to do. A chat widget's integration token could read support Cases wholesale, and support cases are where customers paste the exact secrets the actor was hunting, AWS keys, passwords, Snowflake tokens. That is why GTIG's hardening guidance after the incident focused on the token layer, review and restrict connected app scopes and avoid granting full access, enforce IP restrictions on connected apps, limit which profiles carry API access, and rotate credentials. A token is a standing credential, and its blast radius is precisely its scope. Nobody had asked why a chat tool held a key that opened that much.

Three disciplines separate a contained incident from a catastrophe. First, least privilege, an integration should hold the narrowest scopes that let it do its documented job, because any scope it holds is a scope an attacker inherits with the token. Second, revocability, the incident effectively ended on August 20 when Salesloft and Salesforce revoked every Drift token at once, which is only possible when you know exactly which tokens exist and can kill them centrally. Third, audit, GTIG's guidance leaned on Salesforce Event Monitoring logs to reconstruct what the actor queried from August 8 onward, and even though UNC6395 deleted its query jobs, the underlying logs let defenders see what was taken. Every integration in your stack deserves the same three questions. What exactly can this token read or write, how fast can we revoke it, and what record exists of what it did.

The Drift incident involved an integration that mostly read data, and it still exposed hundreds of Salesforce instances. Now consider the current wave of AI agents that write to the CRM, updating fields, logging outcomes, creating tasks, sending follow-ups. Everything above applies with more force, because a writer with broad scope does not just leak data when it goes wrong, it corrupts the record every team plans against. This is the standard we build ASTRA to at Mindlyft. An agent gets its own scoped identity rather than a borrowed admin login, holds the least privilege its workflow needs, drafts every CRM write for a human to approve before it ships, and leaves an audit trail of what it proposed, who approved it, and what changed. The point of the 2025 incident is not to avoid integrations. It is that surface area, revocation, and evidence are the price of connecting anything to your CRM.

The integration is worth running, and Salesloft restored its Salesforce connection on September 8, 2025 after rotating credentials, isolating Drift infrastructure, and having Mandiant validate containment. Set it up with the incident's lessons applied. Connect through a dedicated integration identity rather than a personal admin login, grant the connected app only the objects and fields your team actually syncs, map fields deliberately instead of accepting every default, and make the sync log a habit so failed syncs and mapping errors surface early. Then hold every other tool that touches Salesforce, especially anything AI-driven, to the same bar. If you want help wiring post-call workflows that write to Salesforce with approvals and an audit trail built in, that is what we do at Mindlyft. We build your first workflow free so you can judge the output before paying, then it is 5,995 dollars a month. Start at mindlyft.in.