CTI System
A CTI System in Salesforce refers to the complete telephony infrastructure that ties an organization phone platform to Salesforce: the underlying phone system (PBX, cloud-based VoIP, or SCV-hosted Amazon Connect), the CTI Adapter or Connector that translates events between phone and Salesforce, and the Salesforce Call Center configuration that registers the adapter and assigns users.
Definition
A CTI System in Salesforce refers to the complete telephony infrastructure that ties an organization phone platform to Salesforce: the underlying phone system (PBX, cloud-based VoIP, or SCV-hosted Amazon Connect), the CTI Adapter or Connector that translates events between phone and Salesforce, and the Salesforce Call Center configuration that registers the adapter and assigns users. Together these components let agents place, receive, and log calls from inside Salesforce without juggling a separate phone application.
CTI System is the umbrella term, distinct from its parts. The Adapter is the JavaScript code; the Connector is the AppExchange package that ships the adapter plus configuration; the Call Center is the Salesforce registration record; the phone platform is the actual telephony plumbing. People say CTI System when they want to discuss the integration as a whole rather than any single piece. Most enterprise Salesforce deployments operate one CTI System with one phone vendor; some operate parallel systems during a migration.
What makes up a CTI System and how the pieces fit
The four layers of a CTI System
A complete CTI System has four layers. The phone platform layer (PBX, cloud telephony, Amazon Connect, Twilio) handles the actual voice transport. The integration layer (CTI Adapter or Connector) translates events between phone and Salesforce. The Salesforce configuration layer (Call Center record, user assignments, page layouts) registers the adapter and tells Salesforce who has access. The Salesforce business logic layer (Flows, Apex, Lightning components) defines what happens when the adapter triggers a screen pop or logs a call.
The phone platform variants
The phone platform is either on-premises PBX (Avaya, Cisco UCM, legacy hardware), cloud telephony (RingCentral, Five9, Talkdesk, Genesys Cloud, Dialpad), or Amazon Connect (the foundation for Service Cloud Voice). The choice drives latency, scale, regulatory residency, and cost. Most modern Salesforce CTI deployments are cloud-telephony or Amazon Connect; on-prem PBX is increasingly rare.
The Salesforce configuration layer in detail
The Salesforce side of a CTI System includes the Call Center record (registered through the Call Center definition file), Open CTI permission sets, user-to-Call-Center assignments, page layouts that show the softphone panel, and the Lightning console apps where the softphone appears. Without all of these, the CTI System fails in subtle ways: the adapter loads but no users see it, or the adapter screen pops to a record the user cannot view.
How calls flow through the System
Inbound: the phone platform receives the call, routes through ACD logic, and notifies the adapter. The adapter calls Open CTI screenPop with the caller ID, Salesforce opens the matching Contact or Lead, and the agent answers. Outbound: the agent clicks a phone number in Salesforce, the adapter calls the phone platform API to place the call, the call rings the customer, and the adapter logs the call when it ends. The interaction is bidirectional and event-driven across all four layers.
Service Cloud Voice as a fully-integrated System
Service Cloud Voice (SCV) packages the phone platform (Amazon Connect or a SCV-supported partner), the adapter, the configuration, and the Salesforce business logic as one unified product. From the customer perspective, SCV is the simplest CTI System to deploy because Salesforce owns end-to-end. The trade-off is licensing cost and migration from an existing phone platform.
Monitoring and observability for a CTI System
A production CTI System needs monitoring at each layer. Phone platform health (uptime, call quality, voice latency). Adapter health (JavaScript errors, Open CTI failures). Salesforce health (Voice Call save errors, screen pop failures). Business logic health (Flow runs, Apex callouts to telephony APIs). Most enterprise deployments use a combination of vendor-provided dashboards and Salesforce Event Monitoring.
Multi-System deployments
Some orgs run more than one CTI System: a primary phone vendor for the contact center and a different vendor for sales reps, or two phone vendors during a migration. Salesforce supports multiple Call Centers in one org; users belong to one at a time. Switching a user between Call Centers is a Setup change. The complexity is mostly operational, not technical.
How to plan and operate a CTI System
Planning a CTI System is a four-layer exercise. The technical install is the smaller part; the operational design (queues, skills, monitoring, escalation) is what determines whether it succeeds at scale.
- Pick the phone platform
Cloud telephony, Service Cloud Voice (Amazon Connect), or on-prem PBX. Drive the choice from existing vendor relationships, latency requirements, and regulatory residency.
- Pick the CTI Connector for the platform
Each phone platform has one or more Salesforce Connectors. Install the vendor Connector or use SCV native.
- Register the Call Center
Import the Call Center definition file. Configure softphone settings and screen pop rules.
- Assign users and configure permissions
Map agents and supervisors to the Call Center. Grant Open CTI permissions through permission sets.
- Build the Salesforce business logic
Configure Flows for after-call wrap-up, build reports on Voice Call or Task, create custom Lightning components for the agent workspace.
- Set up monitoring and SLA reports
Build dashboards for call volume, average handle time, screen pop success rate, and adapter errors. Configure alerts on threshold breaches.
- CTI System problems can come from any of the four layers. Diagnosis requires checking phone, adapter, Salesforce config, and business logic separately.
- The boundary between phone-platform issues and Salesforce-side issues is sometimes fuzzy. Vendor support contracts should cover end-to-end troubleshooting.
- Salesforce sandbox refresh resets some Call Center configuration; document the post-refresh setup steps for sandbox-driven workflows.
- Multiple CTI Systems in one org are supported but operationally complex. Avoid unless there is a specific business reason.
- Migration between CTI Systems usually requires a parallel-run period where both systems are active. Plan licensing, support, and reporting for the overlap.
Trust & references
Cross-checked against the following references.
- Open CTI Developer GuideSalesforce Developers
- Service Cloud Voice OverviewSalesforce Help
Straight from the source - Salesforce's reference material on CTI System.
- Set Up a Call CenterSalesforce Help
- Event Monitoring OverviewSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does a CTI System include?
Q2. Why is thinking of CTI as a stack useful?
Q3. Where does a CTI issue commonly originate?
Discussion
Loading discussion…