CallRail tracks the call. Salesforce runs the revenue. The connector between them moves call activity — and stops short of texts, form submissions and the attribution your marketing team actually reports on. Twopir Consulting implements that connector, configures it around your routing and campaign rules, and builds the parts it does not cover. Attribution that survives the handoff.
Twopir Consulting is a Salesforce Partner and has connected CRM platforms to the systems that actually run revenue — call tracking, marketing automation and AI conversation tools — for 500+ clients.
.png){kind=small}
-3.png){kind=small}
Built for Call-Driven Revenue
None of these are bugs. They are the documented edges of the native connector — and every one of them shows up as a blank field, a missing Lead, or a campaign that looks like it did nothing. Knowing where the edges are is what makes the build predictable.
Attribution detail — gclid, keyword, campaign, landing page — is generally not available at the pre-call event that creates the Lead. It arrives after the call and maps to the call activity instead, so a report grouped by Lead source shows blanks.
Once CallRail has created a Lead it does not update that Lead record again — subsequent detail updates the call activity. Anything you need enriched on the Lead itself has to be built deliberately.
CallRail's Salesforce integration sends call data. Text messages and form submissions do not report through it, so a form-heavy campaign can look like it produced nothing at all in the CRM.
An active Salesforce duplicate rule with the Alert option turned on fires every time CallRail tries to create a Lead. The call is tracked, the CRM record is not — and nobody notices until the pipeline looks thin.
A required custom field on Lead or Activity that is not mapped — or is mapped to something that is not always populated — throws an error on every record it touches, silently, until someone reads the integration log.
A single Salesforce user can authorise a limited number of integrations before one of them stops working. Without a dedicated integration user set up correctly at the start, the failure surfaces months later as missing data.
CallRail is a call tracking and lead intelligence platform. It assigns tracking phone numbers to marketing sources, swaps the number shown on a website to match the visitor's source — dynamic number insertion — and records, transcribes and analyses the resulting calls, so a business can see which campaign, ad or keyword produced each phone conversation. Its documentation is published at callrail.com.
Salesforce is where that call has to turn into revenue. A tracked call is only useful once it exists as a Lead somebody owns, an Activity somebody can read, and a Campaign somebody can measure against closed-won. CallRail is the system of capture; Salesforce is the system of record.
Twopir Consulting builds the layer between them. We are not reselling CallRail and we do not claim a formal CallRail partner status — we implement the integration, configure it around how your team actually routes and reports, and develop the extensions the native connector does not provide. Where a different call platform fits your stack better, we will say so; we deliver CallTrackingMetrics, RingCentral and PhoneBurner integrations on the same architecture.
This page is for marketing and revenue operations teams at businesses where the phone is a primary conversion path — multi-location services, legal and healthcare practices, home services, and the agencies that run their paid media. If most of your pipeline arrives as a form fill, the parent Salesforce integration page is the better starting point.
These are three different engagements with three different price points, and most teams only need one of them. Knowing which one you need is the point of the first call.
You have CallRail, you have Salesforce, and nothing connects them yet. We get call data flowing correctly the first time instead of six months of silent errors.
The connector is live but the data is wrong for how your team works — wrong owner, wrong campaign, duplicates, or fields nobody trusts. This is tuning, not development.
You have hit a documented limit — texts, forms, post-call enrichment, conversation data — and the answer is custom development against the CallRail and Salesforce APIs.
| Capability | Native connector | What it takes to go further |
|---|---|---|
| Call logging into Salesforce | Supported. Call activity posts to Leads, Contacts, Accounts and Activities. | Configuration only — field mapping and the choice of which objects receive activity. |
| Lead creation from a first-time caller | Supported. A caller with no matching record can be created as a Lead. | Configuration — matching, ownership and duplicate strategy decide whether it actually saves. |
| Campaign assignment on new Leads | Supported, via ordered rules. Only in-progress campaigns are selectable. | Configuration — rule order matters when a call qualifies for more than one campaign. |
| Attribution detail on the Lead record | Limited. Attribution generally is not available when the Lead is created, and the Lead is not updated afterwards. | Custom development — a post-call service that writes the campaign, keyword and landing page back to the Lead. |
| Text messages and form submissions | Not supported. The Salesforce integration sends call data only. | Custom development — webhook listeners that create or update Salesforce records from CallRail events. |
| Conversation intelligence outputs | Limited. AI summaries, sentiment and scoring are not fully exposed through the native connector. | Custom development — API retrieval into custom objects or fields your reports can group by. |
| Multi-touch attribution across call and web | Not supported as a model. The connector reports the call, not the journey. | Architecture and development — a shared attribution model spanning CallRail, Google Ads, GA4 and Salesforce. |
Six workstreams. Most engagements use three or four of them — we scope to what your stack is actually missing rather than selling the whole list.
The setup done properly: prerequisites verified, an integration user that will not collide with anything else, and every field mapped on purpose rather than by default.
A model that survives the whole journey: the source that produced the call, carried through the Lead and the Opportunity, and reported back against closed-won revenue.
Getting the call to the right rep, on the right record, without creating a second copy of a customer you already have — the failure that quietly poisons every downstream report.
The intelligence CallRail produces after the call — transcripts, outcomes, qualification signals — put somewhere Salesforce can group, filter and report on it.
Dashboards that answer the question the budget holder actually asks: which channels produced calls that turned into revenue, and which produced volume that went nowhere.
If the integration is already live and the data is not trustworthy, we find out why before proposing a rebuild. Most of the time the architecture is fine and the rules are wrong.
A call is only attributable if every system agrees on what produced it. These are the connections that keep that agreement intact.
Call activity flows one way into Leads, Contacts, Accounts and Activities, so sales works the call inside the CRM. Text and form events need a custom service.
Qualifying calls report back to the ad platform as conversions, so bidding optimises toward calls that became revenue rather than calls that merely connected.
Call events join web sessions in analytics so a phone conversion appears in the same funnel as a form fill, measured against the same session and source definitions.
New call Leads are assigned to campaigns by ordered rules, which is what lets marketing attribute spend and sales see which programme produced the conversation.
Where the native connector stops, events are pulled or pushed directly — texts, form submissions and post-call detail written into Salesforce on our own terms.
For teams running marketing in HubSpot, call activity lands on the contact timeline so nurture and lifecycle stages respond to phone behaviour, not just email and forms.
Transcripts, sentiment and qualification signals are retrieved by API into Salesforce objects, so call quality becomes a field teams can report on rather than a recording nobody opens.
Moving between call platforms — CallRail, CallTrackingMetrics, Invoca or RingCentral — with historic attribution preserved and reporting continuity through cutover.
The same sequence whether we are standing the connector up for the first time or repairing one that has been running badly for a year.
We trace a real call end to end — tracking number, CallRail record, Salesforce Lead, activity, campaign, report — and mark every point where detail is lost.
We agree the model before touching configuration: which fields carry source, where the Lead comes from, how campaigns are assigned, and what the closed-loop report has to prove.
Connector configuration, field mapping, routing and duplicate rules — plus any custom services needed for texts, forms or post-call enrichment. Built in a sandbox first.
We place test calls across every source and confirm each one lands with the right owner, campaign and attribution — then deliberately break it to check errors actually surface.
Error monitoring, quarterly attribution review, and changes as campaigns and territories move. An integration nobody watches drifts out of accuracy within a season.
These engagements were delivered on the call platforms named on each card, not on CallRail — but the architecture is the one described on this page: capture the call, attribute it, create the record, and report it back against revenue. The pattern is what transfers.
High inbound call volume with no way to connect a call to the campaign that drove it.
Rebuilding lead capture, routing and pipeline reporting on one Salesforce architecture.
Placeholder testimonial. Replace this with an approved client quote about the CallRail and Salesforce work — ideally one that names the specific problem it solved, such as attribution that finally reconciled with the ad platform, or missed calls that became owned follow-up tasks. Two to four sentences reads best in this card.
One line naming the problem the engagement solved.
Connecting two systems is a morning's work. Making the data trustworthy eighteen months later, across campaign changes and territory changes and a duplicate rule somebody switched on, is the actual job.
The limits on this page are published in CallRail's own documentation. We would rather you know them before the statement of work than discover them in month three.
Most call-tracking failures are Salesforce problems wearing a disguise — duplicate rules, required fields, ownership, sharing. That is our home ground, not a subcontracted skill.
We write Apex, Flow and integration services to production standards. Custom development is a deliberate decision with a reason attached, never the default answer to a limitation.
We deliver CallTrackingMetrics, RingCentral, PhoneBurner and Invoca integrations too. If CallRail is the wrong fit for your volume or routing, we will say so during discovery.
Attribution decays. Campaigns get renamed, territories move, admins add required fields. We monitor the errors and review the model so the reports keep meaning what they meant.
No. CallRail documents that its Salesforce integration sends call data only — text messages and form submissions do not report to Salesforce through the native connector. If those events need to reach your CRM, they require a custom integration built against CallRail's API and webhooks, which is work we deliver as a separate build-on engagement.
Because that detail usually does not exist yet at the moment the Lead is created. Attribution values such as gclid, keyword, campaign and landing page are generally not available at the pre-call event, and CallRail does not update a Lead after it has created it — the post-call detail attaches to the call activity instead. The fix is either to report from the activity, or to build a post-call service that writes the attribution back onto the Lead. We also check the setting that controls whether call data is sent both when a call begins and again when it completes, which is a common cause.
REST API access, which is included with Salesforce Lightning Enterprise and Unlimited editions and available as an add-on to some others, plus a user with sufficient permissions to authorise the connection. We also recommend a dedicated integration user rather than an individual's login, because a single Salesforce user can only authorise a limited number of integrations before one of them silently fails. Confirming all of this before work starts is the first item in our implementation scope.
All three, and they are separate engagements. Implementation is standing the connector up — prerequisites, integration user, field mapping, campaign rules. Configuration is tuning what already exists so routing, duplicates and reporting match how your team works. Build-on is custom development against the CallRail and Salesforce APIs for anything the connector does not cover, such as text and form events, post-call enrichment on the Lead, or conversation intelligence outputs. The boundary is simple: if it can be achieved through connector settings and Salesforce declarative configuration it is configuration, and everything beyond that is development.
It depends on four things, and we scope against them rather than quoting a standard duration: how many tracking numbers and sources need to map to campaigns, whether your Salesforce org has existing duplicate rules and required fields that will conflict, whether you need only call data or also texts, forms and conversation outputs, and whether historic data has to be reconciled. A clean implementation with no custom development is a short engagement; an attribution rebuild across several thousand tracking numbers with a custom enrichment service is not. We give a fixed scope after the audit stage, not before it.
Yes, and that is a large share of the CallRail work we take on. We start with the integration error log and a traced test call rather than a rebuild proposal, because the architecture is usually sound and the rules are usually wrong. The most common causes we find are an active duplicate rule blocking Lead creation, a required custom field that was never mapped, campaign assignment rules in the wrong priority order, and attribution being reported from the Lead when it only ever lived on the activity. You get a remediation plan ordered by revenue impact before any changes are made.
Twopir Consulting implements, configures and extends CallRail's Salesforce integration so call attribution holds up under real campaign volume — and so the numbers your marketing team reports reconcile with the revenue your finance team recognises.
Speak with a team that has already met these edge cases
