As teams explore in Omni, useful transformations will naturally emerge. Instead of leaving them as one-off queries, you can save the query as an Omni view — a lightweight, virtual transformation (like a CTE you can reference in Omni) that’s easy to reuse and simple for end users.
When a saved view needs better performance (or otherwise warrants materialization in the database), you can create a dbt model for it. Then, the content validator can cleanly remap references from the original Omni view to the new dbt model without breakage. In effect, Omni acts as a “prototyping” layer to let you test what transformations are actually useful to your team before creating a full dbt model. (If you just need to edit an existing dbt model, you can do that in Omni, too!)
For example, here’s how a new Customer Fact table might follow this process:
-
Save query as an Omni view. An analyst creates a customer fact table by joining Orders and Customers. This gets used widely, so she turns it into an Omni view to make it easier to work with.
-
See how it gets used. As the table becomes foundational to some dashboards, materializing it in the database would significantly improve performance.
-
Build in dbt. The analyst recreates the table in a new dbt model, fct_customers (alternatively, if you had an existing model you wanted to update, you can do so from Omni as well).
-
Swap safely with the content validator. Use Omni’s content validator to bulk-remap references from the Omni view to the new dbt model, with schema compatibility checks and a preview of impacted content (this is where the co-development pattern comes in handy).
-
Retire the original Omni view. Deprecate or drop the original “Customer Fact” Omni view once everything points to the dbt model to avoid misalignment.
Here’s a quick tutorial from Sara, one of Omni’s solutions engineers, on how this process works:
