Build Your Connector

Starting from the demo connector, replace Open CTI adapter logic with Salesforce Voice connector methods and events.

In the cloned demo connector location, open src/main/connector.js. This file already has VendorConnector and TelephonyConnector fully scaffolded. Your migration task is to replace the mock backend calls in each method with calls to your real telephony system.

DirectionWhat It MeansExamples
Your connector calls SalesforceYour connector publishes an event; Salesforce reacts.publishEvent(CALL_STARTED), publishEvent(HANGUP)
Salesforce calls your connectorYour connector implements a method and returns a promise; Salesforce invokes it when an in-org event occurs. Return a promise with the result; do not call publishEvent() yourself from inside the method.acceptCall(), endCall(), setAgentStatus(), superviseCall()

After cloning the demo connector, consider using AI coding assistants for the mechanical translation of your Open CTI adapter logic into Salesforce Voice connector methods. Because patterns are systematic and each opencti.* call maps to a specific connector method or event, AI agents are helpful for this migration.

Although you can use an AI assistant for certain straightforward tasks, such as translating opencti calls to connector methods, writing unit tests, or generating SOQL for reporting, other tasks require manual insight. Make sure that you check or implement these items yourself:

  • Whether to use enqueueNextState correctly. The timing is subtle.
  • Multiparty event sequencing: AI can generate the call paths, but you should validate each pattern (blind transfer, warm transfer, consult, add caller) manually.
  • Deciding which custom fields belong on VoiceCall vs. a child object: This is a domain decision, not a coding decision.
  • Final Flow construction: The AI gives you the spec; Flow Builder is where you implement.
  • Auth / SSO into your backend: This should be reviewed by a human; AI-generated auth code is a common source of security issues.

Here are sample prompts to start migrating your adapter.

  1. Feed the assistant your Open CTI adapter and related information.

    If your AI tool isn’t able to parse the Salesforce Voice with Partner Telephony Developer Guide, point it to the latest PDF version (available from the guide overview page).

  2. Generate connector methods one at a time. Don’t ask for the whole file at once. Migrate method by method, in priority order.

  3. Repeat for endCall(), dial(), hold(), mute(), setAgentStatus(), wrapUpCall(), etc.

  4. Generate unit tests against the SDK’s test fixtures.

  5. Validate with the CCaaS.html simulator. After generating code, test against the demo connector’s mock backend before connecting your real backend. The simulator catches event-ordering bugs early, such as CALL_CONNECTED before CALL_STARTED, missing voiceCallId, and other rejections the base connector enforces.

  6. Generate Omni-Channel Flow specifications (build in Flow Builder). For Flows (screen pop, post-call automation), AI tools generate Flow specifications and step-by-step build instructions, not deployable Flow XML. Use the AI output as a buildable spec. Build the actual Flow in Flow Builder.

Priority 1 (required for basic calls):

Priority 2 (required for complete experience):

Priority 3 (advanced features):

When your telephony system fires events, translate them using the pattern that’s already in the demo connector’s event publisher:

voiceCallId in callAttributes must be the Salesforce VoiceCall record ID (0LQ…). This is the binding between your call and everything Salesforce does (AgentWork creation, supervisor view, reporting).