Skip to main content

​
Building Blocks of Authorization: Rules, Policies, and Roles

Collate controls access through three building blocks: rules define what is allowed or denied, policies group rules together and apply them to teams, and roles bundle policies into job-function templates you can assign to users. Every access decision Collate makes comes down to three questions: who is the user, what are they trying to access, and what do they want to do with it?

​
Rules

A rule in a policy is the building block of authorization. It contains the following:
  1. Name: A unique name to define the rule
  2. Description: Description of the rule
  3. Resources: List of resources this rule applies to. An admin can select a specific resource, such as Table or All, to apply against all resources.
  4. Operations: List of operations this rule applies to. An admin can select a specific operation such as EditOwners or All to apply against all the operations.
  5. Condition: Expressions written using policy functions that evaluate true or false.
  6. Effect: Deny or Allow the operation.
Building Blocks of Authorization: Rules

​
Operations

When you build a rule, you pick one or more operations to cover. Each operation controls a specific action – for example, ViewAll, EditTags, or Delete. Operations vary in risk level, from low-risk viewing permissions to critical admin-only actions like Impersonate, EditPolicy, EditRole, and GenerateToken. For a reference for common operations, risk levels, and recommended role assignments, see Resource scope and operations reference.
Important: EditAll overrides every other edit permission. Only use it when full editing access is intentional – otherwise assign the specific edit operations you need.

​
Condition

Conditions let you make a rule apply only when certain things are true about the asset being accessed. For example, you can write a rule that only applies to assets tagged as PII.Sensitive, or only to assets that don’t have an owner yet. Collate uses SpEL-based expressions for conditions. For more information about SpEL expressions, see Spring Expression Language (SpEL). Following are some examples of conditions:

​
Use hasDomain() With Bots

hasDomain() evaluates the domains on the requesting principal. For a bot request, the principal is the user account associated with that bot. Assigning a domain only to the asset does not give the bot access. For example, a bot with a policy that allows ViewBasic only when hasDomain() is true receives a 403 [ViewBasic] not allowed response when the asset belongs to Finance but the bot user does not. To resolve the error:
  1. Open Settings > Bots, select the bot, and identify its associated bot user.
  2. In Settings > Members > Users, open the bot user’s profile.
  3. Add the asset’s domain in the Domains card. An administrator must make this change.
  4. Retry the request after the domain assignment is saved.
If the bot must read assets across domains, use a separate policy without the hasDomain() condition and limit its resources and operations to the minimum required. Removing the condition allows the rule to match resources outside the bot’s domains. Roles Based Access Controls (RBAC) Search supports only some of these conditions. It evaluates noOwner(), isOwner(), matchAllTags(), matchAnyTag(), hasDomain(), and inAnyTeam(). It ignores matchTeam() when it filters search results. Access to the asset itself still honors matchTeam(). To limit search results by team, use isOwner(). In search, it also matches assets owned by any team the user belongs to. The inAnyTeam('<team>') condition checks only the user’s team membership: if the user is in that team, it matches every asset. Use conditions to assess data assets like Tables, Topics, and Dashboards for specific attributes. Example: Consider the noOwner() condition when applied to the table fact_orders. If this table lacks an assigned owner, then the condition returns true. However, if an owner is present, it returns false. Another instance: The matchAnyTag(‘PII.Sensitive’) condition, when applied to the dim_address table that carries the PII.Sensitive tag, will yield true. But, without this specific tag, the outcome is false. You can combine conditions with && (both must be true) or || (either can be true). For example:
This condition is true only if the asset has no owner and carries both of the listed tags.

​
Use Service Attributes in Policy Conditions

Every service can store three deployment attributes.

​
Set Service Attributes

You need permission to edit the service.
  1. Navigate to Settings > Services.
  2. Select the service category, then open the service you want to configure.
  3. Click the Connection tab. Connection tab on a service page
  4. In the Service Attributes section, click Edit. Service Attributes section with the Edit button highlighted
  5. Complete the following steps:
    • Select an Environment.
    • Optional: Enter the Region and Deployment identifier.
    Service Attributes configured with an environment, region, and deployment
  6. Click Save.
