CRM Integration Guides
What a real integration does, the field-mapping decisions that cause every sync problem, and what to test before go-live.
In short
A CRM integration for a contact center does four things: click-to-call from the CRM record, screen pop of the matching record when a call connects, disposition write-back so outcomes land in the system of record automatically, and two-way sync so lead status stays consistent in both systems.
Screen pop alone saves 15–30 seconds per contact. The hard part is not the connection — it is deciding which direction each field flows and what wins on conflict.
What an integration does
The point of integrating a dialer with a CRM is to remove the two things agents do that create no value: looking up the person they are already talking to, and re-typing the outcome into a second system. Between them those consume a substantial share of after-call work.
Click-to-call
Dialing from the CRM record rather than from the dialer. Small feature, real effect: it removes mis-dials and it means the call is automatically associated with the right record, which is what makes the reporting trustworthy later.
Worth checking during evaluation: does click-to-call work from list views and from search results, or only from the record detail page? Agents work from list views.
Screen pop
The CRM record appearing the instant a call connects, matched by ANI on inbound or by campaign record on outbound. Saves 15–30 seconds per contact and removes the awkward silent opening where the agent is searching.
The match logic is where it goes wrong:
-
Number formatting. If the CRM stores
(954) 246-4086and the ANI arrives as+19542464086, nothing matches. Normalise on both sides. - Multiple matches. One number on three records — a household, a shared business line. Decide whether to pop a chooser or the most recently modified record.
- No match. Should pop a pre-filled create form, not an empty screen. An unmatched inbound call is a lead you do not have yet.
- Withheld numbers. Design for it rather than letting the agent stare at a blank pane.
Disposition write-back
The outcome the agent selects in the dialer writing itself into the CRM as an activity, call log or status change. This is the single highest-value part of the integration, because it is the part that otherwise gets done manually, inconsistently, or not at all.
It also means your disposition scheme is now a CRM data model decision. Forty vague codes in the dialer become forty vague values in a CRM picklist that someone will build a report on.
Two-way sync
The hardest part, and the one to scope carefully. Push-only — dialer to CRM — is simple and sufficient for many operations. True two-way means both systems can change the same record, which requires you to answer conflict questions in advance.
The three questions that prevent sync problems
- If a record's status changes in both systems between syncs, which one wins?
- If a number is suppressed in the CRM, does the dialer stop calling it — and how fast? This is a compliance question, not a convenience one.
- Does a record deleted in the CRM get removed from active campaigns, or keep dialing?
Field mapping decisions
Every integration problem anyone has ever reported traces back to a mapping decision nobody wrote down. Write them down.
| Field | Direction | Notes |
|---|---|---|
| Phone numbers | CRM → dialer | Normalise to E.164 on both sides; carry number type |
| Record owner | CRM → dialer | Drives routing and callback assignment |
| Timezone | CRM → dialer | Required for lawful calling windows; do not derive from area code |
| Consent and source | CRM → dialer | Provenance must travel with the record, not sit in the origin system |
| Disposition | Dialer → CRM | Map to a short, controlled picklist |
| Call recording link | Dialer → CRM | Link, not the file; check retention and access scope |
| Attempt count and last attempt | Dialer → CRM | Stops the CRM side re-queueing worked records |
| Suppression / DNC flag | Two-way | Whichever system sets it, both must honour it immediately |
Salesforce
The most common integration and the most configurable, which cuts both ways. Points to settle early: whether you dial from Leads, Contacts or a custom object; whether dispositions write to Task or to a custom activity object; and how your existing automation reacts to an inbound write. A well-meaning flow that fires on every Task creation can generate a great deal of noise once a dialer starts writing thousands of them.
Also confirm API call volume against your org's limits. A high-volume outbound operation writing every disposition and attempt count can consume more of the daily allocation than anyone expected. DialedIn's Salesforce integration →
HubSpot
Cleaner object model, fewer decisions. Dialing typically works from Contacts, with dispositions landing as logged calls against the contact timeline. The thing to check is how call outcomes interact with your lifecycle stages and any workflow that advances a deal on activity — you generally want dispositions to record fact, not to trigger stage changes, until you have watched the volume for a few weeks. DialedIn's HubSpot integration →
Microsoft Dynamics
Common in regulated and enterprise environments, which usually means the integration conversation is as much about identity and audit as about call flow. Expect to involve whoever owns your Entra ID configuration. Worth settling early: how phone call activities map to your entity model, and whether recordings are linked or stored per your retention policy. DialedIn's Dynamics integration →
Zoho
Frequently chosen by smaller and mid-market teams, and often the case where a lighter push-only integration is genuinely the right scope. Dispositions and call logs to the CRM, numbers and owner out of it, no two-way conflict resolution to design. Do not scope more integration than the operation needs. DialedIn's Zoho integration →
Zendesk
A support system rather than a sales CRM, so the integration shape differs: the useful pattern is ticket context on screen pop and call activity attached to the ticket, rather than lead status sync. Decide whether an inbound call creates a ticket automatically or only when the agent chooses — automatic creation on every call produces a large volume of single-touch tickets that distort your support reporting. DialedIn's Zendesk integration →
Pre-go-live test checklist
Test with real records, not seed data. Seed data is always formatted correctly.
- Screen pop fires on inbound match, on outbound, and on a withheld number.
- A number stored in a non-standard format still matches.
- A number appearing on two records behaves the way you decided.
- An unmatched inbound call offers a pre-filled create form.
- Every disposition writes the value you expect — walk the whole list, not three of them.
- Suppressing a record in the CRM stops calls, and you know how many minutes that takes.
- Attempt count increments and is visible in the CRM.
- A recording link opens for a user who should have access, and fails for one who should not.
- Existing CRM automation does not misfire on dialer-created activity.
- API volume under peak load stays inside your limits.
Deep-dive guides in progress
Each of these becomes a per-platform walkthrough with the actual field maps and the settings screens.
- Salesforce: field mapping and object model walkthroughIn progress
- HubSpot: click-to-call and timeline logging setupIn progress
- Microsoft Dynamics: identity, audit and activity mappingIn progress
- Zoho: a minimal push-only integrationIn progress
- Zendesk: ticket context and call attachmentIn progress
- Screen pop match logic: normalisation and edge casesIn progress
- Two-way sync: designing conflict resolutionIn progress
These are listed without links on purpose — we would rather show you what is coming than send you to a page that does not exist yet.
Frequently asked questions
What does a CRM integration do for a call center?
Four things: click-to-call from the CRM record, screen pop of the matching record when a call connects, automatic disposition write-back, and — optionally — two-way sync of lead status.
Screen pop alone saves 15–30 seconds per contact, and write-back removes the manual re-entry that otherwise dominates after-call work.
Why is screen pop not finding the right record?
Almost always number formatting. If the CRM stores
(954) 246-4086 and the ANI arrives as
+19542464086, no match occurs. Normalise to E.164 on both
sides.
After that, check your multiple-match rule — one number on several records needs a decision about whether to pop a chooser or the most recently modified record.
Do we need two-way sync or is one direction enough?
Push-only from dialer to CRM is sufficient for many operations and much simpler to run. True two-way means both systems can change the same record, which requires you to decide in advance what wins on conflict.
The one exception worth two-way regardless of scope is the suppression flag — whichever system records an opt-out, both must honour it, and quickly.
How long does a CRM integration take to set up?
Typically two to four weeks as part of a wider deployment, and the time goes into field mapping and user acceptance testing rather than into connecting the two systems.
You can shorten it considerably by writing down, before configuration starts, which direction each field flows and what wins on conflict.
Will the dialer break our existing CRM automation?
It can, and this is worth testing deliberately. A workflow that fires on every activity creation behaves very differently once a dialer starts writing thousands of them per day.
Test dialer-created activity against your existing automation in a sandbox before go-live, and check API call volume against your org's limits under peak load.
See the integration with your own records
We will connect a sandbox to your CRM during the demo, so you can watch screen pop and write-back working against data you recognise.