Every Fivetran project reaches the same awkward moment. The connectors are green, the raw Salesforce and HubSpot and Stripe schemas are landing on schedule, and someone from finance asks a question that sounds simple: "how many open opportunities do we have by stage?" Then you open salesforce.opportunity, find 340 columns, three history tables, a _fivetran_deleted flag and a stage_name field that contains four spellings of "Closed Won", and the honest answer becomes "give me two weeks".
Fivetran's answer to that gap is Quickstart data models: managed, pre-built transformations that run in your destination on top of a connector's raw schema and produce analytics-ready tables, with no dbt project, no git repository and no orchestration for you to own. They are one of the most under-used features on the platform, partly because the marketing name makes them sound like a toy. They are not a toy — but they are also not a substitute for a transformation layer, and knowing which of those two statements applies to your situation is the whole point of this tutorial.
What Quickstart data models actually are
Fivetran maintains a large library of open-source dbt packages for its connectors — fivetran_utils, salesforce_source and salesforce, hubspot, stripe, netsuite, zendesk, google_ads, shopify and dozens more. Quickstart is Fivetran running the same packages for you, as a managed service inside your destination, triggered after the relevant connection finishes syncing.
Practically, that means:
- You enable a Quickstart transformation and pick a connection.
- Fivetran works out which source tables the model needs and tells you if any are blocked or missing.
- After each successful sync, Fivetran executes the model's SQL in your warehouse — your compute, your credits.
- You get a set of conformed staging tables (
stg_salesforce__opportunity) and end models (salesforce__opportunity_enhanced,salesforce__manager_performance) in a schema of your choosing.
There is no dbt runtime for you to host and nothing to deploy. The trade for that convenience is control: you cannot edit the model SQL, you cannot add your own models into the DAG, and you cannot fork a package and keep the managed scheduling. It is a fixed menu.
Step 1: check the prerequisites before you enable anything
Two conditions cause most of the failures we get called about, and both are visible in advance.
The connector must be syncing the tables the package needs. Quickstart packages assume the connector's standard schema. If someone excluded opportunity_history or contact in the connector's schema tab to save on monthly active rows, the model will either fail or silently produce empty results. Check the connector's schema config first, and expect to trade some MAR savings back for the models to work.
Column blocking and hashing break joins. If you hashed contact.email for governance reasons — a good instinct, and one we recommend doing at the connector — any Quickstart model that joins or dedupes on that column now behaves differently. Hashing is fine when the hash is consistent; blocking the column entirely is not.
Also confirm your destination is supported for the package you want. Coverage is broadest on Snowflake, BigQuery, Databricks and Redshift, and thinner on newer destinations. Check the specific package's docs rather than assuming.
Step 2: enable a model and read the first run honestly
In the dashboard, go to Transformations → Add transformation → Quickstart data models, choose the connection, and pick the packages you want. Fivetran shows a dependency report: the source tables it needs, and any that are unavailable. Do not skip that screen. Fix the gaps in the connector first, re-sync, then enable.
Choose the output schema deliberately. Our convention on client projects:
salesforce— raw connector landing, analysts have no access.salesforce_qs— Quickstart output.analytics— your own models, the only schema BI tools are pointed at.
Keeping Quickstart output in its own schema matters more than it looks. If you later replace Quickstart with your own dbt models, you want to be able to swap what analytics reads from without renaming anything users touch.
The first run is a full build and it is the expensive one. On a large Salesforce or NetSuite account, expect materially more warehouse compute than a normal incremental run. Run it once, look at the query history, and price it before you switch on twelve packages at the same time.
Step 3: understand the cost model, because it is not the one people assume
Two separate meters are involved and confusing them leads to unpleasant invoices.
Fivetran side. Quickstart transformations are billed in model runs rather than monthly active rows. There is a free allowance, and each transformation run counts against it. This matters because the trigger is "after the connection syncs". A connector on a 15-minute schedule fires the model up to 96 times a day. That is almost never what anyone wants for a reporting table that gets looked at once each morning.
Warehouse side. Every run is SQL in your destination. A rebuild of a wide Salesforce package is not free on Snowflake credits, and Quickstart's incremental logic is only as clever as the package's own materialisation strategy.
The fix is boring and effective: decouple sync frequency from model frequency. Let the connector sync often for freshness, and schedule the transformation on integrated scheduling only for connections whose downstream tables genuinely need to be minutes fresh. For everything else, set the connector to hourly or use a time-based schedule for the transformation. We routinely cut a client's transformation run count by 80% with no user-visible change in freshness — the same discipline we apply in Fivetran cost optimisation engagements.
Step 4: validate the output against a number someone already trusts
Never hand Quickstart tables to a business team without a reconciliation pass. Pick one metric the business already reports from the source system — open pipeline by stage, MRR, ticket count last month — and compare.
-- Source-of-truth style count straight off the raw connector schema
select stage_name, count(*) as opps, sum(amount) as amount
from salesforce.opportunity
where not coalesce(_fivetran_deleted, false)
and is_deleted = false
and is_closed = false
group by 1
order by 2 desc;
-- The Quickstart model's version of the same question
select stage_name, count(*) as opps, sum(amount) as amount
from salesforce_qs.salesforce__opportunity_enhanced
where is_closed = false
group by 1
order by 2 desc;
Differences are normal and usually explainable. The three we see most often:
- Deletes. Packages generally filter
_fivetran_deletedand the source's own soft-delete flag. Your hand-written query may not, so raw counts run high. - Currency. Multi-currency Salesforce and NetSuite accounts need the package's currency variables configured, or amounts get summed across currencies as if they were the same unit. This one has embarrassed people in board meetings.
- Timezones and fiscal calendars. Packages default to UTC and a calendar year. If your business closes months on a 4-4-5 fiscal calendar, month-over-month numbers will not match finance until you set that up.
Most packages expose variables for exactly these things — enabled/disabled source tables, currency conversion, timezone, fiscal year start. In Quickstart, the configurable surface is narrower than in the dbt package itself, which is one of the honest limits of the managed option.
Step 5: monitor them like pipelines, not like magic
A Quickstart model that starts failing is a silently stale dashboard, which is worse than a broken one. Wire the transformation status into the same alerting you use for connectors: Fivetran's webhooks emit transformation success and failure events, and the Fivetran Platform Connector lands transformation run history in your warehouse so you can alert on "model has not succeeded in N hours". If you have not set that up yet, our pipeline observability walkthrough covers the queries.
When to graduate to dbt
Quickstart is the right call when you need standard reporting on standard SaaS sources, quickly, with a small team and no dbt skills in-house. For a 40-person company that wants Salesforce and HubSpot dashboards next week, it is genuinely the fastest defensible path — and much better than the pile of hand-written BI-tool SQL that is the real alternative.
Move to your own dbt project when any of the following is true:
- You need to join across sources. Quickstart models are per-connector. Revenue that combines Stripe, Salesforce and your product database is not something Quickstart will build for you.
- You have business logic worth version-controlling. Definitions of "active customer" or "qualified lead" belong in code review, not in a vendor's fixed package.
- You need tests and contracts. Quickstart gives you the package's built-in tests; it does not give you your own assertions, freshness thresholds or CI on pull requests.
- You want to edit the model. The moment you say "this is nearly right, but…", the managed option is over.
The migration path is deliberately gentle, and it is why we insist on the separate-schema convention above. The same dbt packages Quickstart runs are open source, so you can install dbt-salesforce into your own project, point it at the same raw schema, reproduce the Quickstart output, add your own cross-source models on top, and cut BI over when the numbers match. Then disable the Quickstart transformation. Nothing gets rebuilt from scratch and no connector is touched, so there is no re-sync and no MAR consequence.
Where you run that dbt project afterwards is a live question in 2026, given Fivetran and dbt Labs are now the same company — we unpicked the practical implications in what the merger actually changes for your pipelines, and Fivetran-hosted dbt Core transformations are one option alongside dbt Cloud and your own orchestrator.
A short decision checklist
- Connector syncs every table the package needs; no blocked join keys.
- Destination supported by the specific package version.
- Quickstart output lands in its own schema, not the raw one and not
analytics. - Transformation schedule decoupled from a high-frequency sync schedule.
- First full build cost measured in the warehouse before enabling more packages.
- Currency, timezone and fiscal calendar settings reviewed with finance.
- One trusted business metric reconciled and the variance explained in writing.
- Transformation failures alerting into a channel a human reads.
- A written note on which of the "graduate to dbt" triggers you expect to hit, and when.
Quickstart is best understood as a loan of somebody else's transformation layer. It buys you months, and it is far better than nothing — but plan for the day you hand it back.
If you want help deciding whether to stand up Quickstart or a proper dbt project for your stack — or you already have Quickstart output that does not agree with the source system — our Fivetran + dbt transformations and data warehousing consulting teams do this assessment week in, week out. Get in touch with your connector list, destination and the metrics that have to reconcile, and we will tell you which path is cheaper for you.