Salesforce Open CTI Retirement: What Mobile Teams Should Audit Before 2028
Salesforce has confirmed that Open CTI is in maintenance mode and will be retired on 28 February 2028. It is also unavailable for newly created Agentforce Service orgs.
For Salesforce administrators and service leaders, that creates a clear migration deadline. Existing Open CTI implementations need to move to a supported voice architecture before the retirement date.
But mobile teams have a second question to answer.
Will the new architecture capture the calls people actually make when they are away from the Salesforce console?
That question matters because Open CTI retirement is mainly a change to the way telephony connects with the Salesforce user interface. It does not automatically solve the ordinary mobile call gap. A business can complete a technically successful voice migration and still leave calls from native mobile diallers, direct customer callbacks, and conversations in poor data coverage outside Salesforce.
This guide explains what is changing, what is not, and how to audit mobile call coverage before the migration plan becomes fixed.
What is happening to Salesforce Open CTI?
Open CTI is the framework many telephony providers have used to place a softphone and call controls inside Salesforce. It supports familiar functions such as screen pops, call controls, click to call, and call logging within the Salesforce interface.
Salesforce has put Open CTI into maintenance mode. No new features or enhancements are planned. New Agentforce Service orgs cannot implement it, while existing implementations can continue until 28 February 2028. After that date, Open CTI implementations will no longer function.
Salesforce recommends moving to Salesforce Voice. The company is positioning that architecture around closer integration with Omni Channel, transcription, Next Best Action, and Agentforce capabilities.
The deadline is firm enough that waiting is not a sensible strategy. Yet rushing into a replacement based only on feature equivalence can create a different problem. The new platform may reproduce the controlled call centre workflow without accounting for how field teams use mobile phones.
Does the Open CTI retirement affect mobile call recording?
It can, but the answer depends on how the mobile call is captured today.
If a mobile app, softphone, or browser experience depends on Open CTI to present controls or save call activity, that workflow needs to be assessed as part of the migration. If a separate mobile network layer captures cellular calls and sends the resulting activity into Salesforce, the dependency may be different.
The important point is to trace the complete path for each call type. Do not assume that every function described as Salesforce call logging uses the same architecture.
A practical dependency review should establish:
- Where the call begins
- Which telephony service carries it
- Which component records it
- Which component creates the Salesforce record
- Whether Open CTI is involved at any stage
- What happens to the workflow after 28 February 2028
This turns a broad migration project into a set of testable call paths.
Why mobile teams need a separate conversation coverage audit
Most Open CTI migration advice starts with contact centre users. That is understandable. Contact centre agents usually work inside a controlled environment with queues, routing, call controls, and a Salesforce console.
Field teams work differently.
A sales rep may call a customer after leaving a meeting. A surveyor may return a call from a car park. A recruiter may speak to a candidate while travelling. A financial services professional may receive a direct call on the business mobile number the customer already knows.
In these situations, people often use the native mobile dialler because it is immediate and reliable. They may not open Salesforce, launch a separate calling app, or have a strong data connection.
If the replacement voice architecture only captures calls made through its own console or app, Salesforce will still see a selected version of customer activity. The migration may be complete from an infrastructure perspective while remaining incomplete from a conversation perspective.
That is why the project needs two audits:
- A platform dependency audit that identifies what relies on Open CTI
- A conversation coverage audit that identifies which real customer calls reach Salesforce
Both are necessary. One protects service continuity. The other protects the quality of the customer record.
Seven questions to include in the mobile call audit
1. Which teams use Open CTI today?
Start with users, not licences.
Identify every team that makes or receives customer calls, including sales, service, recruitment, field operations, account management, finance, and compliance. Then document which calling method each group actually uses.
The word actually matters. A process document may say that reps call from Salesforce, while call records and interviews reveal that they use their mobile phones whenever they leave the office.
Record the proportion of work that happens at a desk, in the field, from a mobile app, and through the native mobile dialler. The goal is not to judge behaviour. It is to design around reality.
2. Which call paths are captured now?
List the common scenarios and test each one.
- An outbound call started from the Salesforce console
- An inbound call routed through a service queue
- An outbound call made from a provider mobile app
- An outbound call made from the native mobile dialler
- A customer callback to a direct business mobile number
- A call made where mobile data is weak
- A call to an unknown number that is not yet in Salesforce
For each scenario, check whether Salesforce receives the event, the correct user, the correct customer match, the duration, and any configured recording, transcript, summary, outcome, or follow up.
This exercise often exposes a difference between claimed integration and complete coverage.
3. What Salesforce record does each call create?
Open CTI softphones often create completed Task activity. Salesforce Voice workflows commonly use Voice Call records. Some organisations use both models for different channels.
The retirement project is a good moment to decide how those records should coexist.
Ask whether managers can report across them without counting the same conversation twice. Check whether account teams can see a coherent history. Confirm that automation does not fire twice when two systems describe one call.
The best object choice depends on the wider Salesforce design. The practical requirement is simpler: every relevant conversation should have one trustworthy identity, a clear relationship to the customer, and enough context for the next person or workflow to understand what happened.
4. What happens to direct mobile callbacks?
Customer callbacks are an excellent test because they do not follow internal process diagrams.
A customer sees a missed call and taps the number. The call goes to the person they know. If that direct mobile callback bypasses the managed voice platform, it may also bypass recording, transcription, summaries, and Salesforce logging.
Test callbacks to every type of number used by the business. Confirm who owns an unanswered call, how the connected conversation is captured, and what Salesforce receives when the call ends.
A polished console experience is useful, but it does not compensate for missing the return call that moved the deal or resolved the issue.
5. Does the new workflow depend on perfect user behaviour?
Any process that depends on people choosing the right app for every call will produce uneven data.
Training can improve adoption, but it cannot remove the pressure of real work. People will still call from recent calls, answer the number on screen, or use the native dialler when a data based call is unreliable.
During evaluation, ask providers to demonstrate the ordinary path, not only the ideal path. What happens when Salesforce is closed? What happens when the rep does not open the softphone? What happens when the customer calls the mobile number directly?
The answers reveal whether capture is built into the architecture or left to habit.
6. Will recordings and AI outputs remain governed?
Migration is not only about creating a call record. Teams also need to understand what happens to the conversation material attached to it.
Review where recordings are stored, who can access them, how retention is applied, when transcription is appropriate, and how AI summaries are labelled as derived outputs rather than the original conversation.
Also verify what happens to historical recordings and links created through the current telephony setup. A new voice platform should not make older customer evidence difficult to find or interpret.
Legal, compliance, and data protection teams should set the relevant policy. The technical design should make that policy workable across desk and mobile calls.
7. How will you measure coverage after migration?
Do not define success only as moving users off Open CTI.
Measure whether customer conversations are reaching Salesforce with useful context. Relevant checks may include:
- Captured calls by team and channel
- Calls that could not be matched confidently
- Native mobile calls compared with managed voice calls
- Records missing an expected outcome or owner
- Duplicate activity created for one conversation
- Direct callbacks that never reached the expected workflow
- Availability of recordings and transcripts where policy requires them
These checks help administrators distinguish a migration problem from a wider capture problem.
Should mobile teams move everything to Salesforce Voice?
Salesforce recommends Salesforce Voice as the replacement for Open CTI, and organisations should assess that path carefully with their Salesforce and telephony specialists.
The right architecture may still contain more than one calling layer.
A contact centre may need queues, routing, supervisor controls, and a deeply integrated Salesforce workspace. A field team may need ordinary cellular calls to work through the native mobile experience and become Salesforce activity automatically. Those requirements are related, but they are not identical.
The goal is not to force every conversation through one interface. The goal is to make each important customer conversation visible, governed, and usable in Salesforce without creating duplicate or conflicting records.
For some organisations, that means Salesforce Voice for managed service calls and a dedicated mobile capture layer for field conversations. The design should be based on tested call paths, record ownership, reporting needs, and policy rather than a single architecture slogan.
Where RocketCell fits after Open CTI
RocketCell is designed for teams that make normal business mobile calls.
It uses an eSIM or SIM based cellular service so people can call through the native mobile experience without depending on a separate VoIP app or a live data connection for the call. Configured business calls can then be recorded, transcribed, analysed, matched, and logged in Salesforce automatically.
That makes RocketCell relevant to an Open CTI migration for one specific reason: it addresses the mobile conversation path that a browser based telephony change may not cover.
RocketCell does not replace every contact centre, routing, or Salesforce Voice requirement. It provides the mobile capture layer for teams whose customer relationships continue away from the desk.
During migration planning, the useful question is not whether RocketCell replaces Open CTI feature for feature. It is whether the future Salesforce architecture will still see the native mobile calls that matter to sales, service, compliance, and customer handover.
A practical timeline for the migration
The retirement date may feel distant, but telephony migrations touch user experience, routing, reporting, automation, data retention, and customer contact numbers. Mobile coverage deserves time for real testing.
A sensible sequence is:
- Inventory Open CTI dependencies and user groups
- Map every desk and mobile call path
- Define the Salesforce record and ownership model
- Shortlist supported voice and mobile capture options
- Test real scenarios with a small mixed user group
- Compare capture coverage before and after the pilot
- Resolve duplicate records, matching issues, access, and retention
- Move teams in stages with clear success measures
- Retire the old workflow with enough time before 28 February 2028
Starting early gives the business room to discover that a workflow which looks complete in a console does not cover a customer calling a rep directly on a mobile.
Conclusion
The retirement of Salesforce Open CTI is a firm platform change. Existing users need a supported path before 28 February 2028, and new Agentforce Service orgs cannot begin new Open CTI implementations.
For mobile teams, the migration decision should go beyond replacing call controls and screen pops. It should answer a more practical question: will the future Salesforce record include the conversations that happen through normal mobile behaviour?
Audit dependencies and conversation coverage together. Test native dialler calls, direct callbacks, weak data conditions, matching, recordings, transcripts, outcomes, and duplicate activity. Then choose an architecture that reflects how people and customers actually speak.
That is how an Open CTI migration becomes more than a technical replacement. It becomes a chance to close the mobile call gap before the next generation of Salesforce automation depends on it.