CRM and CTI integration: choose a connector or commission a custom build

Start with the workflow, not the connector name

Computer-telephony integration (CTI) connects telephony events and controls with another application. In a CRM workspace, that might mean presenting candidate customer records when a call arrives, offering click-to-dial, or associating a completed interaction with a case. CRM integration is broader: it can also connect data, business processes and background updates that do not belong inside the softphone.

Treat each capability as a separate requirement. A connector that displays call controls does not, by that fact alone, meet your rules for customer matching, case ownership, recording access or writeback. Equally, a background CRM sync is not a substitute for the agent-facing interaction lifecycle. Ask an agent and a CRM owner to describe the complete task, including what happens when the expected information is missing.

• Trigger: which inbound, outbound, transfer or completion event starts the workflow?
• Context: which interaction, customer and case identifiers are needed, and which system owns each?
• Action: what may the agent view, select or change, using which permission?
• Exception: what should happen with no match, multiple matches, a disconnected session or an unavailable CRM?
• Completion: what is written back, how is success confirmed, and who resolves a failed update?

There are three options—not just build or buy

A supported connector is a maintained integration offered for a defined platform combination. Prefer its documented configuration before adding code. Confirm the provider's actual support policy, supported versions, licence requirements and upgrade responsibilities; a marketplace listing alone does not establish all of them.

A connector extension keeps the supported integration for the standard workflow and adds a bounded capability through a documented API, event or extension point. For example, a permitted CRM-side action might retrieve an additional business record after an agent selects the right customer. An extension is only a sensible middle option if its boundary is supported and responsibilities between providers are explicit. Editing a managed package or relying on undocumented browser internals is not the same thing.

A custom integration implements the missing workflow against supported platform interfaces. It need not replace the entire desktop or telephony stack. The smallest viable scope may be an authorised lookup service or a controlled writeback component. However small the codebase, it still needs an owner, deployment arrangements, security review, acceptance tests and a plan for dependency changes.

Use a requirements decision matrix

For each essential workflow, record demonstrated fit, an unresolved question or a confirmed gap. Do not turn an unknown into a pass, and do not average away a failed security or permission requirement. The matrix below is a discussion framework: it assigns no vendor scores and presumes no option is cheaper.

Check API, identity and permission constraints before choosing

First establish the platform contract: product, edition, deployed interface, API version, enabled features, licence entitlement and supported integration surface. Then list the operations the workflow needs—not just the API names. Reading a contact, opening an agent tab and updating a case may have different interfaces, credentials and limits.

Keep agent sign-in, service authentication and customer verification distinct. Successful single sign-on does not prove permission to read every record. A caller's phone number may help find candidates, but it is not proof of identity or permission to disclose a record. A backend service using broad credentials must not expose data that the current agent is not authorised to see.

Map which component holds credentials, how tokens expire or are revoked, and whether access is delegated per user or performed by a service. Test with restricted roles and synthetic records, not only an administrator account. Ask the responsible data and security owners to define permitted fields, recording access, retention and any location restrictions. Do not infer legal suitability from the choice of cloud provider.

Check rate limits and failure contracts on both platforms. Document what the agent sees if lookup fails, whether a write is safely retryable, and how a completion record can be reconciled. Browser policies, embedding restrictions and session expiry may matter as much as a REST endpoint. Establish these constraints in an approved sandbox before committing to the design; do not test with live customer calls or production writes without separate authorisation.

What current platform documentation shows

Salesforce illustrates why lifecycle and interface checks come first. Its Open CTI documentation describes a browser-based JavaScript API, but now says Open CTI is in maintenance mode, with retirement scheduled for February 2028 and no new features. It also says Open CTI is deprecated and unavailable for newly created Agentforce Service orgs, and recommends moving development towards Salesforce Voice. A new integration decision should therefore include the provider's current supported architecture and migration path—not assume that an existing Open CTI example is a suitable long-term starting point. [1]

The same Salesforce documentation distinguishes the Classic and Lightning Experience Open CTI APIs: they behave differently and cannot simply be swapped in custom JavaScript. Check the actual app and UI rather than treating 'Salesforce compatible' as a complete requirement. This is a compatibility example, not a recommendation to start a new Open CTI project. [2]

AWS documents a Salesforce CTI integration consisting of a managed Salesforce package plus an AWS Serverless application deployed into the customer's AWS environment, and recommends starting in a Salesforce sandbox. The linked Amazon Connect CTI Adapter installation guide explains that the adapter and Lambda package versions may differ and directs readers to their compatibility requirements. That is a practical reminder to inventory every deployed component, not just the CRM package. AWS's current administrator documentation uses the Connect Customer name; the linked adapter guide retains Amazon Connect terminology. These documents alone do not establish compatibility with a particular Salesforce Voice configuration or settle the Open CTI lifecycle decision above. [3][4]

Microsoft similarly distinguishes Dynamics 365 Channel Integration Framework 1.0 for single-session model-driven apps from 2.0 for telephony integration in multisession experiences such as Omnichannel for Customer Service and Copilot Service workspace. Its 2.0 overview describes the framework as the interface between a telephony channel and the application; it does not make every provider or channel version interchangeable. Verify the target workspace, framework and channel combination rather than selecting the numerically newest version by default. [5][6]

