AI sales tools break after migrating from Salesforce Classic to Lightning because Lightning uses a different page architecture, stricter API permissions, the Lightning Locker security layer, and changed metadata references. Tools built against Classic's Visualforce DOM, older API versions, or hardcoded field URLs lose access to data and stop rendering correctly.
The Core Architecture Shift
Classic and Lightning aren't two skins on the same engine. Lightning Experience is a single-page application built on the Aura and Lightning Web Components (LWC) frameworks, while Classic served server-rendered Visualforce pages. Most teams get this wrong: they assume the migration is cosmetic and that anything connected via the API keeps working. It doesn't.
When an AI sales tool injects UI elements, scrapes the DOM, or relies on specific page URLs, it's coding against the old Visualforce structure. After migration, those selectors point at elements that no longer exist. The tool either renders nothing or throws JavaScript errors that fail silently inside the Lightning container.
Lightning Locker Service Blocks DOM Access
The biggest silent killer is Lightning Locker Service, a security layer that sandboxes JavaScript components. Locker enforces strict DOM isolation, so a third-party script can't reach into another component's elements the way it could in Classic.
AI tools that previously read field values straight off the page or injected buttons into the record layout get blocked. Locker also restricts access to window, document, and global variables, which breaks browser-extension-style integrations and any tool relying on shared global state. If your AI assistant used to pop up next to the contact's email field and now shows nothing, Locker is usually the culprit.
API Version and Permission Changes
Lightning enforces tighter field-level security and sharing rules than many Classic orgs ever did. A tool that connected through a service account with broad Classic permissions can suddenly hit INSUFFICIENT_ACCESS_OR_READONLY errors because Lightning surfaces permission gaps that Classic quietly ignored.
Three common API-layer failures:
- Deprecated REST/SOAP API versions — tools pinned to old API versions (say, v34.0) may lose access to objects or fields restructured during migration.
- Changed object metadata — custom fields, record types, and page layouts often get renamed or reorganized, breaking hardcoded field references in the integration mapping.
- OAuth scope mismatches — Lightning's connected app model can require re-authorization with updated scopes before data syncs resume.
This matters most for tools that feed CRM data into outbound workflows. If your enrichment or sequencing engine relies on clean field mapping, a broken sync degrades everything downstream, including how AI handles personalized cold email outreach that pulls from contact records.
URL Structure Differences
Classic record URLs looked like /003... with a 15-character ID after the domain. Lightning uses a hashed routing scheme like /lightning/r/Contact/003.../view. Any AI tool that built deep links, parsed the URL to detect which record a rep was viewing, or redirected users back into Salesforce will break on these new paths.
This hits Chrome-extension sales assistants hardest. They typically watch the URL to know context. After migration, the listener never fires because the pattern it expects is gone.
Visualforce and Canvas App Embedding
Many Classic-era AI tools embedded as Visualforce pages or s-controls inside record layouts. In Lightning, those need to be re-exposed as Lightning components, wrapped in lightning:availableForFlowScreens, or added through the Lightning App Builder. A Visualforce page that worked fine in Classic might load inside an iframe in Lightning with different sizing, CSP headers, and session handling, causing blank panels or Refused to display in a frame console errors from Content Security Policy.
How to Diagnose and Fix the Breakage
Start with the browser console. Open Lightning, reproduce the broken action, and watch for Locker errors, CSP violations, or 4xx API responses. That single step tells you whether the problem is client-side (Locker/CSP) or server-side (permissions/metadata).
| Symptom | Likely Cause | Fix |
|---|---|---|
| Tool UI shows blank or missing | Lightning Locker / CSP | Repackage as LWC, add domains to CSP Trusted Sites |
| Data sync stops, access errors | Permission or API version | Re-grant FLS, bump API version, re-auth OAuth |
| Wrong or no record detected | URL pattern change | Update URL parsing to Lightning routing |
| Buttons/actions disappear | Layout/metadata change | Re-add via Lightning App Builder |
Next, confirm the integration user's profile has field-level access to every object the tool touches. Then verify the connected app's OAuth scopes and refresh tokens. Vendors usually ship a Lightning-ready version, so check whether you're on a current build before custom-patching anything.
Preventing the Problem on Future Migrations
Maintain a sandbox that mirrors production and test every integration there before the org-wide cutover. Document each tool's dependencies: which API version, which fields, which UI injection points. Tools that connect purely through the documented REST API and a properly scoped connected app survive migration far better than those that scrape the DOM or hardcode URLs.
When you're evaluating new AI sales platforms or B2B prospecting tools, prioritize ones that integrate through native Salesforce APIs and ship managed Lightning packages over browser-only overlays. They cost more upfront but won't break the next time Salesforce ships a UI overhaul.
Key Takeaways
AI sales tools break in the Classic-to-Lightning move because Lightning is a different rendering engine, not a reskin. Lightning Locker isolates the DOM, CSP blocks embedded frames, permissions get enforced more strictly, and record URLs change format. Diagnose with the browser console first, confirm API and OAuth access second, and favor API-native, Lightning-packaged tools to avoid repeat failures.