CTI Integration with SAP Sales Cloud V2: A Technical Guide

Your sales team picks up the phone. The caller’s name, company, and last interaction should appear on screen before they say hello. That’s CTI — Computer Telephony Integration. Simple concept, complex implementation.

SAP Sales Cloud V2 doesn’t ship with a built-in CTI adapter. It provides the APIs and the UI shell. You build (or buy) the integration. We’ve done both — our Engage CTI product handles this for multiple customers. Here’s what the architecture looks like and where the pitfalls are.

Architecture overview

A CTI integration with Sales Cloud V2 has four components:

Telephony provider. Your PBX or cloud telephony system — Cisco, Genesys, RingCentral, Teams Phone, or any SIP-based provider. This is where calls actually happen.

CTI middleware. A server-side component that bridges the telephony provider and Sales Cloud V2. It translates telephony events (incoming call, call connected, call ended) into CRM actions (screen pop, create activity, log call). In our architecture, this runs on SAP BTP.

Sales Cloud V2 APIs. REST APIs for looking up contacts by phone number, creating phone call activities, and retrieving account context. V2’s API-first design makes this clean.

Client-side widget. A UI component embedded in the Sales Cloud V2 shell that shows call controls (answer, hold, transfer, end) and caller information. This runs as a side-by-side extension using V2’s shell plug-in framework.

Data flow for an inbound call

1. Call arrives at the telephony system. The PBX sends a call event to the CTI middleware via WebSocket or webhook.
2. Middleware extracts the caller’s phone number and queries the Sales Cloud V2 API: GET /sap/c4c/api/v1/phone-call-collection?$filter=phone eq '{number}'. (In practice, we search across accounts, contacts, and individual customers.)
3. If a match is found, middleware pushes caller context (name, account, open opportunities, recent interactions) to the client-side widget via WebSocket.
4. The widget triggers a screen pop — navigating Sales Cloud V2 to the matched contact or account record.
5. When the call ends, middleware creates a phone call activity in V2 with duration, direction, participants, and notes.

The entire flow takes under 2 seconds from ring to screen pop. Anything slower and users lose trust in the system.

Key technical decisions

WebSocket vs. polling

The client-side widget needs real-time call events. Polling the middleware for “is there a call?” every second creates unnecessary load and adds latency. WebSocket connections between the widget and middleware deliver events in milliseconds.

We use a WebSocket server on BTP (Node.js) that maintains persistent connections with each active Sales Cloud V2 session. When a call event arrives from the telephony system, it’s pushed to the right user’s WebSocket connection instantly.

Phone number matching

This sounds simple. It isn’t. Phone numbers come in many formats: +41 44 123 45 67, 044 123 45 67, 0041441234567. Your middleware needs to normalise numbers before searching.

We normalise to E.164 format (+41441234567) and search against a normalised field in V2. Sales Cloud V2 stores phone numbers as entered by users — which means inconsistent formats. Our middleware handles the normalisation on both sides: normalise the incoming caller number AND normalise the V2 stored numbers during comparison.

Pro tip: build a phone number index. Querying V2’s API with wildcard phone searches on every call is slow. We maintain a lightweight lookup cache (Redis on BTP) that maps normalised phone numbers to V2 entity IDs. The cache refreshes every 15 minutes and on entity update events.

Authentication

The middleware needs to call Sales Cloud V2 APIs on behalf of users. We use OAuth 2.0 with SAP IAS (Identity Authentication Service) as the identity provider. The widget handles the initial OAuth flow; the middleware uses refresh tokens for API calls.

For telephony-to-middleware authentication, it depends on the provider. Cisco and Genesys use API keys. Cloud providers like RingCentral and Teams use OAuth. The middleware abstracts this — adding a new telephony provider means implementing one adapter interface.

Call logging

Every call creates a phone call activity in Sales Cloud V2. We log:

• Direction: inbound, outbound, missed
• Duration: start time, end time, talk time
• Participants: caller, called party, any transferred parties
• Account context: which account/contact was matched
• Notes: reps can add notes during or after the call via the widget
• Recording link: if the telephony system records calls, we store the recording URL (not the file)

The activity is created via POST /sap/c4c/api/v1/phone-call-collection. V2’s API accepts all these fields natively — no custom objects needed.

Supported telephony providers

Our Engage CTI product currently supports:

Adding a new provider typically takes 2-4 weeks of development.

Common pitfalls

Latency kills adoption. If the screen pop appears after the rep has already asked “who’s calling?”, nobody will use it. Target under 2 seconds. Test with real call volumes, not just demos.

Phone number data quality. If your V2 data has phone numbers in 15 different formats, matching fails. Clean your data before going live. Run a phone number normalisation script across all accounts and contacts.

WebSocket stability. WebSocket connections drop. Corporate proxies, VPNs, and network switches interrupt them. Implement automatic reconnection with exponential backoff. Show a clear “disconnected” indicator in the widget so reps know when CTI isn’t active.

Multi-tab handling. Sales reps open multiple browser tabs. The CTI widget should only be active in one tab. We use a leader election pattern (BroadcastChannel API) to ensure screen pop happens in exactly one tab.

Call transfer context. When a call is transferred, the context should follow. The second agent should see the same screen pop. This requires tracking call sessions, not just individual call legs.

Compliance. Call recording and logging have legal requirements that vary by jurisdiction. In Switzerland, both parties must consent to recording. Your CTI solution needs configurable recording controls.

Deployment on BTP

Our CTI middleware runs on SAP BTP Cloud Foundry:

• Node.js application with Express for the REST API and WebSocket server
• Redis for the phone number lookup cache and session management
• SAP Integration Suite for reliable event delivery from on-premise telephony systems
• XSUAA for authentication and tenant isolation

The widget is deployed as a Sales Cloud V2 shell plug-in — a small JavaScript application that loads inside the V2 shell frame.

For multi-tenant deployments (multiple customers on one middleware instance), we use XSUAA tenant isolation. Each customer’s telephony events are routed to their tenant only.

Getting started

CTI integration is a high-impact project. When it works, it changes how your sales team handles every phone interaction. The technical implementation is manageable if you plan for the details: phone number quality, latency targets, and WebSocket reliability.

Ready to connect your phone system to SAP Sales Cloud V2? Our Engage CTI product is production-ready. Get in touch.