# Testing dbt changes in Omni before pushing to production (Omni's dynamic dbt environments)

**URL:** <https://community.omni.co/t/testing-dbt-changes-in-omni-before-pushing-to-production-omnis-dynamic-dbt-environments/401>\
**Category:** Modeling\
**Tags:** dbt\
**Created:** [October 7, 2025, 11:44pm UTC](https://community.omni.co/t/testing-dbt-changes-in-omni-before-pushing-to-production-omnis-dynamic-dbt-environments/401 "2025-10-07T23:44:29Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![conner](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.omni.co/conner/32/11_2.png) [@conner](https://community.omni.co/u/conner)\
**Post date:** [October 7, 2025, 11:44pm UTC](https://community.omni.co/t/testing-dbt-changes-in-omni-before-pushing-to-production-omnis-dynamic-dbt-environments/401/1 "2025-10-07T23:44:29Z")

</div>

When you’re editing a dbt model, a seemingly minor change (like renaming a column or updating a WHERE clause) can quietly break dozens of downstream charts. Omni’s [dynamic dbt environments](https://docs.omni.co/docs/integrations/dbt#dynamic-schemas) give you a tight software development workflow to safeguard against this.

For example, let’s say you change the name of the `revenue` field to `sales` in dbt, and you want to ensure that change doesn’t break any of your Omni dashboards and workbooks. You can build that change in your dbt development environment, point your Omni branch to your development environment, replace all references to `revenue` to `sales`, then merge everything at once to prevent breakages.

(Note: you’ll need your [dbt integration](https://docs.omni.co/docs/integrations/dbt/setup) set up in Omni, and your GitHub branches configured correctly - see [this guide](https://community.omni.co/t/how-to-work-on-dbt-models-in-omni-that-arent-yet-written-into-production/380) for more.)

The workflow generally looks like this:

- **In Omni, point to a dev environment on a [branch](https://docs.omni.co/docs/modeling/manage-develop/model-management#branch-mode):** Enter a branch in Omni, then choose which dbt environment to build your content off of. Your dashboards and reports now render against that environment, letting you see how changes you make in dev make impact downstream content.

- **Check what will be impacted:** Use Omni’s [content validator](https://docs.omni.co/docs/modeling/manage-develop/content-validator) to see which content would break due to renamed columns, removed fields, etc.

- **Resolve and retest:** “Find and replace” references across multiple pieces of content using the content validator to ensure nothing breaks when you merge your dbt changes.

- **Merge once, cleanly:** You can set up your Omni schema to refresh automatically once your dbt PR lands using a git action that calls Omni’s [schema refresh API endpoint](https://docs.omni.co/docs/API/model#refresh-a-schema). (Or, you can manually [refresh your schema](https://docs.omni.co/docs/connections/manage/connection-settings#schema-refreshes) with a click in Omni.) Once your schema pulls in those changes, you can merge your Omni branch to update your content right away — preventing any downtime.

Here’s a demo from Gordon, a solutions engineer at Omni, walking through this process:

[![](https://canada1.discourse-cdn.com/flex004/uploads/omni/original/1X/69c59c6ee1829a4abbb21f8e6ff54501dde40415.jpeg "Omni's dbt integration: Co-development between dbt and Omni") ](https://www.youtube.com/watch?v=1nXElS5up1E)