Path 2 begins with the same basic assumption as Path 1: the organization likes its current business phone or contact center provider and does not want to replace the phone system simply because Open CTI is going away. The difference is what happens on the Salesforce side.

Instead of moving into Salesforce Voice, the organization replaces Open CTI with an integration that uses the provider’s modern APIs and supported Salesforce integration capabilities. The replacement must be verified to work without both Open CTI and Salesforce Voice. In some cases, the provider may already have a packaged Salesforce integration that can take over many of the functions currently handled by Open CTI. In other cases, the provider may expose the necessary APIs but leave some of the Salesforce integration work to the customer or implementation partner.

This path can materially reduce the amount of Salesforce change required, particularly when the organization’s real need is fairly straightforward: identify the caller, present useful customer context, support click-to-dial, log the completed interaction and keep downstream Salesforce processes informed. It can also avoid Salesforce Voice licensing and preserve a clearer separation between the CRM and phone system.

Compared with Salesforce Voice, less of the voice experience is managed in Salesforce. Agents may use the provider's interface alongside Salesforce, or they may work through an embedded or browser-based experience supplied by the provider. The organization may also give up some of the tighter Agentforce and real-time transcription capabilities that Salesforce builds around Salesforce Voice, relying instead on the provider's own AI and transcription tools where they exist. If a custom integration is required, someone also has to own that software over the long term. For the right organization, those tradeoffs can be preferable to a much larger Salesforce Voice migration.

How this relates to Salesforce’s migration paths

Salesforce's guidance steers customers toward Salesforce Voice, and its developer documentation recommends transitioning development efforts to it. Some providers also position their Salesforce Voice offerings as the path for Agentforce use. Choosing Path 2 can mean that Salesforce's voice-related AI and conversation features are not available in the same way, with the provider's own capabilities filling the gap instead. Before choosing this path, confirm which AI, transcription and Agentforce capabilities you need and how each would be delivered.

The replacement integration must be verified to work without both Open CTI and Salesforce Voice, for the exact product and version.

Start with the integration your provider has today

The first step should be to revisit the existing telephony provider’s current Salesforce strategy. Many Open CTI deployments were implemented years ago and have remained in place because they continued to work. The same vendor may now have a much newer integration model that did not exist when the original adapter was selected. Before designing anything custom, establish whether the provider already offers a managed package, embedded application, browser extension, API-based connector or other Salesforce integration that can replace the retiring Open CTI layer.

Ask the vendor to confirm the Open CTI and Salesforce Voice dependencies of the exact product and version, then test the required functions without those frameworks. A managed package or browser extension can still depend on Open CTI. Can the integration search Salesforce records on an inbound call? How are multiple matches handled? Can an agent click a Salesforce phone number to initiate a call? What activity is written back after the interaction? Are dispositions and recording links supported? Can custom fields be mapped? How is authentication handled? What happens when Salesforce is unavailable? Who owns compatibility with future Salesforce releases?

If the provider already has a mature product that handles most of the requirements, the migration can remain relatively contained. The project may involve configuring the new connector, rebuilding a small amount of Salesforce automation and addressing a handful of gaps rather than introducing Salesforce Voice or creating a custom integration from scratch.

Where the provider has no suitable packaged option, the same architecture can still be built around the provider’s APIs. The difference is that the organization is now taking on more implementation and support responsibility. That can still be a sound decision, but the economics need to include maintenance, monitoring and ownership rather than focusing only on the savings from avoiding Salesforce Voice licenses.

How the architecture is different

With this model, the telephony provider continues to own the contact center. Routing, queues, IVRs, agent status, recordings, carrier services and supervisor tools remain primarily in the CCaaS platform. Salesforce remains the CRM. The integration moves the information required between them without trying to make Salesforce responsible for the phone system itself.

An inbound interaction illustrates the model well. The call can be routed entirely inside the contact center platform. Once the caller is identified, the integration can search Salesforce using the phone number or another identifier and return the relevant customer record. The agent can receive that context either in Salesforce, inside the provider’s application, or through a combined interface depending on what the vendor supports.

When the call ends, Salesforce may receive only the information the CRM actually needs: the agent, direction, duration, disposition, external interaction ID and perhaps a recording or transcript link. A Flow or other automation can then handle any downstream Salesforce process. That design is intentionally more selective than bringing the full contact center data model into Salesforce. A large CCaaS platform can produce enormous amounts of operational data, and there is usually little value in pushing every routing event, agent-state transition or telephony attribute into CRM.

