diff --git a/docs.json b/docs.json
index ae7426d1..1b45ce15 100644
--- a/docs.json
+++ b/docs.json
@@ -157,6 +157,7 @@
},
"product/admin/access-requests",
"product/admin/customize-requests",
+ "product/admin/entitlement-routing-rules",
"product/admin/emergency"
]
},
diff --git a/product/admin/entitlement-routing-rules.mdx b/product/admin/entitlement-routing-rules.mdx
new file mode 100644
index 00000000..29f47b53
--- /dev/null
+++ b/product/admin/entitlement-routing-rules.mdx
@@ -0,0 +1,126 @@
+---
+title: Apply request settings automatically with entitlement routing rules
+og:title: Apply request settings automatically with entitlement routing rules - C1 docs
+og:description: 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.
+description: 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.
+sidebarTitle: Entitlement routing rules
+---
+{/* Editor Refresh: 2026-06-04 */}
+
+## What are entitlement routing rules?
+
+Entitlement routing rules are app-scoped rules that automatically determine which **request settings**—the [request policy](/product/admin/policies), 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](#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
+
+
+
+Navigate to the **Apps** page and select a managed application.
+
+
+Open the application's entitlement configuration and add a new routing rule.
+
+
+Define the rule's **condition** using either the Basic or Advanced editor (see [Author a rule condition](#author-a-rule-condition) below). Leave the condition empty to create a catch-all default rule for the app.
+
+
+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.
+
+
+Choose the **request settings** the rule should apply when it matches: the request policy, whether emergency grants are allowed, and the maximum grant duration.
+
+
+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](/product/admin/expressions) 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:
+
+```cel
+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:
+
+```cel
+// 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:
+
+```cel
+// 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.
+
diff --git a/product/admin/expressions-reference.mdx b/product/admin/expressions-reference.mdx
index a1a7ccde..335ab624 100644
--- a/product/admin/expressions-reference.mdx
+++ b/product/admin/expressions-reference.mdx
@@ -201,7 +201,7 @@ Analysis data attached to a task, including access conflict information. See [Ta
The entitlement (permission/role) being requested. See [Entitlement object](#entitlement-object) for all fields.
-**Available as:** `entitlement` (in policy expressions)
+**Available as:** `entitlement` (in policy expressions and [entitlement routing rules](/product/admin/entitlement-routing-rules); in routing rules for sparse apps, `entitlement.role` and `entitlement.scope` are also populated)
#### IP
diff --git a/product/admin/expressions.mdx b/product/admin/expressions.mdx
index 8632c19c..5dda55fa 100644
--- a/product/admin/expressions.mdx
+++ b/product/admin/expressions.mdx
@@ -48,6 +48,7 @@ C1 uses CEL expressions in many contexts. Each context provides different variab
| **Push config filters** | true/false | Target users for push rule provisioning |
| **Account provisioning** | text | Compute dynamic account attributes during grants |
| **User attribute mapping** | text or list of text | Derive user attributes from existing data |
+| **Entitlement routing rules** | true/false | Match entitlements (including a sparse app's role and scope) to resolve request policies and access request settings—see [entitlement routing rules](/product/admin/entitlement-routing-rules) |
Each context provides different variables. For example, `subject` is available in most contexts, but `ctx.trigger` is only available in automations. See the [expressions reference](/product/admin/expressions-reference) for details.
diff --git a/rap/cel-expressions/env-app-entitlement-routing.md b/rap/cel-expressions/env-app-entitlement-routing.md
new file mode 100644
index 00000000..33ed07e1
--- /dev/null
+++ b/rap/cel-expressions/env-app-entitlement-routing.md
@@ -0,0 +1,99 @@
+# Entitlement Routing Rule Expressions
+
+Entitlement routing rules are app-scoped rules that resolve the **request settings** (request policy, emergency grant behavior, maximum grant duration) for an entitlement. Each rule's condition evaluates to `bool`. Rules are evaluated by priority (then id), and the first rule whose condition returns `true` provides the effective settings. An empty condition is a catch-all that matches every entitlement no higher-priority rule has claimed.
+
+The condition can be authored in **Basic** mode (field/operator/value rows joined by a single AND/OR, compiled to CEL) or **Advanced** mode (raw CEL).
+
+## Available Variables
+
+Every evaluation receives a single top-level variable: **`entitlement`**.
+
+| Variable | Type | Description |
+|----------|------|-------------|
+| `entitlement` | `AppEntitlement` | The entitlement being routed. For sparse (role-scope) targets, `entitlement.role` and `entitlement.scope` are populated. |
+
+There is **no** `subject`, `task`, `user`, or `app` variable here—routing rules see only the entitlement and its binding context, and are already scoped per-app.
+
+### `entitlement` fields
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `entitlement.id` | string | Entitlement identifier. Empty for sparse targets unless persisted. |
+| `entitlement.app_id` | string | App that owns the entitlement. |
+| `entitlement.app_resource_type_id` | string | Resource type the entitlement is on (for sparse: the role's resource type). |
+| `entitlement.app_resource_id` | string | Resource the entitlement is on (for sparse: the role's resource). |
+| `entitlement.display_name` | string | Display name. For sparse targets, mirrors the role's display name. |
+| `entitlement.description` | string | Description. For sparse targets, mirrors the role's description. |
+| `entitlement.risk_level_value_id` | string | Risk-level value id, if set. |
+
+camelCase aliases also work (`appId`, `appResourceTypeId`, `appResourceId`, `displayName`).
+
+### `entitlement.role` and `entitlement.scope` (sparse targets only)
+
+For **classic** targets these nested resources are empty—every string field is `""`. For **sparse** (role-scope binding) targets they are filled from the binding.
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `entitlement.role.id` | string | Role resource identifier. |
+| `entitlement.role.app_resource_type_id` | string | Resource type of the role. |
+| `entitlement.role.display_name` | string | Role display name. |
+| `entitlement.scope.id` | string | Scope resource identifier. |
+| `entitlement.scope.app_resource_type_id` | string | Resource type of the scope. |
+| `entitlement.scope.display_name` | string | Scope display name. |
+
+## Common Patterns
+
+### Classic targets
+
+```cel
+// Match every entitlement on a specific resource type
+entitlement.app_resource_type_id == "group"
+
+// Match by display-name pattern
+entitlement.display_name.startsWith("prod-")
+
+// Match a specific entitlement
+entitlement.display_name == "Admin"
+```
+
+### Sparse (role-scope binding) targets
+
+These rules only fire for sparse targets—the empty-string sentinel on classic targets makes the comparison fail.
+
+```cel
+// Any sparse target that grants an admin role
+entitlement.role.display_name.contains("Admin")
+
+// Sparse target on a specific scope resource type
+entitlement.scope.app_resource_type_id == "production_database"
+
+// Admin-role grant on a production-prefixed scope
+entitlement.role.display_name.contains("Admin")
+ && entitlement.scope.display_name.startsWith("prod-")
+
+// Pin by stable IDs (survives an upstream rename)
+entitlement.role.id == "ROLE_ID" && entitlement.scope.id == "SCOPE_ID"
+```
+
+### Sparse-only / classic-only gating
+
+```cel
+// Sparse-only: scope.id is "" for classic targets
+entitlement.scope.id != ""
+
+// Classic-only: role.id is "" for classic targets
+entitlement.role.id == ""
+```
+
+## What Can Go Wrong
+
+| Scenario | What Happens | How to Handle |
+|----------|--------------|---------------|
+| `entitlement.role.*` referenced on a classic app | Comparison returns `false` (fields are `""`) | Expected—this is what fences a rule to sparse targets |
+| Two rules can match the same entitlement | First by (priority, id) wins | Order specific rules above general ones |
+| No rule matches | Entitlement falls through to the app default | Add a catch-all rule with an empty condition |
+| Typo in a field name | Compile-time error | Expression won't save |
+
+## Best Practice
+
+Keep each condition simple and use ordering rather than complex boolean logic. Use the rule editor's preview panel to confirm which entitlements a draft condition matches before saving.
diff --git a/rap/cel-expressions/index.md b/rap/cel-expressions/index.md
index fbea506e..b60e5699 100644
--- a/rap/cel-expressions/index.md
+++ b/rap/cel-expressions/index.md
@@ -28,6 +28,7 @@ These files document where CEL expressions are used and what variables/functions
| `env-workflow.md` | Workflow templates, step data flow, ctx object, interpolation |
| `env-account-provisioning.md` | Account attribute mapping, provisioning expressions |
| `env-user-attribute.md` | Derived user attributes, computed attribute values |
+| `env-app-entitlement-routing.md` | Entitlement routing rules, applying request policies/settings by condition, matching a sparse app's role and scope |
### Functions