Path 5 combines a business phone or contact-center replacement with a very different Salesforce strategy from the one we covered in Path 4. The organization has decided that its existing CCaaS or telephony provider is no longer the right long-term platform, so the phone system is going to change. Rather than implementing Salesforce Voice with the new provider, however, the organization connects to the new communications platform through the provider’s own Salesforce integration, APIs, middleware or a custom integration developed specifically for the organization.

This can be an attractive option for companies that want to modernize business calling without adopting Salesforce Voice. It also gives the organization considerably more freedom during provider selection because the shortlist does not have to be limited to vendors whose Salesforce Voice offering matches the required use cases.

The tradeoff is that changing providers is still a significant contact-center migration. IVRs, queues, routing, numbers, recordings, outbound dialing, supervisor workflows and other telephony functions all need to move regardless of how Salesforce is connected. The API architecture can reduce the Salesforce-specific portion of the transformation, but it does not make the CCaaS replacement itself small.

For some organizations, particularly large environments with Platform-licensed Salesforce users or businesses that do not need Salesforce Voice, that distinction can have a substantial impact on both the project and the long-term cost.

How this relates to Salesforce’s migration paths

Salesforce’s recommended destination is Salesforce Voice. Path 5 is for organizations where migrating to Salesforce Voice isn’t required or doesn’t fit, and where the new provider’s integration works without Open CTI.

Provider selection looks different when Salesforce Voice is not a requirement

Path 4 requires the new provider to satisfy two major requirements at once. It needs to be the right CCaaS platform, and its Salesforce Voice implementation needs to be mature enough to support the organization’s desired Salesforce architecture. Path 5 gives the selection process more flexibility.

We still care very much about how the provider integrates with Salesforce, but we are evaluating that integration based on the business functions it needs to perform rather than whether it fits into Salesforce Voice. A provider may already have a modern Salesforce managed package or CRM integration that does not rely on Open CTI. It may provide browser-based functionality, embedded components, a desktop integration or APIs that can be used to create the required workflow. Confirm the Open CTI and Salesforce Voice dependencies of the exact product and version; packaging alone proves neither. Another provider may require a custom integration to meet the Salesforce requirements.

Those differences need to be understood during provider selection rather than after the contract has been signed. For an inbound sales operation, for example, we may ask each provider to demonstrate how an incoming call can identify the appropriate Salesforce Lead or Account, what the agent sees when multiple records match, how a completed interaction is logged, how dispositions get back into Salesforce and where recording links are stored. For an outbound environment, we would want to see how dialing lists are generated, how Salesforce records are passed into the dialer, how outcomes are returned and whether the workflow requires agents to constantly move between applications.

The evaluation should also include what happens when Salesforce is unavailable. If part of the architectural goal is keeping telephony independent from CRM, the provider needs to offer an agent experience that can actually operate without Salesforce rather than merely having a telephony backend that technically remains online. A polished Salesforce demo is useful, but it should be only one part of the provider evaluation. Routing, outbound capabilities, call quality, reporting, AI, workforce management, quality management, carrier strategy, geographic coverage, reliability and the support organization all remain important.

The Salesforce integration may already exist, or it may need to be built

One of the first things CommCorrect would investigate with each prospective provider is whether it already has a supported post-Open-CTI Salesforce integration. If the provider has one, we would want to understand exactly what it does. Some packaged integrations may satisfy most of the requirements with configuration. Others may handle the common functions but leave gaps around custom record matching, data mapping, post-call automation or specialized business objects.

Path 5 does not automatically mean commissioning a custom integration. A new provider may already offer a supported product that works without either Open CTI or Salesforce Voice. That product could be an integration with an external contact-center platform or a telephony application built natively on Salesforce using Lightning Web Components, Apex and supported platform APIs. A native Salesforce app is not necessarily Salesforce Voice, and agents may still be able to make and manage calls inside Salesforce.

Before shortlisting one, ask the vendor to confirm in writing whether the exact product and version use Open CTI or require Salesforce Voice, and demonstrate the required workflows. “Native” and “available on AppExchange” do not establish either point. Confirm Salesforce license compatibility, telephony infrastructure, routing, recording storage, capacity and support ownership. A packaged product may reduce custom development, but it still needs to meet the contact center’s operational requirements.

An organization running a straightforward Salesforce environment might be able to use the provider’s integration largely as delivered. A legal organization working primarily with Matters, for example, or a manufacturer with a heavily customized Salesforce application may need the provider integration extended so the contact-center workflow understands objects and business rules that are unique to that environment.

That does not necessarily mean replacing the packaged integration. A good architecture might use the provider’s product for standard functionality and add a relatively small Salesforce or middleware layer to handle the company’s specialized requirements. If the provider does not have a suitable integration, the alternative is to build one using the provider’s APIs and Salesforce’s supported APIs.

The amount of custom development should be driven by what the business actually needs. If agents only need customer lookup, click-to-dial, call logging, a disposition and a recording link, the integration can remain relatively focused. If Salesforce data is driving sophisticated outbound campaigns, real-time routing, custom screen behavior and several downstream automations, the project becomes more substantial. There is no benefit in recreating a full contact-center platform inside Salesforce through custom development simply to avoid Salesforce Voice. The API option works best when there is a clear division of responsibility between the systems.