Screen-pop logic still requires careful attention. An existing Open CTI adapter may have years of rules around matching Leads, Contacts, Accounts, Cases, Matters or custom objects. Different departments may use different matching sequences, and duplicate records may have special handling. A packaged provider integration may be able to reproduce some of that behavior through configuration. If it cannot, those rules need to be implemented elsewhere. The migration is a useful time to simplify that logic rather than automatically reproduce every historical decision.

Platform and OEM licensing can materially change the business case

Path 2 deserves particular attention in organizations where most users are on Salesforce Platform licenses rather than traditional Sales or Service Cloud licenses. Industry-specific applications can use Platform or OEM arrangements, but the actual user licenses and contract terms must be checked rather than inferred from the application’s name.

Those customers can face a very different commercial decision from a traditional Sales Cloud or Service Cloud customer. If the organization is already on an eligible Sales or Service license, adding Salesforce Voice may primarily involve the incremental Voice entitlement and the implementation work. A large Platform-license population may have to consider whether moving to Salesforce Voice also requires changing the underlying user licensing.

At scale, that can be significant. An organization with 1,500 Platform users may discover that the cost of moving to Salesforce Voice is not simply the published Voice add-on multiplied by 1,500. If those users also need a different Salesforce base license, the recurring cost can increase considerably.

OEM environments can be more complicated still. A customer may already be paying an industry-software vendor for an application that includes or relies on an embedded Salesforce entitlement. If a second Salesforce license is then required to provide capabilities outside that OEM arrangement, the company may effectively be carrying two substantial software costs for the same population. The details depend heavily on the customer’s Salesforce agreement and the commercial structure of the OEM application, so this should never be treated as a universal pricing rule.

An API-based integration may allow those users to remain on the Salesforce licensing model that already supports their core application while replacing the Open CTI functionality through integration rather than changing the entire Salesforce license stack. An API integration does not expand user entitlements. Standard Leads and Opportunities are not included in ordinary Platform licenses; custom Intake or Prospect objects need their own compatibility review.

User experience, availability and support need to be designed together

The most visible difference from Salesforce Voice is usually the agent experience. An API integration can range from two clearly separate applications to an experience that feels fairly well integrated, depending on what the provider offers. Some agents may work primarily in the CCaaS desktop and use Salesforce for CRM tasks. Other providers may offer an embedded workspace or browser extension that makes the experience feel much closer to the current Open CTI model.

A salesperson who spends most of the day inside Salesforce may be sensitive to additional switching between systems. A contact center agent who already lives in the provider’s desktop may care far less. This is one of the reasons we prefer to put a proof of concept in front of actual agents rather than allowing architecture teams to decide whether the user experience is acceptable based on screenshots.

The more independent architecture also affects availability. If the contact center platform continues to own telephony, the phone system may continue functioning during a Salesforce interruption if its call handling does not depend on unavailable Salesforce services. A Salesforce outage may interrupt screen pops, CRM lookups, call logging or other Salesforce-dependent workflows while the underlying CCaaS platform continues routing calls. Whether that independence is useful depends on the interface. If agents can only reach telephony through something embedded inside Salesforce, they may still be effectively blocked even though the phone system itself is healthy. If call continuity matters, the solution should include a direct path into the provider’s native application and the pilot should test what agents can actually do when Salesforce is unavailable.

Support ownership needs the same amount of thought. A provider-managed connector gives the organization a clearer escalation path because the vendor owns more of the integration product. A custom solution creates more shared responsibility. Salesforce and the CCaaS platform can both be healthy while an OAuth credential, middleware process, integration user, API mapping or Salesforce Flow has failed. A custom API architecture can still be highly reliable, but it needs useful logging, identifiable transaction IDs, retry behavior, alerts and documented support ownership from the beginning.

What the project tends to look like

The first phase is usually a fit-gap exercise. The current Open CTI behavior is inventoried and compared with whatever non-Open-CTI capabilities the telephony provider offers today. That allows the requirements to be separated into what already works out of the box, what can be solved with configuration or Salesforce automation, and what requires custom development.

Architecture follows from that analysis. The design should address authentication, integration identities, Salesforce API usage, data mapping, record matching, call logging, retries, monitoring, middleware and failure handling. For larger contact centers, the team should also model API consumption so the new contact center workload is understood alongside all of the other systems already using Salesforce APIs.

