You can’t fix what you can’t see. Every engineering team eventually hits that wall: the project is humming along until someone asks, “Where did this number come from?” Then the scramble begins across analytics dashboards, dbt models, and Confluence pages last updated two quarters ago. That’s where connecting Confluence with dbt changes everything.
Confluence organizes context. dbt transforms and documents data logic. When paired, they turn tribal knowledge into a living system of record that updates itself. Analysts write models, dbt auto-generates documentation, and Confluence becomes the searchable front door where everyone else can find it. No stale spreadsheets. No Slack archeology.
The integration workflow is straightforward. dbt produces documentation as part of its build process, generating metadata that describes lineage, dependencies, and sources. Confluence consumes that metadata, displaying it right beside business definitions, dashboards, or process notes. The result: technical assets and operational decisions stay in sync. Data people work in dbt, everyone else reads in Confluence.
How do you connect Confluence and dbt?
Publish dbt docs to a web endpoint, then embed or sync that HTML into Confluence using your preferred API or integration app. Identity flows through your SSO provider, often via SAML or OIDC, so permissions mirror the ones already defined in Okta or Azure AD. Once linked, updates to dbt docs propagate automatically, keeping the knowledge base consistent without any human babysitting.
For best results, define access controls at the group level. Map dbt project roles to Confluence spaces using RBAC or IAM policies, just like you would for AWS resources. Rotate tokens through a secret manager instead of storing them in the Confluence app configuration. The less manual upkeep, the fewer things to break during a Friday deploy.