Where the phone system and Salesforce responsibilities sit

For an external CCaaS platform, the underlying architecture is similar to Path 2 even though the provider itself is changing. The new CCaaS platform owns telephony. Calls, routing, queues, IVRs, recordings, agent states, supervisor functions and other communications services remain in the system designed to handle them. Salesforce owns CRM data and the business processes that depend on it. The integration connects those two environments where it adds value.

A Salesforce-native provider application can place more of the agent interface, routing logic and call data inside Salesforce while using external telephony services to carry calls. For that model, document the actual division of responsibilities rather than assuming the external-platform architecture described below. Avoiding Open CTI and Salesforce Voice does not by itself make calling independent of Salesforce availability.

An incoming call may be routed completely inside the new CCaaS platform. Once an agent is selected, the provider can query Salesforce for customer context. When the interaction finishes, Salesforce can receive the fields required for CRM history and automation without becoming the repository for every piece of operational telephony data.

For a large contact center, that selectivity matters. Salesforce APIs are shared resources across the org, and integration traffic from the contact center needs to coexist with ERP systems, marketing platforms, data warehouses and every other enterprise integration using Salesforce. During architecture we would estimate the number of Salesforce transactions generated by a typical interaction and apply that to expected call volume. A design where each completed call results in a few meaningful Salesforce transactions will have a very different footprint from one where every agent-state and telephony event is continuously written into CRM.

The same thinking applies to data storage. Detailed call events, recordings and operational metrics can remain in the CCaaS platform if there is no business reason to duplicate them inside Salesforce. Salesforce can store the customer-facing summary and an external interaction ID or recording link while the provider remains the system of record for deeper contact-center data.

Platform licensing, UCaaS strategy and resilience can make this path especially attractive

Path 5 deserves serious consideration when the employees using the integration are not traditional Sales or Service Cloud users. Many industry-specific Salesforce environments operate primarily on Salesforce Platform or OEM licensing. The customer may use Salesforce as the underlying application platform without using a conventional Sales Cloud or Service Cloud operating model. Legal technology, manufacturing applications and other specialized industry products frequently follow this pattern.

In those organizations, adding Salesforce Voice can potentially involve a much broader licensing change than simply purchasing the Voice add-on. Subject to confirmation of the actual licenses and contracts, Path 5 may allow the organization to replace an aging contact-center platform without changing the Salesforce licensing model solely for telephony. If a large Platform-licensed population already has everything it needs from the industry application and only requires the contact center to search Salesforce, display customer information and write interaction results back into CRM, changing the entire Salesforce licensing structure may provide limited additional value. API access does not expand user entitlements: ordinary Platform licenses exclude standard Leads and Opportunities.

Changing providers also creates an opportunity to look at UCaaS and CCaaS together. If the rest of the company uses a separate UCaaS platform for corporate calling, extensions, desk phones, meetings or internal communications, this is an appropriate time to decide whether the contact center should remain separate or whether one provider should serve both populations. Consolidating UCaaS and CCaaS may simplify transfers, number administration, corporate directories and vendor management, but those benefits need to be demonstrated in the proposed configuration. Other companies deliberately keep the environments separate because contact-center requirements are specialized enough that the best CCaaS platform is not necessarily the best corporate communications platform.

Where Path 5 uses an external CCaaS platform, Salesforce and the phone system can remain separate platforms. If Salesforce becomes unavailable, the CCaaS platform can continue operating independently, assuming agents have direct access to the provider application and call handling does not depend on unavailable Salesforce services. Calls can still route, agents can continue talking to customers and supervisors can continue managing the telephony environment even though CRM-dependent parts of the workflow may be temporarily unavailable.

A well-designed integration can account for some of those conditions. Completed interactions can be stored by the CCaaS platform and written back later. Middleware can queue failed transactions. External interaction IDs can be used to prevent duplicate activity from being created when synchronization resumes. The agent interface still needs to support the architecture, so the business-continuity plan should describe what agents can actually do when Salesforce is unavailable, not simply state that the phone system is technically separate.

What the project tends to look like

The overall program is similar in scale to Path 4 because the contact-center provider is being replaced in both cases. The major difference is that the Salesforce workstream can be considerably smaller if the API integration is narrowly designed.

Discovery starts with both environments. The existing CCaaS platform needs to be documented so that routing, numbers, IVRs, outbound functionality, recordings, supervisor tools, integrations and reporting requirements can be carried into the provider-selection process. The Salesforce assessment needs to identify everything Open CTI currently provides and determine which of those functions still matter in the future architecture.

The provider evaluation should include the Salesforce integration as one of the scripted scenarios. We would want to see the prospective provider perform real workflows using Salesforce data, not just show a slide saying Salesforce is supported. Where an out-of-the-box integration exists, the evaluation should identify the gaps before a contract is signed.