These are documentation examples, not tested compatibility results, vendor endorsements, partnership claims or proof that icommunix delivered any of these implementations. Confirm current package releases, entitlements and support terms directly with the relevant provider for your environment.

Hypothetical scenario: keep the connector, extend the missing step

Illustrative scenario—not a customer case study or a tested vendor configuration. A contact centre uses a commercial CRM and telephony platform. Assume sandbox evidence shows that a maintained connector meets the team's call-control, customer-selection and interaction-logging requirements. Agents also need to view a delivery status held in a separate order system after selecting the correct CRM contact.

1. Define the extra task: an authorised agent selects a verified customer context and requests delivery status. The requirement is read-only; no order change, recording transfer or additional CRM write is implied.
2. Try documented connector and CRM configuration first. If the existing product can present the required status through supported configuration, retain it without introducing another integration component.
3. If configuration cannot meet the requirement, examine a supported extension. Assume a documented hook can expose the selected CRM record ID and an approved order API can return only permitted status fields. Verify these assumptions; do not infer them from the fact that both systems have APIs.
4. Keep the connector responsible for its existing call workflow. Make the extension's lookup, authorisation, unavailable-status display and support ownership explicit. Avoid sharing a broad service credential with the browser or searching orders solely by caller number.
5. Accept the extension only after demonstrating wrong-customer prevention, denied access, missing orders, timeouts and connector upgrades with synthetic records. A lookup failure must not misleadingly display another customer's cached status.
6. If the supported hook or required permission does not exist, stop and reassess. A separate approved workflow, different connector or changed requirement may be better than replacing the whole desktop. Consider a bounded custom integration only after proving a supported path and assigning ownership.

Under those stated assumptions, an extension is a candidate—not a predetermined answer. If supported configuration covers the task, use it. If policy forbids the cross-system access, neither an extension nor custom development is acceptable. The exercise makes the deciding evidence visible without claiming savings, delivery speed or a successful implementation.

A requirements checklist for connector evaluation

Ask the platform owner, CRM administrator, security/data owner and integration supplier to review this pack together. For each item, record the evidence, its version and date, an accountable owner and an unresolved question where necessary. A product demonstration is useful evidence for the demonstrated path, not proof of every edge case.

• Platform inventory: exact products, editions, UI/workspace, connector and backend package versions, enabled channels, environments and lifecycle notices.
• Workflow catalogue: essential versus optional tasks, triggers, agent actions, transfers, concurrent interactions, completion rules and safe fallback.
• Identity model: interaction/customer/case identifiers, shared or absent caller numbers, duplicate CRM records, agent record selection and verification boundaries.
• Permission map: agent roles, record and field access, service credentials, consent-sensitive data, authorised recording retrieval and negative access tests.
• API and event evidence: documented operations and hooks, quotas, event timing/order assumptions, token renewal, embedding restrictions and unavailable dependencies.
• Data contract: permitted fields, mappings, source of truth, relationship ownership, write confirmation, conflicts, duplicate protection and reconciliation.
• Acceptance evidence: approved sandbox, synthetic fixtures, accessible agent controls, restricted-role checks and demonstrated failure/upgrade paths.
• Ownership agreement: configuration, extension code, infrastructure, licences, upgrades, monitoring, support escalation, runbooks, IP and exit arrangements.

What to establish before discussing scope, cost or delivery time

Separate known requirements from assumptions before asking for an implementation proposal. A useful estimate depends on evidence of the supported integration path, access to an approved test environment, the number of genuinely different workflows, required objects and permissions, failure handling, release process and agreed operating responsibilities. If those are unresolved, identify a bounded investigation and its outputs rather than treating a guessed implementation figure as a commitment.

Compare the whole ownership commitment: connector subscriptions and relevant platform entitlements; configuration and extension work; approved hosting and monitoring; security and acceptance review; maintenance, upgrades and eventual migration. Obtain supplier-specific terms rather than assuming that a prebuilt connector has no operating cost or that custom code has no licence dependencies. This guide provides no price ranges or delivery estimates.

Ask who owns each fault when the CRM, connector, telephony platform and custom component interact. Agree how to reproduce an issue with safe diagnostics, who communicates with the vendor, and what the agent can do while it is unresolved. Record what is excluded and which responsibilities remain with your own platform and data owners.

Choose the smallest supported change that meets the requirement

A supported connector is the right answer when demonstrated fit and ownership are acceptable. A supported extension is worth evaluating when it closes a defined gap without destabilising the standard workflow. Custom engineering becomes relevant when a necessary workflow remains unsupported by those options but can be implemented within the platforms' documented boundaries and your operating model.

If a critical constraint remains unresolved, the answer is not yet 'build'. Obtain the missing evidence, change the workflow or reconsider the platform choice. A clear decision record should explain why the selected option fits, which assumptions were tested, who accepts the remaining risks and what would trigger a review.

• Explore the existing CX solution areas →
• Review software development and integration capabilities →

Resources

• Explore CX solution areas →
• Software development and integration capabilities →
• Discuss your systems and workflows →