Most Fivetran accounts start with three people who trust each other. Someone in analytics engineering has the admin login, connectors get added when they are needed, and everything works. The trouble arrives about eighteen months later, when four squads are sharing one account, a marketing analyst has quietly added a connector that costs more per month than the rest of the pipeline combined, and an auditor asks who approved the Salesforce sync into the finance schema.
That is a governance problem, not a pipeline problem, and it is fixed in the account structure rather than in any connector. This tutorial covers how to lay out destinations and teams, which Fivetran role to hand to which job function, how to wire single sign-on and SCIM provisioning from Okta or Microsoft Entra ID, how to keep API keys from becoming shadow admins, and how to answer "who changed this?" with evidence rather than recollection.
Start with the blast radius, not the roles
Fivetran's permission model hangs off the destination. A destination (and the connections attached to it) is the unit you grant access to, so the way you split destinations decides how finely you can grant anything at all. If every team lands data in one destination, everyone with edit rights on that destination can touch everyone else's connectors, no matter how carefully you name the roles.
Three layouts show up in practice.
One destination, one team. Fine below roughly ten connectors and one squad. Do not build governance ceremony around this; just keep two account admins and move on.
One destination per environment. A prod and a dev destination, usually pointing at separate warehouse databases. This is the minimum sane setup once anything downstream is customer-facing. Engineers get edit rights on dev and read-only on prod, and promotion happens through Terraform rather than through the UI.
One destination per domain or business unit. Finance, growth, product and platform each land in their own destination, often separate schemas or even separate warehouse accounts. This is the layout that scales, because chargeback, access and blast radius all line up with the same boundary. The cost is duplication: a Salesforce connector needed by two domains is two connections and two MAR bills for overlapping tables. Decide deliberately - usually the answer is to sync once into a platform destination and let domains read the modelled output, not raw source tables.
Whatever you choose, write down the rule for creating a new destination and who signs off. Destination sprawl is harder to unwind than connector sprawl because the data physically lands in different places.
Mapping roles to real jobs
Fivetran separates account-level roles from destination-level roles. Account roles cover billing, users, settings and the ability to create destinations. Destination roles cover the connections and the schema config underneath a given destination. A person can be nothing at the account level and still be a powerful editor inside one destination - which is exactly what you want for most engineers.
A mapping that holds up in review:
| Job function | Account role | Destination role | Rationale |
|---|---|---|---|
| Data platform lead | Account Administrator | Destination Administrator on all | Two of these, never one, never five |
| Analytics engineer | None | Connector Creator / Editor on their domain | Can add and fix connectors where they own the outcome |
| Analyst | None | Reader on prod | Sees sync status and schemas, changes nothing |
| Finance / FinOps | Account Billing (read) | Reader | Needs MAR and invoices, not pipelines |
| Security reviewer | Account Reader | Reader | Needs config and audit visibility, not edit |
| Contractor / agency | None | Editor on a scoped dev destination, time-boxed | Access ends when the statement of work does |
Two rules matter more than the exact table. First, the ability to create connections is the ability to create cost, because a new connector generates monthly active rows the moment it syncs. Treat Connector Creator as a spending permission and grant it to people who see the bill. Second, resist granting Account Administrator as a convenience for someone who just needs to add a connector - that role also carries user management and billing, and it is the one auditors count.
Teams instead of individual grants
Granting access user by user is fine for six people and unmanageable for sixty. Fivetran Teams let you create a named group, give the group a role on a destination or connection, and then manage membership only. The practical pattern:
- Create a team per domain and environment:
finance-eng,finance-read,growth-eng,platform-admin. - Grant each team exactly one role on exactly one destination. Resist teams that span destinations with different roles - the intersection is what people will get wrong when they reason about it later.
- Add users only through teams. If someone needs an exception, that is a signal your team layout is wrong, not a reason for a direct grant.
- Review membership quarterly. Export it (see the API section below) and diff against your HR roster or your identity provider groups.
The payoff is that offboarding becomes a single action in your identity provider rather than an archaeology exercise across destinations.
SSO and SCIM: stop managing passwords
On Enterprise and Business Critical plans, Fivetran supports SAML single sign-on with Okta, Microsoft Entra ID, Google Workspace and generic SAML 2.0 providers, plus SCIM for automatic user provisioning and deprovisioning.
A workable rollout order, because doing this in the wrong order locks people out:
- Configure SAML while local logins still work. Set up the application in your IdP, exchange metadata, and assign yourself plus one other admin first.
- Verify with a non-admin test user. Log in from a private browser window. Confirm the user lands with the role you expect, not with more.
- Roll out to the rest of the account by IdP group. Assign the Fivetran app to identity provider groups that mirror your Fivetran teams - same names, so that the mapping is obvious.
- Turn on SCIM provisioning. Now a joiner in the IdP group becomes a Fivetran user automatically, and a leaver is deactivated within minutes rather than at the next access review.
- Only then enforce SSO-only login and remove local passwords. Keep one break-glass account documented with your security team in case the IdP itself is the outage.
The detail teams most often miss: SCIM handles users, but role and team assignment still has to be driven by group mapping. If your IdP groups do not correspond one-to-one with Fivetran teams, you will be doing manual role grants forever and your deprovisioning story will have a hole in it.
API keys are users too
Every orchestration integration, Terraform run and monitoring script authenticates with a Fivetran API key, and an account-level key carries account-level power. This is the most common finding in a first SOC 2 review of a Fivetran account.
Keep to four habits:
- One key per system, never per person. A key named
airflow-prodis auditable; a key created by an engineer who left is not. - Scope keys as narrowly as the plan allows - destination-scoped where available, and never a permanent account admin key sitting in a shared CI variable.
- Store them in the secret manager you already use (AWS Secrets Manager, Vault, GitHub Actions secrets), not in a
.envcommitted to a repo, and rotate on a schedule you actually keep. - Give Terraform its own key. If you manage pipelines as code with the Fivetran Terraform provider, that key is effectively an editor on everything it manages, and its state file deserves the same protection.
A quick inventory of who and what has access:
curl -u "$FIVETRAN_API_KEY:$FIVETRAN_API_SECRET" \
'https://api.fivetran.com/v1/users?limit=1000' \
| jq -r '.data.items[] | [.email, .role, (.active|tostring), .logged_in_at] | @tsv'
Run it monthly, commit the output to a private repo, and your access review becomes a diff instead of a meeting. The same endpoint family covers teams (/v1/teams), team membership and per-destination memberships, so the whole picture can be rebuilt from the API without a single screenshot.
Proving who changed what
Governance you cannot evidence is a policy document, not a control. Fivetran gives you two useful sources.
The Fivetran Platform Connector syncs your own account metadata into your warehouse - connector state, sync history, usage and log events, including account activity. Landing it in the same warehouse as your data means you can query changes with SQL and join them to cost. If you have not set it up, start with the pipeline observability walkthrough; the governance queries sit on the same tables.
A simple change-review query over the log table looks like this:
select
time_stamp::date as day,
event,
message_data:actor::string as actor,
message_data:connection::string as connection,
message_data:change::string as change
from fivetran_platform.log
where event in ('create_connector','update_connector','delete_connector',
'pause_connector','resume_connector','alter_schema')
and time_stamp >= dateadd(day, -30, current_date)
order by time_stamp desc;
Exact column and event names vary a little by destination and connector version - inspect the log table in your own warehouse before wiring it into a dashboard. The point is that the question "who paused the finance connector on the 14th?" becomes a query.
Log service export is the second source. On the higher plans, Fivetran can stream connector and account logs to CloudWatch, Azure Monitor, Datadog, Splunk or a cloud bucket. If your security team already runs a SIEM with retention rules, send the logs there rather than inventing a separate retention policy in the warehouse. Most auditors will accept "it is in Splunk with the rest of our audit trail" far more readily than a bespoke table.
Pair both with alerting on the events that indicate governance drift: a new connector created outside Terraform, a destination role granted directly rather than via a team, a schema change policy flipped from block to allow.
A 90-minute hardening pass
If your account has grown organically and you want a concrete starting point, do this in one sitting:
- List every user and role via the API and delete anyone who has not logged in for 90 days.
- Count Account Administrators. If there are more than three, demote the rest to destination roles.
- List API keys. Name the owning system for each one; delete any key nobody can explain.
- Create teams that mirror your domains and move every direct grant into a team.
- Confirm dev and prod land in separate destinations, and that no analyst has edit rights on prod.
- Turn on the Platform Connector if it is not already running, and save the change-review query above as a scheduled check.
- Write down, in one page, who may create a connector and what approval a new one needs. Cost control and access control are the same control here.
None of this slows down the teams that are doing the right thing. It mostly removes the quiet paths by which a shared account accumulates risk - the contractor still in the account, the admin key in a CI variable, the connector nobody owns that bills every month.
Where this usually needs help
The technical steps are not hard. The hard parts are deciding the destination boundary in an organisation that has not agreed on data ownership, and mapping identity provider groups onto that boundary without breaking access for people mid-quarter. If you are staring at a Fivetran account with forty connectors, nine admins and no idea which ones are load-bearing, SyncSpur does this as a fixed-scope engagement: an access and cost inventory, a target role and team design, the SSO/SCIM rollout, and the Terraform baseline so the structure does not drift back. Get in touch and we will start with the inventory.