The attributes apply to the service. You do not need to add them separately to every asset ingested from that service. Service-aware conditions let one rule cover the service and the assets it ingests: The referenced value must exist when you save the policy. These conditions return false for resources that do not belong to a service. Examples include glossary terms and users. For example, the following condition can be used in a Deny rule to prevent access to assets from development services:
Apply the rule to the required resources and operations. A service is treated as its own service, so a matching Deny rule can hide both the service and its assets.

​
Create a Service-Scoped Policy Rule

Test the rule in an unassigned policy before applying it to users or teams.
  1. Navigate to Settings > Access Control > Policies.
  2. Create a policy or open the policy.
  3. Click Add Rule.
  4. Complete the following steps:
    • Enter the Rule Name.
    • Optional: Enter a Description.
    • Select the required Resources and Operations. For example, select All and ViewAll to evaluate view access across service-backed resources.
    • Set Effect to Deny or Allow. When rules conflict, Deny takes precedence.
    • In Condition, enter a service-aware expression. For example:
      Confirm that the editor reports Valid condition.
    Policy rule with a valid service environment condition
  5. Click Create.
Review the policy with the Permission Debugger before assigning it to a production team.
Service-aware conditions apply to search-backed results, direct entity requests, and create operations. A plain entity list API, such as GET /v1/tables, does not resolve an individual entity for its authorization check and cannot evaluate these conditions per result. Do not use an unfiltered list endpoint as a security boundary for a service-scoped policy.

​
Understand Inherited Service Tags

Tags now pass down automatically through the service hierarchy. For example, a tag on a database service is inherited by its databases, database schemas, and tables.
  • Collate marks inherited tags as Derived.
  • Inherited tags are merged with the tags assigned directly to the child asset.
  • If the child asset already has the same tag assigned directly, the child’s tag takes precedence.
You cannot remove a derived tag from a child asset. To remove it, go to the parent where the tag was assigned and remove it there. Policy conditions such as matchAnyTag(...) also evaluate inherited tags.
After you upgrade, reindex Collate so existing assets receive their inherited tags in search. Until reindexing finishes, an asset’s own page can show inherited tags before they appear in Explore.

​
Restrict Requests Made Through Bots

Use impersonation conditions in Deny rules to restrict actions attributed to a bot acting on a person’s behalf. This includes requests that use the X-Impersonate-User header and Model Context Protocol (MCP) or Collate AI tool calls. Use this condition to match every request attributed to a bot:
To restrict a specific bot, use its existing bot name:
You can combine isImpersonated() with matchAnyTag(...) to protect tagged assets. The tag’s fully qualified name must already exist in Collate or the condition will be invalid. Put isImpersonated() before the tag condition so ordinary requests can stop evaluation before Collate loads the tags. When you use impersonatedBy(...), the supplied name must resolve to a bot or to its bot user.

​
Create a Bot Attribution Rule

Create the rule in an unassigned test policy first. A broad impersonation Deny rule can block MCP and Collate AI tool access to matching resources.
  1. Navigate to Settings > Access Control > Policies.
  2. Create a policy or open the policy.
  3. Click Add Rule.
  4. Complete the following steps:
    • Enter the Rule Name.
    • Optional: Enter a Description.
    • Select the required Resources and Operations.
    • Set Effect to Deny.
    • In Condition, enter isImpersonated() or impersonatedBy('<existing-bot-name>'). Confirm that the editor reports Valid condition.
    Deny rule with a valid impersonatedBy condition for McpApplicationBot
  5. Click Create.
Use the Permission Debugger to verify the expected result before assigning the policy.
These functions report bot attribution. They do not verify that an impersonation grant was authorized. Use them in Deny rules. They apply when Collate performs a per-entity authorization check, but they do not filter results returned directly by search_metadata, semantic_search, or nlq_search.

