Dialing
Power dialer with Salesforce: how the integration actually works
- 7 min read
By Sujan ThapaliyaLast updated
The short answer
"Power dialer with Salesforce integration" is a checkbox on nearly every vendor's comparison page, and it can mean three different pieces of engineering: a click-to-dial button, an activity write-back, and a screen-pop that opens the right record before the rep says hello. Only one of the three actually removes work from the call, and it is the one most pricing pages don't distinguish from the other two.
This is the workflow underneath power dialer software when the CRM on the other end is specifically Salesforce — where the data actually lands, what click-to-dial requires under the hood, and the three places the integration silently breaks.
Where does a power dialer call actually land in Salesforce?
Every call becomes a Task record — Salesforce's standard activity object — with two link fields doing the real work: `WhoId` points to the Lead or Contact the call was about, and `WhatId` points to the related Account, Opportunity, or Case. Get both populated correctly and the call shows up on the Lead's activity timeline, the Opportunity's related list, and any report built on Task data, with zero manual entry.
| Field | What it holds | What breaks if it's wrong |
|---|---|---|
| WhoId | The Lead or Contact dialed | Call disappears from that person's activity history |
| WhatId | The related Account/Opportunity | Call doesn't roll up into pipeline or account reporting |
| Subject | A short description, often auto-templated | Reps can't scan a timeline without opening every task |
| CallDisposition | Outcome, from a picklist | Silently rejected or miscategorized if it doesn't match Salesforce's exact picklist values |
| CallDurationInSeconds | Talk time | Breaks any dashboard built on average handle time |
The `CallDisposition` row is the one that fails most often, and it fails quietly. Salesforce's picklist for that field is a fixed set of values configured in the org; a dialer that sends its own disposition label — "Connected" instead of the org's "Contacted" — either gets rejected outright or lands in an "Other" bucket that makes every downstream report wrong without throwing an error anyone notices.
How does Salesforce click-to-dial actually work?
Two architectures answer to the same feature name, and they are not close to equivalent.
| Open CTI screen-pop | External call-out button | |
|---|---|---|
| What happens on click | An embedded softphone panel places the call and Salesforce opens the matching record automatically | Salesforce hands the number to an external app or device; nothing opens on screen |
| What the rep sees before speaking | The Lead/Contact record, already on screen | Nothing — they're still looking at whatever tab was open |
| What it requires | Salesforce's Open CTI framework, a registered call center config, Sales Cloud/Service Cloud licensing that supports it | A tel: link or an API call — works on almost any Salesforce edition |
| Logging | Automatic, tied to the softphone session | Usually a separate write-back step, sometimes manual |
A click-to-dial button that doesn't open the record is a phone number with extra steps. The screen-pop is the feature; the button is the marketing.
This is the same latency question as the dial-to-connect gap in power dialer software, applied specifically to CRM lookup: without a screen-pop, a rep spends time finding and opening the right Salesforce record for every single call. At roughly 8 seconds per lookup — a name typed into search, a wait for results, a click to open — that cluster's own latency table already shows what 8 seconds of added cycle time costs: 16% of the hour's conversations, gone, with the dialer itself working exactly as advertised.
What does a Salesforce-driven dial queue look like?
The list a power dialer works from is usually a Salesforce report or list view — a segment of Leads or Contacts filtered by status, owner, or campaign membership. How that segment gets to the dialer is where the second common failure shows up.
- 1
A report or list view defines the segment
Filtered by lead status, campaign membership, or a custom field — whatever the team's working definition of "due to call" is. - 2
The segment reaches the dialer one of two ways
A live sync (the dialer queries Salesforce for the current list each session) or a one-time export (a CSV pulled once and loaded). Only the first reflects reassignments, status changes, or a colleague who already called that lead an hour ago. - 3
The dialer works the queue and dispositions each call
Each outcome should both advance the local queue and write back to Salesforce — not just one or the other. - 4
The write-back updates the record that drove the queue in the first place
If the queue was built from lead status, a disposition that should change that status needs to actually change it, or the same lead reappears in tomorrow's export.
A static export is a queue that lies to you by the afternoon
What breaks the integration, in practice?
- Disposition picklist mismatch. The dialer's outcome labels don't match the org's `CallDisposition` values exactly. Fails silently — no error, just a wrong or empty field on every call.
- WhatId left blank. The call logs against the right person but not the right deal, so it never shows up in pipeline or opportunity reporting even though it exists as a Task.
- Static list exports. Covered above — the queue drifts out of sync with Salesforce within hours, not days.
- Time zone mismatches between the calling window and the Lead's own record. A dialer that paces calls to a global calling-hours setting rather than each contact's own time zone field will eventually call someone outside their permitted hours, even when the org's compliance settings are configured correctly.
- No handling for Salesforce API limits. High-volume dialing teams can hit daily API call caps on smaller Salesforce editions, which silently stops write-backs rather than stopping the dialer — calls keep happening, logging quietly stops.
What to verify before rolling this out to a team
- 1
Confirm which click-to-dial architecture you're buying
Ask directly: does the record open automatically, or does the rep still have to search for it? If it's Open CTI, confirm your Salesforce edition and call-center configuration actually support it. - 2
Map disposition values before go-live, not after the first bad report
Get the org's exact `CallDisposition` picklist values and confirm the dialer's outcomes map to them one-to-one. A mismatch here is invisible until someone builds a report that comes out wrong. - 3
Ask whether the dial queue is a live sync or an export
If it's an export, ask how often it refreshes and what happens when two reps' segments overlap. This is the detail vendors are least likely to volunteer unprompted. - 4
Check API call volume against your Salesforce edition's daily limit
Multiply expected calls per rep per day by however many API calls each one triggers (dial, disposition, task creation), then compare against your org's daily limit before scaling past a pilot team.
2
Link fields (WhoId, WhatId) that determine whether a call shows up in Salesforce reporting
16%
Conversations/hour lost to an 8-second manual record lookup, per this cluster's latency math
2
Distinct architectures hiding behind the phrase "click-to-dial"
0
Errors thrown when a disposition picklist mismatch silently corrupts a report
None of this is Salesforce-specific difficulty — every CRM integration has its own version of the WhoId/WhatId problem, the picklist-mismatch problem, and the stale-export problem. Salesforce just has the most explicit, well-documented data model to check the integration against, which makes it the easiest CRM to verify a vendor's claims on before rolling a power dialer out to a full team.
Frequently asked questions
Does a power dialer log calls automatically in Salesforce?
What is Salesforce click-to-dial, and does it open the record automatically?
Why did a call disposition not show up correctly in Salesforce?
Can two reps work the same Salesforce list without double-dialing?
Does high-volume power dialing hit Salesforce API limits?
Sources
- Telemarketing Sales Rule — Federal Trade CommissionDo-not-call obligations, abandonment-rate limits for predictive dialing, and required call disclosures.
- 47 U.S.C. § 227 — Restrictions on the use of telephone equipment — Cornell Legal Information InstituteThe Telephone Consumer Protection Act itself — the consent requirements, calling-hours limits, and private right of action.
- National Do Not Call Registry — Federal Trade CommissionThe registry that outbound calling lists must be scrubbed against.
See it working: power dialer
A power dialer places one outbound call at a time from a loaded list, automatically dialling the next contact the moment the previous call ends. It removes manual dialling and hold time without the connection delay that makes predictive dialling feel robotic to the person who answers.
- No subscription
- Numbers in 100+ countries
- Compliance built in