Salesforce CTI Integration: A Buyer’s Checklist and Test Plan
Computer telephony integration, or CTI, connects your phone system with business software. A Salesforce CTI integration can bring calling, caller context, and call activity into a rep’s CRM workflow. The exact capabilities depend on the telephony product and how it connects to your org.
A successful demo should prove more than click-to-call. It should show that the right record appears, the call is associated correctly, the next action is owned, and errors can be recovered without creating missing or duplicate activity.
Use this checklist to evaluate a new integration or audit the one your sales team already uses.
For terminology, start with the CTI definition. If you are building a vendor shortlist, use the separate Salesforce telephony solutions comparison, then apply the acceptance tests below.
CTI is a capability; Open CTI is a specific framework
Keep the distinction clear. CTI describes the connection between telephony and software. Salesforce Open CTI is a particular set of APIs for integrating third-party telephony with Salesforce.
Salesforce’s Open CTI support policy states that the framework is in maintenance mode and scheduled for retirement in February 2028. Ask vendors which parts of their product depend on that framework and what their supported migration path is.
This is an integration acceptance guide, not a retirement timeline. For that separate decision, see our Open CTI migration guide. Do not assume that every telephony integration uses the same architecture.
Map the complete calling workflow
Write down what happens at each stage: select the record, initiate or receive the call, display context, connect audio, capture the outcome, associate the activity, and create follow-up.
Assign an owner to each dependency. A calling vendor may own the softphone and audio connection while your Salesforce team owns validation rules, record permissions, and automation triggered by the completed activity.
| Layer | Question to answer | Evidence to request |
|---|---|---|
| User experience | Where does a rep place, receive, and control a call? | Demonstration in the actual Salesforce app your reps use |
| Record context | How does the integration select a Lead, Contact, or related record? | Single-match, multi-match, and unknown-caller tests |
| Activity data | Which objects and fields are written, and when? | Field map and completed sample records |
| Access | What can a rep, supervisor, and integration user see or change? | Role-specific tests and permission requirements |
| Recovery | What happens when Salesforce rejects or delays a write? | Error visibility, retry behavior, and duplicate-prevention tests |
| Lifecycle | Which Salesforce framework or API dependencies need maintenance? | Supported architecture and upgrade plan |
Test record matching before automatic logging
Use test records with deliberately difficult phone data. Include a contact with a country code, a business number shared by two people, a duplicate lead, a caller with no match, and a contact associated with multiple open opportunities.
The integration should make ambiguity visible. A matching phone number should not silently attach a sensitive conversation to whichever record appears first.
Ask what happens when a rep selects a different related record during or after the call. Confirm whether the association changes and whether reporting continues to reflect the actual rep and outcome.
Define a call activity field map
Agree on the minimum data your team needs before adding custom fields. The following is a suggested acceptance checklist, not a claim that every vendor populates each field by default.
- Actual calling or answering user.
- Call direction, start time, and usable duration.
- Relevant Lead or Contact and any appropriate related record.
- Outcome or disposition with a documented meaning.
- Recording or transcript reference where enabled and permitted.
- Next action, assigned owner, and due time when a follow-up is required.
- A stable interaction identifier that can help detect duplicate writes.
Check the data after a completed call, an unanswered attempt, a transfer, and a returned call. Those are different events; reporting should not treat every attempt as a completed conversation.
For the operational workflow after capture, see automatically logging calls and activities in Salesforce.
Verify click-to-call and screen pops in the right interface
Run the demo in the Salesforce application and interface used by your reps. Do not accept an administrator’s test in a different app as proof that the frontline workflow works.
Salesforce documents click-to-dial integration and Open CTI screen-pop behavior for Lightning Experience. Use the vendor’s supported implementation instructions; the presence of a phone component does not establish that the phone system is enabled or correctly connected.
Test a caller with one match, several matches, and no match. Confirm which page opens, what the rep can see, and whether a record is created only when your workflow calls for one.
Test permissions as a rep and a supervisor
An integration can work for an administrator and still fail for a rep. Test with normal profiles and permission sets, including access to the objects and fields that the integration reads or writes.
For supervisors, verify which teams and conversations they can access. Test restrictions as well as allowed actions. If one manager can see recordings belonging to a team outside their responsibility, resolve the access model before rollout.
Give each integration account only the access required by the supported design. Document who maintains that access and who owns changes when a Salesforce field or validation rule is updated.
Worked acceptance test: a contact with two open opportunities
Create an approved test contact associated with two open opportunities. Place a test call from that contact’s record, discuss only the first opportunity, and complete the normal disposition workflow. Then inspect the saved activity.
| Check | Expected evidence | Failure to investigate |
|---|---|---|
| Person association | The intended test contact is selected | Activity attached to a duplicate Lead or Contact |
| Deal association | The chosen opportunity is recorded, or the integration visibly requires selection | The first open opportunity is silently selected |
| Rep ownership | The actual caller is identifiable | All activities appear to belong only to the integration account |
| Outcome | The disposition has the intended value | A connected conversation is indistinguishable from an unanswered attempt |
| Retry | The same interaction can be reconciled without unintended duplication | A repeated write creates another call event |
Repeat the test for an inbound call and a transfer. Keep a test identifier and screenshots of the selected record and saved activity so the vendor and Salesforce administrator can inspect the same event.
Set a release gate that survives configuration changes
Assign each test an owner, expected behavior, result, and defect reference. Block rollout on incorrect record association, inappropriate access, or an unrecoverable logging failure. For lower-impact issues, document a temporary workaround and an owner rather than silently accepting them.
Rerun the relevant tests when validation rules, required fields, permissions, or vendor package versions change. Your acceptance matrix becomes a small regression suite for the calling workflow.
Use a failure test before signing off
Ask the vendor to demonstrate a controlled failure in an approved test environment. Examples include a rejected activity write, expired connection, unavailable CRM lookup, or interrupted browser session.
For each case, ask:
- Does the rep know that the activity has not been saved?
- Can an administrator find the reason without guessing?
- Will a retry create one activity or a duplicate?
- How does the team reconcile records that could not be recovered automatically?
- Can a rep continue through an approved fallback workflow?
Keep the test results with your field map. They are useful later when an unrelated Salesforce automation change affects call capture.
Roll out with measurable acceptance criteria
Start with a limited group that represents your real workflows. Include inbound and outbound callers, reps working different record types, and a supervisor who reviews the resulting activity.
Agree on pass criteria before the pilot. For example, every test call must associate with the intended record, show a recognizable outcome, and preserve the actual rep. Establish your own tolerance and escalation process for production errors.
During rollout, track logging completeness, record-association errors, duplicate activity, time spent repairing calls, and rep adoption. A successful audio connection is only one part of integration quality.
Evaluate Revenue.io against your actual requirements
Revenue.io’s Salesforce integration connects calling and activity capture with the CRM workflow. Bring your field map, matching edge cases, and permission requirements to the evaluation rather than relying on a default demo.
Ready to test the integration? Book a Revenue.io demo and ask for one end-to-end scenario: call an approved test contact, capture the outcome, confirm the Salesforce association, and inspect the next action.
Frequently asked questions
Is CTI the same as VoIP?
No. VoIP concerns how voice is transmitted over an IP network. CTI concerns how telephony connects with software such as Salesforce. A phone system can use VoIP and also provide CTI capabilities.
Does CTI automatically log every call correctly?
Not simply because it is called CTI. Validate the product’s capture behavior, field mapping, matching logic, permissions, and recovery process in your environment.
What should I ask about Open CTI?
Ask whether the integration depends on it, which capabilities are affected, and how the vendor will support those capabilities after the announced retirement. Confirm the plan in writing.