Every Fivetran rollout eventually reaches Salesforce, and Salesforce is the connector that behaves least like a database. There is no write-ahead log to tail, no replication slot to own. There is a metered API, a data model your revenue team reshapes every quarter, and a set of objects that quietly refuse to replicate the way you expect.
This tutorial covers the parts that cause real tickets: which sync method to use, how API call consumption actually works, why formula fields go stale, what happens to deleted and archived records, and how to keep a Salesforce connector fast and cheap as the org grows. It assumes a warehouse destination already exists — Snowflake, BigQuery, Databricks or Fabric — and that you have a Salesforce user you can dedicate to Fivetran.
Step 1: give Fivetran its own Salesforce user
Do not authorise the connector with an admin's personal account. When that person leaves, changes their password, or gets an MFA reset, every sync fails at once and nobody connects the two events.
Create a dedicated integration user and give it:
- API Enabled and View All Data (or, if View All Data is refused, a permission set granting read on exactly the objects you intend to sync — expect to revisit it every time someone adds an object).
- View Encrypted Data only if you genuinely need encrypted field values in the warehouse. Usually you do not, and leaving it off is a cheaper conversation with security than masking downstream.
- A profile whose login IP ranges and login hours do not exclude Fivetran. A restrictive profile silently breaks OAuth refresh.
- No inbox, no UI habits, and a named human owner recorded in your runbook.
Salesforce also offers an Integration User licence type on many editions; it is cheaper than a full licence and designed for exactly this. Ask the Salesforce admin before buying a seat you do not need.
Fivetran authenticates by OAuth, so no password is stored. Two things still expire: the refresh token if the connected app is revoked, and the user itself if it is deactivated during an offboarding sweep. Both present as a broken connector with an authorisation error, and both are fixed by re-authorising — not by re-syncing.
Step 2: choose the sync method deliberately
Fivetran's Salesforce connector can read through more than one API path, and the choice drives both your sync duration and your API consumption.
| Method | How it reads | Best for | Watch out for |
|---|---|---|---|
| REST / SOAP incremental | Queries by SystemModstamp in batched calls | Small-to-mid orgs, most standard objects | API call count scales with row volume |
| Bulk API | Asynchronous jobs, large result batches | Initial sync and very large objects | Job-level failures retry the whole batch |
| Salesforce Pub/Sub (Change Data Capture) | Streams change events | Low-latency needs on selected objects | Requires CDC enabled per object; event retention window is short |
The practical guidance: let the connector use bulk paths for the historical sync, keep incremental queries for steady state, and only reach for CDC/Pub-Sub when someone has a genuine sub-hourly requirement and is prepared to pay for it in Salesforce configuration. Streaming events do not backfill — if your consumer is down longer than the retention window, you are re-syncing anyway, so you still need the query-based path as a safety net.
Step 3: understand what consumes your API limit
This is the part that bites. Salesforce enforces a rolling 24-hour API request limit based on edition and licence count — often somewhere in the low hundreds of thousands of calls for a mid-size org. Fivetran is rarely the only consumer; marketing automation, CPQ, middleware and someone's spreadsheet add-in are all drinking from the same tap.
What drives Fivetran's consumption:
- Sync frequency. A 15-minute schedule makes 96 passes a day across every selected object. A 6-hour schedule makes four. If nobody looks at the dashboard before 09:00, a 15-minute sync is pure waste.
- Number of selected objects. Each object costs at least one call per sync even when nothing changed. An org with 400 objects selected and a 15-minute schedule burns tens of thousands of calls doing nothing.
- Row churn. Incremental queries page through modified records; high-churn objects like
Task,EmailMessageandLoginHistorydominate.
Two checks worth doing in week one:
- In Salesforce, Setup → System Overview shows API requests over the last 24 hours. Take a baseline before the connector goes live.
- Query the limits directly so you can trend it:
SELECT ... FROM /services/data/vXX.0/limitsreturnsDailyApiRequestswithMaxandRemaining. Poll it into your warehouse on a schedule and alert at 70%.
Then tune in this order: deselect objects nobody queries, lengthen the schedule, and only then argue about API capacity. Object deselection is almost always the biggest single win, and it reduces your Fivetran MAR bill at the same time — see our notes on connection-level MAR pricing for why row count and object count are the two levers that matter.
Step 4: formula fields, and why your numbers disagree
Formula fields and roll-up summaries are calculated by Salesforce at read time. They are not stored, and — critically — changing one does not bump SystemModstamp on the record.
The consequences are specific:
- A formula field synced today can be stale tomorrow even though the underlying record never changed in a way Fivetran can see.
- Re-defining a formula (new logic, new currency conversion) changes the value for every historical row in Salesforce and for none of them in your warehouse until a re-sync.
- Roll-ups like
Opportunity.Amountderived from line items can drift when child records change without touching the parent's modstamp.
There are three defensible responses, in increasing order of maturity:
- Re-sync the affected table after a formula change. Cheap to say, expensive on large objects, and it needs to be someone's job the day the admin ships the change.
- Enable Fivetran's formula-field handling where available on the connector and accept the extra API cost of periodic re-reads.
- Stop syncing formula fields and rebuild the logic in dbt. This is what we recommend for anything finance looks at. The definition lives in version control, it recalculates over full history, and it is reviewable. Our Fivetran + dbt transformations work is mostly this: moving business logic out of the CRM's read layer and into a tested model.
Write it into the process: when a Salesforce admin changes a formula or roll-up, the data team gets told. Otherwise the first signal is a finance meeting where two dashboards disagree.
Step 5: deletes, archives and the records that vanish
Salesforce deletion has three flavours, and Fivetran handles them differently.
- Soft delete (Recycle Bin). The record is queryable via
queryAll/isDeleted. Fivetran picks this up and marks the row_fivetran_deleted = TRUErather than removing it — the same pattern described in handling deletes in Fivetran. - Hard delete / Recycle Bin purge. The record leaves the queryable space. If the purge happens between syncs, Fivetran may never observe the deletion, and the row sits in your warehouse looking alive. This is the number one cause of "our warehouse has 30 more accounts than Salesforce".
- Archived activity records.
TaskandEventrows older than the activity archive threshold drop out of standard queries. They are not deleted, and they will not be re-synced by a normal incremental pass.
Mitigations that actually work: run a periodic reconciliation query comparing row counts per object between Salesforce and the warehouse, filter _fivetran_deleted in every downstream model (not in the BI layer, where someone will forget), and schedule a full re-sync of small dimension objects like Account and User on a monthly cadence. A re-sync of Account is cheap. A quarter of misreported pipeline is not.
Field History tables (AccountHistory, OpportunityFieldHistory) deserve a mention: they are append-only, they are the only record of who changed what and when, and Salesforce retains them for a limited period by default. If you care about change history, sync them early — you cannot backfill history that Salesforce has already aged out. For point-in-time reporting on current objects, Fivetran's own History Mode is usually the better tool.
Step 6: schema drift from a CRM that changes weekly
Salesforce orgs mutate constantly. Custom fields appear with an __c suffix, record types get added, a managed package installs 60 objects overnight. Your change-handling policy on the connector decides whether that arrives silently or breaks something.
Sane defaults for a Salesforce connection:
- Allow new columns, block new tables. New fields on objects you already sync are usually wanted. New objects from a package install are usually not, and letting them in automatically is how a MAR bill doubles in a month.
- Pin the object list explicitly and review it quarterly with the Salesforce admin.
- Alert on schema change events from the Fivetran Platform Connector so a new column shows up in a channel rather than in a broken dbt model. The pipeline observability walkthrough has the query patterns.
- Never let a downstream model do
SELECT *on a Salesforce table.
The wider re-sync mechanics are covered in the schema drift playbook; the Salesforce-specific part is simply that drift here is weekly, not annual.
Step 7: a sane object selection
Most orgs need far less than they select. A reasonable starting core:
Account,Contact,Lead,Opportunity,OpportunityLineItem,Product2,Pricebook2User,UserRole,Group,Profilefor ownership and attributionCampaign,CampaignMemberif marketing attribution is in scopeCase,CaseCommentif support reporting is in scopeRecordTypeand the relevant__cobjects your revenue process depends on
Deliberately deferred until someone asks by name: Task, Event, EmailMessage, LoginHistory, FeedItem, and anything a managed package brought with it. These are the highest-volume, lowest-value objects in a typical org, and they are where the MAR goes.
Step 8: validate before anyone builds on it
Before the first dashboard is written, check four things:
- Row counts per object against Salesforce reports, with
_fivetran_deleted = FALSEapplied. - A known-value spot check: pick five opportunities across stages and compare every synced field, including currency and timezone-sensitive ones. Salesforce stores datetimes in UTC; a dashboard built in local time will be off by hours and nobody will notice until quarter close.
- Multi-currency, if enabled:
Amountis in record currency,ConvertedAmountsemantics depend on your dated conversion rates. Decide once, document it, and convert in dbt. - Sync duration and API consumption over a full business day, not over a quiet Sunday.
Log the results. Six months on, the reconciliation you ran at go-live is the only evidence anyone has of what "correct" looked like.
Where SyncSpur fits
A Salesforce connector is easy to switch on and easy to get quietly wrong — a stale formula field, a purged record and a 15-minute schedule on 400 objects will each cost you either credibility or money. We scope object selection against the reporting that is actually being asked for, move business logic into tested dbt models, and hand back a reconciliation runbook your team can re-run.
If your Salesforce pipeline is slow, expensive, or disagreeing with the CRM, get in touch. You can also read how we approach Fivetran connectors configuration and management and performance tuning in Fivetran.