Apply request settings automatically with entitlement routing rules

Use entitlement routing rules to resolve the request policy and access request settings for many entitlements at once, based on conditions you define—including conditions that match the role and scope of sparse apps.

What are entitlement routing rules?

Entitlement routing rules are app-scoped rules that automatically determine which request settings—the request policy, emergency grant behavior, and maximum grant duration—apply when someone requests an entitlement. Instead of opening each entitlement and configuring its request settings by hand, you write a small, ordered set of rules that match entitlements by their attributes and apply the right settings to every matching entitlement, including entitlements that are created later but fit the same pattern.

Each rule has two parts: a condition that decides which entitlements the rule applies to, and the request settings the rule provides when its condition matches. Rules are evaluated in priority order, and the first rule whose condition matches an entitlement provides that entitlement’s effective request settings. Because only the first match wins, order your rules from most specific to most general: put narrow, high-priority rules at the top and broader fallback rules below them. A rule with an empty condition acts as a catch-all—it matches every entitlement that no higher-priority rule has already claimed, which is a convenient way to set a default policy for an entire app.

Routing rules work for both classic apps (where each entitlement is a single permission, group, or role) and sparse apps (where access is modeled as a role granted on a scope). For sparse apps, a rule’s condition can match on the granted role and the scope it applies to—see How the CEL condition works for sparse apps below.

A Super Admin or an application owner with the Application Admin role must configure entitlement routing rules.

Create an entitlement routing rule

1. Navigate to the Apps page and select a managed application.

2. Open the application’s entitlement configuration and add a new routing rule.

3. Define the rule’s condition using either the Basic or Advanced editor (see Author a rule condition below). Leave the condition empty to create a catch-all default rule for the app.

4. Use the preview panel to confirm which of the app’s entitlements your draft condition matches. This lets you verify a rule is neither too broad nor too narrow before it affects any live requests.

5. Choose the request settings the rule should apply when it matches: the request policy, whether emergency grants are allowed, and the maximum grant duration.

6. Click Save.

Rules take effect in priority order. To change which rule wins when more than one could match an entitlement, reorder your rules—lower-priority numbers are evaluated first.

Author a rule condition

You can author a rule’s condition in one of two modes.

Basic

Build a list of predicate rows, each made up of a field, an operator, and one or more values, combined with a single AND or OR:

• Fields: Entitlement name, Resource type ID, and Risk level ID. For sparse apps, you can also match on Role name and Scope name.
• Operators: equals, does not equal, starts with, ends with, contains, and is any of.

The Basic editor covers the most common matching needs without writing any code. C1 compiles your rows into a CEL expression behind the scenes.

Advanced

Write the condition directly as a CEL expression for full control. When you switch a Basic condition to Advanced, the editor seeds the CEL with the expression compiled from your rows so you can extend it.

Switching a condition from Basic to Advanced is one-way for that rule. Once you edit the raw CEL, the structured Basic rows are no longer kept in sync with it.

How the CEL condition works for sparse apps

A routing rule condition is a CEL expression evaluated against a single variable, entitlement, that describes the entitlement being routed. The expression returns true (the rule matches) or false (it doesn’t). For example:

entitlement.display_name == "Admin"
entitlement.app_resource_type_id == "group"
entitlement.display_name.startsWith("prod-")

For sparse apps—apps that model access as a role granted on a scope (a scope-role binding) rather than as a single flat entitlement—the entitlement also carries the granted role and the scope it applies to. These are exposed as nested objects, entitlement.role and entitlement.scope, so you can match on them directly:

// Any sparse entitlement that grants an Admin role
entitlement.role.display_name.contains("Admin")

// A specific scope resource type
entitlement.scope.app_resource_type_id == "production_database"

// An Admin role granted on a production-prefixed scope
entitlement.role.display_name.contains("Admin")
  && entitlement.scope.display_name.startsWith("prod-")

// Pin by stable IDs so the rule survives an upstream rename
entitlement.role.id == "ROLE_RESOURCE_ID" && entitlement.scope.id == "SCOPE_RESOURCE_ID"

The key detail is how role and scope behave across app types:

• For a sparse (role-scope) entitlement, entitlement.role.* and entitlement.scope.* are populated from the binding.
• For a classic entitlement, those nested objects are empty—every string field is "".

A rule therefore implicitly fences itself to one shape or the other by which fields it references. A condition like entitlement.role.display_name.contains("Admin") can only match sparse entitlements, because the role display name is always empty on a classic entitlement. To make a rule explicitly sparse-only, use the canonical guard:

// True only for sparse targets; false for classic ones
entitlement.scope.id != ""

Available fields

The most commonly used accessors are listed below. String comparisons support the standard CEL string methods—==, !=, .startsWith(...), .endsWith(...), and .contains(...)—and you can match against a set with the in operator (for example, entitlement.app_resource_type_id in ["group", "role"]). Combine multiple checks with && and ||.

Field	Description
entitlement.display_name	Display name. For sparse targets, mirrors the role’s display name.
entitlement.app_resource_type_id	Resource type the entitlement is on. For sparse targets, the role’s resource type.
entitlement.app_resource_id	Resource the entitlement is on. For sparse targets, the role’s resource.
entitlement.risk_level_value_id	Risk level value ID, if one is set.
entitlement.role.display_name	Display name of the granted role (sparse only).
entitlement.role.id	Stable ID of the granted role (sparse only).
entitlement.role.app_resource_type_id	Resource type of the role (sparse only).
entitlement.scope.display_name	Display name of the scope the role applies to (sparse only).
entitlement.scope.id	Stable ID of the scope (sparse only).
entitlement.scope.app_resource_type_id	Resource type of the scope (sparse only).

Routing rule conditions see only the entitlement and its role/scope context. They do not have access to the requestor, the request, or the app itself, since rules are already scoped to a single app. When you’re unsure whether a condition matches what you intend, use the preview panel to check it against the app’s real entitlements before saving.