> ## Documentation Index
> Fetch the complete documentation index at: https://docs.omni.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Using dbt constraints and deferrals
> Inherit primary keys, relationships, and column descriptions from dbt constraints, and use deferrals or dbt clone to test changes against production data.
export const CheckIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const XCircleIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const MarkdownVariablesIcon = ({label}) => {
return ;
};
export const DashboardIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const WorkbookIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const WorkbookNumberFormatIcon = ({label}) => {
return ;
};
export const DashboardPreviewIcon = ({label}) => {
return ;
};
export const DashboardCatalogIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const DashboardAddItemIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const DashboardControlIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const DashboardChartIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const DashboardPlaceholderIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const DashboardLayoutIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const DashboardTextIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const DashboardStackContainerIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const DashboardPageNavIcon = ({label}) => {
return
{label && ` ${label}`}
;
};
export const IdeFileIcon = ({color = "#000000"}) => {
return ;
};
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](/integrations/dbt/setup)
* **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](https://docs.getdbt.com/reference/resource-properties/constraints) 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.
If you run dbt locally (for example, in VS Code with a local `profiles.yaml`), you need to download the artifacts from your most recent production run first, then pass them to `dbt clone` using the `--state` flag:
```bash theme={null}
dbt clone --state /path/to/production/artifacts
```
Production artifacts are typically available from your CI/CD pipeline, an S3 bucket, or your dbt Cloud job's artifact storage.
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](/integrations/dbt/virtual-schemas#partial-dbt-builds) 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](/integrations/dbt/setup) for more information.
## Next steps
* [Connecting dbt to Omni](/integrations/dbt/setup) — Configure the dbt integration if you haven't already.
* [Working with dbt models](/integrations/dbt/models) — Author and edit dbt models from Omni.
* [Connection environments](/connect-data/dynamic-environments) — Set up dynamic environments for safe testing.