After provider selection, two workstreams can proceed together. The CCaaS team configures the new telephony environment while the integration team implements the Salesforce relationship. Number planning, routing, IVRs, carrier services, recordings, outbound workflows and supervisor capabilities are handled on the communications side. Salesforce work may consist of configuring the provider’s connector, rebuilding record matching, modifying automation and reporting, or developing the required API layer.

Where custom integration is needed, authentication, error handling, retries, logging, data mapping and monitoring need to be designed as production capabilities rather than added at the end. Testing then needs to treat the environment as one solution. Failure scenarios should also be included, including what happens when Salesforce is unavailable, when an API transaction times out, when an event arrives twice and when authentication fails.

Because the provider is changing, a pilot remains important even if the Salesforce integration itself is relatively simple. The organization needs real-world evidence around call quality, routing, agent workflow, supervisor tools, reporting and support before moving the full population.

Cost and support depend heavily on the provider integration model

The financial model is different from Path 4 because Salesforce Voice licensing is generally removed from the equation. The organization will still purchase licenses from the new CCaaS provider. Depending on the vendor, Salesforce integration capabilities may be included, sold as an add-on or priced according to a different model. Carrier and usage charges may also change.

Implementation expenses include contact-center configuration, Salesforce integration, number migration, testing, training, reporting and any professional services required by the provider. A custom API integration adds development and ongoing maintenance costs that a packaged connector may avoid. Parallel licensing is another cost that is easy to underestimate because the legacy provider may need to stay active for several months while the new platform is configured and piloted.

One of the bigger differences within Path 5 is whether the Salesforce integration is an actual provider product or a custom solution. When the provider owns the connector, the support model can be relatively clean. With a custom architecture, responsibility becomes distributed. Custom integration needs transaction logging, correlation IDs, retry mechanisms, meaningful alerts and documentation that makes it possible to follow an interaction from the provider into Salesforce.

A hypothetical example

This is an illustrative scenario, not a completed client engagement. Consider a 1,200-agent sales organization using an older CCaaS provider connected to an industry-specific Salesforce application through Open CTI. The Salesforce users are predominantly on Platform licenses. The current contact-center platform works, but the business has become frustrated with outbound dialing limitations, reporting and the provider’s product roadmap. Its CCaaS contract will expire with enough time to complete a migration before the Open CTI retirement deadline.

A straightforward response would be to select a new provider and implement Salesforce Voice, as described in Path 4. During discovery, however, the business determines that its Salesforce requirements are fairly narrow. Agents need customer and account context, click-to-dial, automatic activity logging, dispositions and access to recording links. The organization is not using Omni-Channel for voice and does not have a business case for moving routing or telephony administration into Salesforce.

The licensing analysis also shows that moving such a large Platform-license population into a Salesforce Voice architecture could introduce a substantial recurring cost. The provider-selection process therefore evaluates prospective vendors on their CCaaS capabilities and their ability to support Salesforce through a modern API-based integration.

Assume one shortlisted provider demonstrates a packaged CRM integration that works without Open CTI or Salesforce Voice and covers most of the requirements. It handles Salesforce lookup, activity creation and basic field mapping, but it does not support several of the organization’s custom objects and matching rules. Instead of discarding the provider or moving to Salesforce Voice, the project uses the packaged integration for standard functionality and adds a small custom integration layer for the organization’s specialized Salesforce requirements.

At the same time, the new provider replaces the old dialer, improves outbound campaign management and consolidates the company’s existing UCaaS platform into the same communications environment. The resulting project is still substantial because 1,200 agents are changing phone systems, but the Salesforce portion is much more contained than it would have been under a full Salesforce Voice implementation.

Where Path 5 tends to fit

Path 5 is worth serious consideration when the organization wants to change contact-center providers but does not require Salesforce Voice. It can be particularly attractive when the new provider already offers a mature API-based Salesforce integration, when the organization has a large Platform or OEM user population, when keeping telephony independent of Salesforce is an important resiliency requirement, or when the provider change creates an opportunity to consolidate UCaaS and CCaaS on one communications platform.

The architecture requires more scrutiny when the business wants deep Omni-Channel integration, the Salesforce Voice data model, or functionality specifically tied to Salesforce Voice and Agentforce. It also deserves careful analysis when satisfying the Salesforce requirements would require a large custom integration with significant long-term maintenance.

CommCorrect can support the complete Path 5 program. We can help document the current contact-center environment, develop the requirements, identify and evaluate replacement providers, run structured demonstrations, assist with commercial negotiations, design the Salesforce integration, and support the migration into the new platform. If the selected provider has a suitable Salesforce integration, we can help configure it and close the gaps. If one does not exist, we can scope the custom API integration required to connect the new phone system to Salesforce, with development and support responsibilities agreed across CommCorrect and any implementation partners.

Path 5 can suit organizations that need a new contact-center platform while retaining a focused Salesforce integration.

CommCorrect Technologies, LLC

5233 Driscoll Court, Orlando, FL 32812

hello@commcorrect.tech

© 2026 CommCorrect Technologies, LLC. All rights reserved.

Privacy Policy

Terms of Service