Open CTI end-of-life and what it means architecturally
Salesforce has confirmed the retirement date for the Open CTI framework: February 28, 2028. If you run a custom or vendor-supplied Open CTI implementation, that is the date your transition plan works back from, and the target is Service Cloud Voice (SCV).
Open CTI is a browser-based integration mechanism. An external Computer Telephony Integration platform presents softphone controls, screen pops and activity logging inside the Salesforce UI through iframes or embedded components. SCV changes where that machinery lives, which makes it an architectural change rather than an upgrade.
The structural shift from Open CTI to Service Cloud Voice
The difference is where the telephony control plane sits.
Under Open CTI, the telephony infrastructure and its controls are hosted externally and Salesforce acts as a display and logging client. Under Service Cloud Voice, Salesforce owns the agent workspace: call lifecycle management, native controls such as wrap-up and outcome selection, and the link to CRM data all happen on the platform.
Moving from an embedded external component to a native, data-centric workspace is what makes the newer features possible: transcription, summarization and guided workflows through embedded Einstein capabilities.
Technical migration pathways for developers and architects
Your telephony provider (Twilio, Amazon Connect, Microsoft Teams) can stay where it is. What changes is how it plugs into the CRM. You are replacing the integration layer inside Salesforce, not necessarily the telephony infrastructure behind it, so start by assessing licensing against the future state you want.
1. SCV first
Adopt the SCV agent workspace as the standard straight away. You integrate the telephony provider through the Service Cloud Voice infrastructure, which usually means platform events, specific data models and Service Console configuration replacing the old Open CTI methods.
The architectural cost is alignment with the SCV data model for call outcomes and logging: SCV objects and their configuration replace the custom Activity or Task logging paths a legacy Open CTI build relies on.
2. Controlled transition, pilot and validate
Keep the existing Open CTI implementation running in production while you deploy and test SCV with a limited group of users. It is the lower-risk option, which is usually what decides it.
Running both at once needs watching, though. Duplicate call logging and an inconsistent agent experience are what bite during the overlap. Any custom logic that fires on Open CTI events has to be refactored to listen for SCV events, or run as a parallel execution path.
3. Capture first, defer the workspace change
If data quality matters more to you right now than modernizing the workspace, port the reliable capture of voice activity into Salesforce records first. Newer integration patterns can feed the SCV data model without moving agents onto the full SCV workspace, which buys time for the workflow and training changes.
Telephony platform considerations, Microsoft Teams included
If unified communications run through something like Microsoft Teams, keep the separation of concerns explicit. PSTN connectivity, routing policies, user identity and dial plans stay managed in the external telephony administration center, such as the Teams Admin Center. SCV manages the agent's interaction surface, the controls and the CRM linkage.
That split lets IT keep its enterprise agreements and governance for calling infrastructure while the Service Cloud agent experience moves on.
Planning the technical migration
Audit the Open CTI logic first: every piece of custom JavaScript, all the configuration metadata, and any Apex class that depends on Open CTI APIs or on DOM manipulation tied to the embedded softphone panel.
Then map the existing activity logging patterns, custom Tasks and Activities included, onto the Service Cloud Voice data model, so historical reporting still lines up.
Refactor the workflows next. Find every Process Builder, Flow and Apex Trigger that fires on call disposition, wrap-up completion or CTI events. Each one has to be re-pointed at the creation or update of the matching SCV record.
Then pilot. Deploy the SCV integration mechanism, which often needs specific managed packages or configuration flows, to a small user group and test the call flow end to end, along with data persistence and the automation hanging off it.
Key takeaways
The 2028 retirement date means planning the architecture well ahead of it. Migrating to Service Cloud Voice moves the integration from browser embedding to native Salesforce control, so most of the work is refactoring logic tied to old CTI events and aligning data capture with the SCV record model. Build for adaptability while you are in there: the AI capabilities in the native workspace will land on whatever structure you leave behind.
Leave a Comment