​
Default Rules

Go to Settings > Policies > Organization Policy to see the three rules that come built in and apply to everyone in your organization. Organization Policy showing the default rules
  • OrganizationPolicy-NoOwner-Rule Organization Policy - No Owner - Rule This rule lets any user assign ownership to an asset that doesn’t have an owner yet. Once an owner is assigned, the rule no longer applies to that asset. For example, if a user accesses fact_table and finds that it is unowned, then they can modify the ownership field to establish a new owner. However, for a table like dim_address that already has an assigned owner, any attempt to change the ownership will be restricted.
  • OrganizationPolicy-Owner-Rule Organization Policy - Owner - Rule This rule gives the owner of an asset – or any member of the owning team – full access to edit and view all its details. When a user, who either personally owns a table or is part of the team owning that table logs in, they’re granted extensive rights. They can modify all properties of that data asset and access complete information about it.
  • OrganizationPolicy-ViewAll-Rule This rule lets every user view every asset. It has no condition, so it applies to all users and all assets, whether or not they own the asset or belong to its team. This is why everyone can find and open any asset in Explore by default. With RBAC Search turned on, this rule still applies. For more information, see Roles Based Access Controls (RBAC) Search.
By setting up such default rules, the organization ensures clarity in access control based on ownership status and user roles.

​
Policies

A policy is a named group of rules. When you access a resource in Collate, it checks all the rules in all the policies that apply to your account and decides whether to allow or deny the action.

​
How Policies Work

When rules conflict If two rules in the same policy disagree – for example, one allows EditDescription and another denies it – the Deny always wins. How policies are assigned Policies are assigned to teams, not to individual users. When you’re added to a team, you automatically inherit all the policies assigned to that team. Inheritance and Application Inheritance and Application Any user positioned within a team structure inherently adopts its policies. For instance, if the “Organization-NoOwner-Policy” is instituted at the organization’s apex, all its internal members will be governed by this policy and the rules therein. Similarly, if a policy is assigned to “Division1” such as “Division Policy”, every member – whether “Department”, “Team1”, “Team2”, or individual users in these groups – falls under its scope. However, if you create a policy specifically for “Team1”, only its members are affected. Policy Design Principles This architecture sets broad rules at the organizational level, with more lenient defaults at the top. Teams can then define stricter, more tailored policies as you move down the hierarchy. For example, a policy can say: ‘Deny access to everyone outside of Team 1.’ This gives you flexibility at the top and precision where it matters most. When designing policies for sensitive processes, it’s also worth thinking about who should hold which permissions – not just what the permissions are.

​
Separation of Duties

For teams with compliance or regulatory requirements, it’s good practice to make sure no single person can complete a sensitive process from start to finish on their own. Split the steps across two roles so each one requires a different person.

​
Roles

A role is a ready-made bundle of policies that matches a job function. Instead of assigning individual policies to every user, you assign them a role and they get all the right policies in one step. Building Blocks of Authorization: Roles Roles can be assigned to individual users or to entire teams. When a role is assigned to a team, every member of that team gets it automatically – which makes onboarding and offboarding much simpler. Some common examples of how roles map to job functions:
  • Data engineers build and maintain data assets – they need Create, Deploy, and Trigger
  • Analysts explore and use data – they need ViewAll, ViewUsage, and ViewQueries
  • Data stewards manage governance – they need EditTags, EditGlossaryTerms, and EditCertification
A role bundles multiple policies that match a specific job function. For example, a “Data Consumer” role includes a “Data Consumer Policy.” Anyone assigned that role – whether an individual or a team – automatically gets all the permissions defined in those policies.

​
Common Mistakes to Avoid

