Data Authorization — Domains

Monte Carlo's authorization model has two distinct layers that work together:

1. Permission authorization — Can this user perform this action? (e.g., can they edit monitors?)
2. Data authorization — Can this user perform this action on this specific data? (e.g., can they edit monitors in Domain X?)

Roles and policy statements handle the first layer. This page covers the second: how domain and connection restrictions on authorization groups limit which specific sets of data a user can access.

How domain restrictions work

When you create an authorization group, you can optionally restrict it to one or more domains. This scopes whatever permissions the group's roles grant to only the data assigned to those domains.

A user who is domain-restricted must pass both checks to access any specific data asset/monitor/alert (object in this doc):

• They have the required permission (e.g., monitors/access: allow)
• The object they are accessing is assigned to one of their authorized domains

If either check fails, access is denied.

Users with no domain restrictions (i.e., all their groups are unrestricted) skip the second check entirely — they can access any data in their account that their permissions allow.

What is domain-scoped

Domain restrictions apply to data objects that can be assigned to domains. This includes:

• Assets
• Monitors
• Alerts

Some data is inherently account-level and is not affected by domain restrictions:

• Data sources / warehouses — These are account-wide. A domain-restricted user can still see the data sources their account has connected; domain restrictions don't prevent them from reading warehouse metadata.
• Settings — Account configuration (users, groups, integrations, etc.) is governed by permissions alone.

Note: For objects that are not domain-assignable, the data authorization check is skipped. The permission check still applies.

Assigning objects to domains

Assets need to be assigned to a domain for domain-restricted users to access them. You can assign assets to domains from the domain settings page or from the Assets section.

If a domain-restricted user tries to access an object that has not been assigned to any of their authorized domains, the request is denied — even if the object has no domain assignment at all. No assignment does not mean visible to all; it means visible only to unrestricted users.

Using reference domains

Teams often need to check their own data against common or conformed assets that another team owns or maintains. A monitor might join to a shared dimension, look up a value in a mapping table, or compare counts against a source of truth.

A reference domain is a read-only grant for exactly that: a consuming domain's monitors can use assets another domain is responsible for, and that responsibility doesn't move.

To decide between assigning assets to a domain (owned assets) and referencing a domain (reference assets):

• Assign assets to your domain when your team is responsible for the data. Assignment is what drives coverage, reporting, and alert routing.
• Reference another domain when your monitors only need to read its assets and your team doesn't own or maintain them. Reference assets aren't counted toward your domains coverage, reporting, or alerts.

A monitor belongs to the consuming domain, and must cover at least one of that domain's owned assets. To monitor reference assets on their own, create the monitor in the domain they're assigned to.

For example: Marketing validates its own data against core.dim_customer, an asset assigned to Platform. Adding Platform as a reference domain of Marketing lets Marketing's monitors read it. The asset stays with Platform; the monitor belongs to Marketing.

Tip: If an asset is assigned to several domains only so their monitors can reach it, assign it to the domain whose team owns it and reference that domain from the others. Their monitors keep working, and the asset leaves the other domains' counts, coverage, reporting, and table monitors.

Configuring reference domains

1. Create or edit the consuming domain
2. In the Reference domains field, select the domains to read from

Setting a reference domain requires editor access or higher to both domains, and both domains must be in the same account. Viewing a domain's references is limited to users who can access those domains.

Once a reference domain is defined:

• Metric, comparison, custom SQL, and validation monitors can cover owned and reference assets. Reference assets appear in the asset picker for users authorized for them, and can be used in a SQL query for joins and lookups.
  • Table monitors are unaffected. They don't pick up reference assets, so pipeline alerts stay with the team that owns them.
  • JSON schema, query performance, and agent monitors are unaffected.
• References don't chain. Referencing a domain grants its owned assets only, never the assets of domains it references in turn.
• A reference grants domain-to-domain access, not user access. It decides which assets a domain's monitors may read; authorization groups still decide which domains a user may work in.
• Monitor authors need authorization for each reference domain they use. Creating or editing a monitor over a reference asset is rejected otherwise.

Note: Removing a reference domain will impact any monitor that depended on it. Runs fail at the next check until you restore the reference or edit the monitor.

Domain access across multiple groups

If a user belongs to multiple domain-restricted groups, their effective data access is the union of all their groups' allowed domains for a given permission. For example:

This user can edit objects in Finance Domain and view objects in Platform Domain. They cannot edit objects in Platform Domain (Viewer role) or access objects in any other domain.

Warning: If a user is a member of any group with no domain restriction (including the managed "All" groups like "Editors (All)"), that group's permissions apply to all domains. This overrides any more specific domain restrictions from other groups for those permissions. If you intend to limit a user to specific domains, ensure they are not in any unrestricted groups.

Practical patterns

Restricting a team to a specific domain

1. Create a domain and assign the relevant tables/assets to it
2. Create a custom authorization group with the desired role and select that domain as the restriction
3. Add the users to that group — do not also add them to any managed "All" group

Giving a user access to multiple domains

Add the user to separate domain-restricted groups, one per domain. Their effective data access is the union of those domains.

Read-only access to one domain, full access to another

The user can read data in Reporting Domain and read/write in Ops Domain. No access outside those two domains.

How connection restrictions work

Authorization groups can also be restricted to specific data source connections (warehouses and other integrations). This is separate from domain restrictions and limits which underlying data sources a user can access, regardless of domain membership.

A connection-restricted user can only see data that originates from one of their allowed connections. If a user has both domain restrictions and connection restrictions, both apply simultaneously — they can only see data that is in an authorized domain and comes from an authorized connection.

Users with no connection restrictions can access data from all connections in the account (subject to their domain restrictions and permissions).

Connection restrictions are configured per authorization group the same way domain restrictions are — see Managing authorization groups.

Note: Connection restrictions are available on select plans. If you don't see this option when configuring a group, contact your Monte Carlo representative.

Checking effective data access

To see which domains a user has access to for a given permission, use the permission inspector on the user's detail page. The inspector shows resolved permissions and the domain restrictions in effect.