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 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 set up in Omni, and your GitHub branches configured correctly - see this guide for more.)
The workflow generally looks like this:
-
In Omni, point to a dev environment on a branch: 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 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. (Or, you can manually refresh your schema 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:
