Skip to main content
Shared extension models let you create tenant-specific versions of a parent model. The parent model defines the core logic - joins, topics, metrics - and each extension inherits that logic while allowing its own customizations.

​
When to use shared extensions

Shared extensions may be a good fit when:
  • You manage a multi-tenant environment and need to give each customer a tailored data experience
  • You have a core set of metrics and joins that should be consistent across all customers
  • You want customers to build their own content without affecting other tenants
  • You need to programmatically provision and route users to siloed data views at scale
Shared extensions are not recommended for:
  • Environments where every customer requires a completely different schema or data source with no common logic
  • Situations where changes made by one customer should flow back up and be visible to everyone else

​
Requirements

To follow the steps in this guide, you’ll need:
  • To have shared extension models enabled. Contact Omni support to have this feature enabled.
  • Organization Admin or Connection Admin permissions for the connection you want to work with in Omni.

​
Creating shared extensions

1

Create the extension model

  1. Navigate to the Develop menu and select your parent connection.
  2. Open the model and click Model > New Shared Extension.
  3. Enter a name for the extension (e.g., customer_3).
  4. Optional: Select the checkbox to allow the extension to be explored. Enable this option if you want users to build their own content off the extension rather than viewing existing dashboards.
2

Define model visibility with user attributes

Next, you’ll use user attributes to control which model extension a user sees when accessing or building content.
  1. Navigate to Settings > Attributes.
  2. Click New Attribute.
  3. Define a name and a reference (e.g., customer_attribute).
  4. Assign the appropriate attribute value to your users.
3

Map user attributes in the model

To route users to the correct extension, you’ll add a mapping to the parent model using the dynamic_shared_extensions parameter.
  1. Click Develop in the left navigation.
  2. Navigate to the parent model.
  3. In the model file, create the attribute mappings:
    In this approach, you use the mappings parameter to create individual mappings to user attributes:
    Manual mapping
    dynamic_shared_extensions:
  user_attribute: customer_attribute # User attribute reference
  mappings:
    customer_3:                      # User attribute value
      model: customer_3              # Extension model name
    customer_2:
      model: customer_2
    Only one of the mappings or map_pattern parameters can be used at a time.
  4. Save the changes.
4

Define default access for users

Setting default access levels ensures users only see the data intended for them.To start, set your parent connection base access to No Access. This prevents users from building off any extensions until you explicitly grant permission.
  1. Click Settings > Connections.
  2. In the list of connections, click the parent connection of the extension model.
  3. Click the Permissions tab.
  4. Set the connection’s Base Access to No Access.
  5. Click Save changes.
  6. Choose how to approach permissions:
    Even with No Access applied to the specific child extension, Omni will automatically route the user to the proper model when they view or build content. This allows them to see shared dashboards while being restricted to their own data scope.To implement this approach, grant users access to the parent model - for example, as Restricted Queriers - but set all child extensions to No Access.
    When implemented, users can build off their assigned extension but will not see any shared instances or content from the parent level.To implement this approach, grant explicit access only to the specific child extension (e.g., Customer 3) and set the parent model to No Access.
5

Testing access with user impersonation

To verify that your access controls are working as expected, we recommend impersonating a test user.
  1. Navigate to your user list and select a test user.
  2. Change their user attribute to the extension you wish to test.
  3. Use the Impersonate feature to view the Omni instance through their eyes.
  4. Verify that the topics, tables, and metrics match the expected siloed or shared configuration.
Manage user permissions at scale by using the Omni API or user groups.

​
Applying changes to extended models

Changes to a parent model propagate to all extensions automatically. Changes to a child extension stay within that extension only.
I want to…Do this
Apply global changesModify the parent model. Any updates—such as removing a join or adding a shared metric—will automatically propagate to all extensions once saved.
Apply changes to one extensionEdit the specific child extension. Actions like hiding a sensitive table or customizing a metric stay siloed within that extension.

​
Troubleshooting

If users are seeing incorrect data or No Access errors, check the following:
  • Potential cause: Incorrect attribute reference in model file
  • Solution: Verify the user attribute reference (ex: my_user_attribute) matches the exact string in Settings > Attributes.
  • Potential cause: Attribute value does not match any mapping
  • Solution: Check the user’s attribute value against the mappings keys in the model YAML file
  • Potential cause: Parent model changes not saved
  • Solution: Ensure you have clicked Save in the parent model. Changes flow downstream automatically.
  • Potential cause: Extension-specific overrides are missing
  • Solution: Edit the extension model directly to apply overrides (like hiding tables) that shouldn’t affect the parent