Skip to main content
Omni inherits metadata from your dbt project so your BI layer stays in sync with your transformation layer. Two dbt features do most of the work:
  • Constraints let Omni automatically pick up primary keys, relationships, and column descriptions from dbt.
  • dbt clone creates zero-copy clones of production objects in your dev schema, so Omni can resolve all table references without you having to rebuild everything.

​
Common questions

No. Cloning creates zero-copy clones of all production objects in your development schema. If you then run dbt build or dbt run on a specific model, dbt replaces that clone with the table or view built from your code. Omni picks up the new version automatically.
In many warehouses, constraints are applied to tables rather than views. If your dbt project outputs views, define constraints at the model level in dbt so Omni can still inherit that logic, even if the warehouse doesn’t enforce them on the view.

​
Requirements

  • A configured dbt integration
  • For constraints - Constraints defined in your dbt project (using dbt-constraints or native dbt constraints)
  • For deferrals - A production environment configured in Omni with successful builds

​
dbt constraints

Omni automatically inherits the semantic logic you’ve defined in your dbt project to build a baseline model.
  • Relationship inheritance: If you have primary keys and relationships defined in your dbt project, Omni can automatically create the corresponding relationships and primary keys in your Omni model. To enable this, turn on Auto-generate primary keys and relationships from dbt constraints in your dbt connection settings.
  • Description sync: Column descriptions defined in your schema.yml files are brought into Omni automatically, providing immediate context in the UI.
  • Automated joins: Omni maps join paths based on your dbt constraints. When a user combines fields from Orders and Customers, Omni joins them using the dbt-defined relationship.
Keep source-of-truth logic (like column descriptions and primary keys) in dbt, but manage Omni-specific metadata (like AI instructions or synonyms) directly in the Omni UI.
See dbt’s constraints reference for more on how constraints are defined in dbt.

​
dbt deferrals

Omni natively supports dbt deferrals through the Enable deferral checkbox in dbt environment settings. When enabled for development environments, Omni automatically resolves unbuilt models to the production build, eliminating the need for full dbt runs or manual dbt clone workflows when working with partial builds.

​
Enabling deferral in Omni

The Enable deferral checkbox appears when configuring non-production dbt environments in Omni:
  1. Navigate to your connection’s dbt tab.
  2. In the Environments section, add or edit a development environment.
  3. Check the Enable deferral box to automatically fall back to production builds for models not built in this dev environment.
When deferral is enabled, queries automatically resolve unbuilt models to production. For example, if you only build a subset of models in your dev schema, Omni will use the production version for everything else without any additional setup.
For partial builds, enable deferral when you routinely build only the models you’re actively changing, rather than running full dbt build commands.

​
Using dbt clone for zero-copy clones

While the Enable deferral checkbox handles most use cases, dbt clone remains a complementary option for creating zero-copy clones of production objects directly in your warehouse. This can be useful when you want physical copies of production tables in your dev schema:
Deferrals require at least one successful job run in the designated production environment.
  1. In dbt Cloud, enable the Defer to staging/production option in your development environment settings. This designates your production job as the reference point.
  2. Once enabled, run dbt clone from the dbt Cloud IDE.
When using dbt clone with virtual schemas, the model IDE visually highlights dev-built views with an icon and displays an environment chip to help you identify which environment is active. See Working with dbt virtual schemas for more details.

​
Troubleshooting

Omni expects every model referenced in an environment to physically exist in the target schema. If you’ve only built modified models, Omni can’t resolve the missing tables.Enable deferral for your dev environment to automatically fall back to production builds for unbuilt models. Alternatively, run dbt clone before switching environments in Omni to create zero-copy clones of all production tables. If errors persist, confirm your database user has permission to read the production schema — see dbt connection setup for more information.

​
Next steps