The build can be very different depending on the results of the fit-gap analysis. A mature provider integration may require relatively little custom code. The bulk of the work could be configuration, remediating Salesforce automation and updating reports. A custom solution introduces a larger development workstream around APIs, middleware or Salesforce components.

Testing has to include failure as well as success. The usual agent scenarios still matter, but the team should also test what happens when Salesforce rejects a transaction, authentication expires, the same event is delivered twice or Salesforce is unavailable for a period of time. If the architecture is intended to queue and replay activity later, that behavior should be proven before production.

Cost should be evaluated as total ownership, not just license avoidance

The commercial appeal of Path 2 is easy to understand because it generally avoids purchasing Salesforce Voice simply to maintain the telephony integration. That does not make the API option free. The CCaaS provider may charge for its Salesforce connector. Middleware may have licensing costs. Custom development requires implementation effort and ongoing support. High API usage may have its own implications. Monitoring and operational ownership also carry a cost.

A provider-supported integration can have a very attractive cost profile because much of the maintenance burden remains with the vendor. A heavily customized integration can become expensive over time if every Salesforce or provider change requires specialized development work. The useful comparison is therefore over several years. Licensing, implementation, maintenance, vendor support and internal team effort should all be included.

A hypothetical example

This is an illustrative scenario, not a completed client engagement. Consider a 1,500-agent legal organization running an industry-specific Salesforce application. The users are primarily on Salesforce Platform licenses rather than Sales or Service Cloud. The current contact center provider works well. The dialer is reliable, routing is mature, supervisors know the platform and management has no particular desire to replace it.

Open CTI currently provides screen pops, click-to-dial, automatic Task creation, dispositions and recording links. The initial assumption is that Open CTI retirement means moving all 1,500 users to Salesforce Voice. During the readiness assessment, two things change that conversation.

First, the licensing analysis raises the possibility that Salesforce Voice would require more than adding the Voice entitlement. Because the population currently operates on Platform licensing, there may also be a significant change to the underlying Salesforce licenses required for those users. Second, the existing telephony provider has developed a modern Salesforce integration since the original Open CTI adapter was implemented. Assume the provider confirms that the new integration works without Open CTI or Salesforce Voice and demonstrates record lookup, activity logging and configurable field mappings. It does not support all of the company’s custom Intake-record matching logic, and several existing post-call automations will still need to be rebuilt.

That gives the organization a legitimate alternative. The provider integration can handle the standard contact center functions while a smaller Salesforce or middleware layer handles the company’s unique business rules. Assume the provider also confirms that the dialer, routing, phone numbers and supervisor tools can remain unchanged. The project is no longer a broad Salesforce Voice migration. It is a targeted integration migration with a relatively clear set of custom gaps.

The final decision would still depend on how well agents like the new workflow, whether the support model is acceptable and how the total cost compares over several years. The important result of the assessment is that the organization now has two real architectures to compare rather than assuming there is only one.

Where Path 2 tends to fit

This path is a strong candidate when the organization likes its existing contact center platform and primarily needs Salesforce and telephony to continue exchanging data effectively. It becomes especially attractive when the provider already offers a mature post-Open-CTI integration, when the agent population is large enough for Salesforce Voice licensing to materially affect the economics, or when the organization wants telephony to remain operationally separate from Salesforce.

Platform and OEM environments deserve additional attention because their Salesforce licensing situation can make a Voice migration much more expensive than it first appears. The tradeoff becomes less attractive when the organization wants a highly Salesforce-native voice experience, deep Omni-Channel integration or capabilities that specifically depend on Salesforce Voice. A large custom API solution can also become difficult to justify if the organization does not have the appetite to support it long term.

CommCorrect’s role is to work through those questions before the architecture is chosen. If the existing provider already has a strong integration, we can help validate it, close the Salesforce gaps and support the migration. If an appropriate packaged option does not exist, we can scope a custom API integration, with development and ongoing support responsibilities agreed across CommCorrect and any implementation partners. If the analysis ultimately shows that Salesforce Voice offers enough additional value to justify the project and licensing, then Path 1 may still be the better choice. The decision should come from the requirements, economics and operating model of the contact center rather than from the assumption that Open CTI retirement automatically means Salesforce Voice.

CommCorrect Technologies, LLC

5233 Driscoll Court, Orlando, FL 32812

hello@commcorrect.tech

© 2026 CommCorrect Technologies, LLC. All rights reserved.

Privacy Policy

Terms of Service