Important: This has been enforced since Collate 1.12.9. Triggering an ingestion pipeline through the API (POST /v1/services/ingestionPipelines/trigger/{id}) now requires the Trigger operation to be explicitly granted — EditAll no longer covers it. The upgrade automatically added Trigger to the default bot policies (Ingestion, Lineage, Profiler, Quality, Usage) and the default Data Steward role.If you have a custom role or policy that grants EditAll on Ingestion Pipeline without an explicit Trigger grant, add Trigger to it after upgrading — otherwise pipeline triggers will start failing silently for anyone assigned that role. Scheduled runs are unaffected. This only applies to manually or programmatically triggered runs.
By default, every user can search for and find any data asset in Collate, regardless of whether they have permission to access it. If you want search results to reflect each user’s permissions, turn on RBAC Search. Search then shows only the assets that the user’s policies allow them to see. The built-in Organization Policy allows everyone to see every asset, so this takes effect only after you change that. For more information, see How Search Combines Your Policies. To enable or disable this, go to Settings > Preferences > Search. Roles Based Access Controls (RBAC) Search Option

​
What Changes When You Turn It On

Search results are filtered by permission – users only see assets their role gives them access to, which helps with data security and compliance. Permissions apply at the point of discovery – users can’t find or browse assets they’re not allowed to access, even through search.

​
How Search Combines Your Policies

RBAC Search combines the rules from all of a user’s policies, including the Organization Policy. An asset shows up in search if at least one allow rule lets the user see it, unless a deny rule blocks it. Search only looks at rules that grant ViewBasic, ViewAll, or All. It skips every other rule. The Organization Policy includes OrganizationPolicy-ViewAll-Rule, which grants ViewAll on all resources with no condition. Because of this rule, every user sees every asset in search, even with RBAC Search turned on. A role that grants ViewAll only under isOwner() doesn’t change this. The unconditional rule still shows non-owned assets. Any other policy with an unconditional rule that grants ViewBasic, ViewAll, or All has the same effect. Examples are the policy of the Data Consumer role and a read-only viewer policy that grants ViewBasic on tables. For strict isolation, make sure no policy that applies to the user grants ViewBasic, ViewAll, or All without a condition. To change the Organization Policy, go to Settings > Policies > Organization Policy, and either delete OrganizationPolicy-ViewAll-Rule or add a condition such as isOwner() to it. Collate doesn’t restore the built-in rules when the server restarts. Owners and owning teams keep access through OrganizationPolicy-Owner-Rule.
ViewAll also lets users view an asset’s details, not only find it in search. After you remove an unconditional ViewAll rule, users can open only the assets that another rule gives them access to.

​
Before You Turn It On

Check your roles and policies are fully configured – make sure every user and team has the right permissions for the assets they need. Incomplete configuration can cause users to lose visibility of assets they should see. Check for unconditional ViewBasic, ViewAll, and All rules: if you need users to see only some assets, review every policy that applies to them. Test with real users after enabling – ask someone from each role to run searches and confirm they’re seeing the right results. For a full guide on setting up roles and policies, see Roles and Policies. Enabling RBAC Search makes sure Collate’s search aligns with your organization’s data governance and access requirements.

Use Cases: Creating Roles & Policies in Collate

Tailor your policies to meet your organizational and team needs.

​
Troubleshooting: Queries Tab Is Empty for Non-Admin Users

If a table has queries and an admin can see them, but a non-admin user sees an empty Queries tab, check the following in order:
  1. RBAC Search: Go to Settings > Preferences > Search and check whether RBAC Search is on. When it is on, policies filter the Queries list, so continue to step 2. When it is off, search results aren’t filtered by policies, so go to step 3.
  2. Query resource rule: Confirm that one of the user’s policies has an Allow rule on the Query resource with ViewAll (or All) and no isOwner() condition. Table-level ViewAll or ViewQueries doesn’t control this tab. Owning the table doesn’t help either, because isOwner() in search matches the owners of the query.
  3. Query ingestion: Confirm that query ingestion has run for the service. An admin should see the queries on the table.
  4. Permission Debugger: Use the Permission Debugger to evaluate ViewAll on the Query resource for the affected user.