Open CTI & Salesforce Voice
Salesforce Open CTI retirement: the deadline, what changes and what to do next
RocketCX ·
Salesforce Open CTI retires on 28 February 2028. Salesforce states that implementations using the framework will no longer function after that date. If your telephony integration depends on Open CTI, you need a supported replacement before retirement.
The first decision is whether to retain your telephony provider and replace the Salesforce integration, or adopt a different telephony model.
What is being retired?
Open CTI is Salesforce’s JavaScript API for integrating third-party telephony with its interface. It supports functions such as screen pops, click-to-dial, call controls and call logging.
Salesforce is retiring this integration framework. Your carrier, phone numbers and telephony platform are separate components: their future depends on your chosen migration route.
Source: Salesforce’s retirement notice.
What is changing, and when?
| Change | What it means |
|---|---|
| Open CTI is in maintenance mode | Salesforce is no longer adding features or enhancements. |
| Restrictions already apply | Newly created Agentforce Service orgs cannot implement Open CTI. |
| Retirement is set for 28 February 2028 | Salesforce states that Open CTI implementations will no longer function after this date. |
Existing implementations can continue until retirement. That time needs to cover assessment, supplier decisions, implementation, testing and rollout.
Why is Salesforce retiring Open CTI?
Salesforce says the framework limits its ability to deliver newer platform capabilities. It is directing customers towards Salesforce Voice and its more integrated service architecture.
That explains the product direction. It does not remove the need to check how your existing workflows will operate in the replacement.
Source: Salesforce’s retirement explanation.
What could be affected in our organisation?
The impact depends on what your adapter does and what has been built around it.
Start by checking:
- Screen pops: how callers are matched to records and where agents are taken.
- Call logging: which Tasks or other records are created or updated.
- Automation: flows, triggers and integrations that use those records.
- Call handling: routing, presence, transfers, callbacks and voicemail.
- Reporting: dashboards and reports that depend on existing fields or objects.
- Recording access: where recordings are stored and how users retrieve them.
Treat this as an assessment list. It does not mean every component must be replaced.
For example, if an adapter creates a Task that triggers a follow-up flow, answering calls successfully in the replacement is only part of the test. The record and follow-up process must also behave as intended.
Do we have to replace our telephony provider?
Not necessarily. Salesforce documents a partner-telephony migration route that can retain the existing telephony environment where the provider offers a suitable Salesforce Voice-certified managed package.
Before choosing that route, ask the provider:
- Is the replacement integration generally available and supported?
- Which current functions are supported, changed or unavailable?
- What configuration and licensing changes are required?
- Who owns migration delivery and support?
An existing Open CTI adapter is not evidence that a provider’s replacement is ready.
Source: Salesforce’s partner-telephony migration guidance.
When should we start?
Start the dependency assessment now. You can then schedule implementation against confirmed requirements and supplier commitments.
Work backwards from an internal completion date before February 2028. Include time for procurement, configuration, testing, user preparation and stabilisation.
Do not assume a small user count means a simple migration. A heavily customised integration may require more work than a larger standard deployment.
What should we do first?
Assign an owner and produce three outputs:
- Confirmed scope: identify the adapter, provider, users and customisations that depend on Open CTI.
- Supported options: obtain written confirmation of the available replacement routes and prerequisites.
- Delivery outline: document dependencies, costs, responsibilities and testing requirements.
These give you enough information to decide whether the migration fits an existing change programme or needs a separate project.
For architecture choices, dependency assessment and testing, read our technical Open CTI migration guide.
Need help scoping the work? Explore RocketCX’s Open CTI migration services.