Skip to main content
When you manage multiple departments or distributed data teams, a centralized modeling approach can become a bottleneck. By leveraging a layered system of connections and models, you can empower individual teams to own their data products while you preserve core governance. This is especially relevant if:
  • Your verticalized teams need to own their own data models
  • Your central data team is overwhelmed by team-specific metric requests
  • You provide custom metrics for external tenants
  • You need region-specific localizations or cache policies without altering the core model
This guide walks through a layered architecture for scaling Omni across multiple teams — from choosing how to organize your database connections, to building a governed shared model as your foundation, to letting individual teams extend that model for their own needs. It also covers how to use folders and permissions to control who sees what.

Structure connections for scale

The first layer of your architecture is the database connection. Since each model in Omni is tied to a single database connection, the way you organize your connections directly shapes how you’ll structure your models. There are two common patterns for connecting databases at scale:
  1. One database per model: Each database gets its own connection and shared model. This gives you the most isolation — teams can work independently — but it also means managing more models. Use shared model extensions to let teams customize without duplicating the core model.
  2. Dynamic connections, one model: Use dynamic connections to route users to different database connections (e.g., production vs. staging, or region-specific replicas) while sharing a single model definition. Be aware that tables must be structurally consistent across environments, or you’ll see validation errors.
Regardless of which pattern you choose, you can also use OAuth to delegate access control to your warehouse. If your database — like Snowflake — already manages user-level permissions, OAuth lets those flow directly into Omni so you don’t need to duplicate access controls in the semantic layer. The tradeoff is that OAuth bypasses the shared cache, which. means queries will rely solely on the performance of your database. Diagram showing three patterns for connecting multiple databases in Omni

Extend the shared model

In a distributed organization, your core data team typically governs the shared model — the canonical source of truth — while departmental analysts manage shared model extensions. Extensions let teams modify logic in a “forked” environment against the same database connection without affecting the parent model. Extensions inherit everything from the upstream shared model by default, so they’re additive — if you need to exclude specific objects, you’ll need to manually hide them. This makes getting started with extensions straightforward, but keep these governance considerations in mind:
  • Upstream logic can be overwritten: Users with edit permissions to an extension can overwrite any logic from the upstream model, including data access policies. Establish clear ownership and review processes for extension changes.
  • Connection-level access still applies: Developers can access all views allowed by the underlying connection credentials, regardless of what the model exposes. Keep this in mind when scoping connection permissions.
  • Performance at scale: As your model grows, use offloaded schemas to defer loading metadata for specific schemas until they’re explicitly needed. This keeps the field browser responsive.
Diagram showing how to configure shared model extensions

Manage version control

Full Git support for extension models is a work in progress. Currently, Git workflows only apply to the base shared model — extensions use Omni’s native branching.
If your organization uses Git, you can integrate it with Omni to manage version control for your shared model. When planning your repository structure, there are three common strategies:
StrategyDescriptionBest for
MonorepoParent model and extensions live in one repo; use CODEOWNERS for controlTeams that need visibility across models and want to manage dependencies in one place
Isolated reposSeparate repo per modelTeams that need strict isolation and independent release cycles
HybridSensitive extensions use isolated repos; others use a monorepoOrganizations balancing security requirements with cross-team collaboration

How Git syncing works

Since Git isn’t yet native to extensions, it’s important to understand how Omni interacts with your repository:
  • Extensions store diffs, not full models: Extensions use extension-only mode, recording only changes relative to the parent. This keeps your repo clean but means you can’t reconstruct an extension without its parent.
  • Syncs occur only on merge: Omni monitors for merges to the main branch and copies those changes to its internal record. Changes on other branches won’t appear until they’re merged.
  • Branching may behave differently than expected: Omni uses its own internal database for version control, so branch behavior may not match standard Git workflows exactly.

Manage content access

With your shared model and extensions in place, the next step is making sure the right people can access the right content.

Control document access with folders

Folders are the primary mechanism for controlling who can see and interact with your content. Understanding how permissions cascade from folders to documents will help you design a folder structure that scales with your team.
  • Permissions flow downward: Workbooks and dashboards inherit permissions from their parent folder. You can grant broader access at the document level, but you can’t make a document more restrictive than its folder — so plan your folder structure around your most restrictive access needs first.
  • Visibility is model-aware: Users only see documents associated with models they have permission to access. For workbooks that pull from multiple topics, users will see charts from their authorized topics but get an error for any charts tied to topics they can’t access — so avoid mixing broadly-shared and restricted topics in a single workbook when possible.
Diagram showing shared model extension access control

Increase permissions with AccessBoost

In a scaled deployment, you may have dashboards intended for a broad audience — like executives or external stakeholders — who don’t need to build their own queries but do need to see results from topics or fields they wouldn’t normally have access to. AccessBoost solves this by selectively elevating permissions at the dashboard or folder level. This allows users with lower-level connection roles - like Restricted Querier or Viewer — to view all data on a boosted dashboard, even content built with SQL they wouldn’t normally have access to.

Next steps