Skip to main content
Managing changes across your data stack shouldn’t feel like a black box. By integrating dbt and Git with Omni, you can align your analytics development with software engineering best practices using branches, pull requests, and dynamic environments to test changes before they reach your end users. This guide covers the core workflows for keeping Omni in sync with dbt, collaborating with Git, and managing the end-to-end development lifecycle.

​
Common questions

Omni supports both bottom-up (dbt to Omni) and top-down (Omni to dbt) development patterns.
No. Omni handles the connection using a centralized deploy key or integration. You can manage which users have permission to push changes within Omni’s internal settings.
Yes, shared model changes are automatically rebased and picked up by other branches upon merge.
No. Draft changes do not get rebased. If multiple people edit the same document draft, subsequent merges can overwrite previous changes. Coordinate with others when collaborating on the same dashboard to avoid accidental overwrites.
Yes. Folder-structured branch names aren’t automatically matched between Omni and dbt, so you’ll need to manually repoint your dbt branch to the working branch in the Omni model IDE to keep the workflows synced.
Before merging your branch, use Omni’s Content Validator to find and fix any broken references (e.g., a deleted column). You can fix these globally from the validator interface before the changes go live.

​
Requirements

To follow the workflows in this guide, you’ll need:

​
Governance and SDLC controls

For teams requiring governance, Omni supports a software-engineering-style development lifecycle. Three Omni features make this possible:
  • Omni’s Git integration, which allows you to sync your Omni model to a Git repository and enforce pull requests for all model changes.
    We recommend having separate Git repositories for your dbt code and your Omni code.
  • Dynamic environments. Use connection environments to swap entire databases or dynamic schemas to swap underlying schemas within a single connection. This allows you to point an Omni branch at a CI schema to test breaking changes.
  • Content drafts. Drafts allow you to iterate on dashboards privately. You can attach these drafts to specific branches to see how underlying model changes impact the visualization.

​
Bottom-up: dbt to Omni

This is the standard flow where you define core logic (tables, views, schemas) in dbt. Omni inherits this logic, including descriptions and metadata, so you only have to define it once.
1

Prepare the data and code

Before Omni can detect a new model, it must be materialized as a table or view in your database and committed to your dbt Git repository so Omni can access the metadata.
  1. Materialize your dbt model. Run dbt build (or dbt run) against your development target. Omni cannot query a model that hasn’t been materialized in your database yet.
  2. Push to Git. Push your dbt code to a feature branch in your Git provider.
2

Sync with Omni

  1. Create a branch. In the Omni model IDE, create a new branch for testing changes from dbt.
  2. Switch dbt environments. Use the environment selector in the Omni header to point your branch to your dbt development environment.
    Switching dbt environments requires Virtual Schemas to be configured.
  3. Refresh the schema. Click Model > Refresh Schema. Schema refreshes trigger Omni to pull the updated manifest from Git and the new table structures from your database.
3

Model and validate

  1. Develop in Omni. Your new dbt model will display in the IDE. You can now add it to topics, define joins, or create measures.
  2. Validate Omni content. Use the Content Validator to see how your changes impact existing dashboards. You can perform a global find-and-replace for renamed fields across all content if needed.
  3. Merge and publish. Once your dbt pull request is merged, merge your Omni branch to promote your metadata changes to production.

​
Top-down: Pushing changes from Omni to dbt

If you’d rather model visually, Omni also lets you push transformations from the Omni UI back to dbt. You can also restrict this workflow to specific users based on Omni data permissions. See Creating new dbt models from Omni queries for the full workflow.
Use Omni as a prototyping layer. Build views in Omni first to test if they provide value before committing to the full dbt materialization process.

​
Next steps