Custom Role Recipes

Here are some ready-to-use custom role patterns for common authorization scenarios. Each recipe includes a YAML role definition and guidance on how to use it.

For background on creating custom roles, see Managing roles. For how policy statements and effects work, see Policies and permission resolution.

Restricting billing access

You may want technical staff to have full access to Monte Carlo's data features without being able to view or modify billing information. This is common when billing is managed by a finance team or department head.

Follow the extend/modify approach, combining with mcd/owner and a custom role that:

• denies billing permissions
• denies managing owners (to prevent escalation of privilege)

iam-role:
  version: 2026-01-27
  name: owner-no-billing
  label: "Owner (No Billing)"
  description: "When combined with mcd/owner, allows full access except viewing or modifying billing."
  permissions:
    settings/billing/*: deny
    settings/authorization-groups/manage-owners: deny

How to use: Create an authorization group with both the mcd/owner role and this owner-no-billing role. Users in that group get full owner access except they cannot view or change billing information, or promote users to owner.

Managing access to sampling data

Sampling data can be sensitive, so you may want to restrict access to it.

👍

Note that you can also disable sampling per integration or configure it more granularly by selecting which types of assets have sampling enabled at the integration level. To learn more, see here.

The permission controlling sampling data access is monitors/data-sampling/access. Currently, only mcd/owner and mcd/domains-manager grant this permission via their monitors/*: allow wildcard. The mcd/editor role explicitly denies it.

Granting sampling access

To grant sampling access to users who don't have it through their built-in role, follow the extend/modify approach, combining a built-in role (like mcd/editor) with a custom role that:

• allows data sampling access

iam-role:
  version: 2026-01-27
  name: allow-data-sampling
  label: "Allow Sampling Access"
  description: "Grants access to sampling data."
  permissions:
    monitors/data-sampling/read: allow

Note: Denies beat allows when policies are resolved at the same level of specificity. So if the role you are combining this with specifies the same path (e.g., monitors/data-sampling/read: deny), deny would still win. In that case, you may need to specify the individual permissions to override.

Blocking sampling access

Conversely, set the effect to deny to explicitly block sampling data access — useful if you want to override the default grant from mcd/owner or mcd/domains-manager:

iam-role:
  version: 2026-01-27
  name: deny-data-sampling
  label: "Deny Sampling Access"
  description: "Denies access to sampling data."
  permissions:
    monitors/data-sampling/read: deny

Limiting to subsets of sampling data

To grant access to only a subset of sampling data you must use domain authorization, which combines with roles in authorization groups to further scope the defined auth to particular assets in Monte Carlo. This restricts access to sampled data based on the assets monitored for a given monitor. The steps are:

1. Create a domain that defines the subset of data you want to allow.
2. In the authorization group editor, under Access, choose Restrict to domains and select your domain.
3. Under Roles, include both your desired built-in role and the allow-data-sampling role above. Alternatively, if the built-in role already allows data sampling access, you only need to include that with the domain restriction(s).

Users in this group will only be able to access sampling data within the scope of the assigned domain(s).

Note: To restrict sampling data for all users in your account, use the sampling data restrictions in the integration settings for a given warehouse. Domain restrictions on authorization groups operate in addition to those integration-level restrictions.

Controlling access to specific types of monitors

Monitor management permissions are organized by monitor type (e.g., monitors/management/custom-sql/*, monitors/management/table/*). This lets you define custom policies that control which types of monitors specific users can access, draft, or edit. See IAM Resources and Permissions for the full list of monitor type permission paths.

Combine these custom roles with a built-in role like mcd/monitor-editor in an authorization group using the extend/modify approach. The user retains all other permissions from the built-in role while the custom role overrides only the monitor type access you specify.

Blocking a specific monitor type

To exclude a specific monitor type, deny its permissions. For example, custom SQL monitors allow users to execute arbitrary SQL queries against your data warehouse — some organizations want to restrict this to a smaller set of trusted users to prevent accidental costly queries:

iam-role:
  name: no-custom-sql-monitors
  label: No Custom SQL Monitors
  description: Allows using/managing all kinds of monitors except custom SQL.
  restrictions_summary: Denies accessing, drafting, or editing custom SQL monitors.
  recommended_for: Users in our organization who should not be able to design
    custom SQL monitors.
  permissions:
    monitors/management/custom-sql/*: deny

How to use: Create an authorization group with both the mcd/monitor-editor role and this no-custom-sql-monitors role. Users in that group get full monitor editing capabilities except they cannot view, create, or modify custom SQL monitors.

The monitors/management/custom-sql/*: deny wildcard denies all operations on custom SQL monitors — access, edit, and draft. Because this is more specific than the broader monitors/*: allow granted by the built-in role, the deny takes precedence.

You can deny multiple monitor types in the same role by adding additional statements — for example, monitors/management/comparison/*: deny alongside the custom SQL deny.

Allowing only a specific monitor type

To invert the pattern and only allow a specific monitor type, deny the broad wildcard and then carve out an exception:

iam-role:
  name: table-monitors-only
  label: Table Monitors Only
  description: Only allows table monitor management.
  restrictions_summary: Denies all types of monitor access/management except for table monitors.
  permissions:
    monitors/management/*: deny
    monitors/management/table/*: allow

Here monitors/management/*: deny blocks all monitor types, and the more specific monitors/management/table/*: allow carves out an exception for table monitors. Users in this group can only work with table monitors while retaining all non-monitor-management permissions from the built-in role.