> ## Documentation Index
> Fetch the complete documentation index at: https://conductorone-docs-mcp-bridge-private-server.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Apply request settings automatically with entitlement configuration rules
> Use entitlement configuration 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 cloud infrastructure apps.
## What are entitlement configuration rules?
Entitlement configuration 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.
Configuration rules work for both **classic** apps (where each entitlement is a single permission, group, or role) and **cloud infrastructure apps** (where access is modeled as a role granted on a scope). For cloud infrastructure apps, a rule's condition can match on the granted role and the scope it applies to—see [How the CEL condition works for cloud infrastructure apps](#how-the-cel-condition-works-for-cloud-infrastructure-apps) below.
## Create an entitlement configuration rule
A **Super Admin** or an application owner with the **Application Admin** role must configure entitlement configuration rules.
Navigate to the **Apps** page and select a managed application.
On the app's **Overview** tab, scroll to the **Entitlement management** section, find **Entitlement configuration rules**, and click **Edit**.
Define the rule's **condition** as a [CEL expression](#author-a-rule-condition). 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. A rule must be turned **On** to be evaluated; rules that are Off are skipped.
## Author a rule condition
Write the rule's condition as a [CEL expression](/product/admin/expressions). The expression evaluates to `true` (the rule matches an entitlement) or `false` (it doesn't). See [How the CEL condition works for cloud infrastructure apps](#how-the-cel-condition-works-for-cloud-infrastructure-apps) below for the variables and fields available to your expression.
## How the CEL condition works for cloud infrastructure apps
A configuration 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:
```go theme={"theme":{"light":"css-variables","dark":"css-variables"}}
entitlement.display_name == "Admin"
entitlement.app_resource_type_id == "group"
entitlement.display_name.startsWith("prod-")
```
For **cloud infrastructure apps**—apps that model access as a role granted on a scope 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:
```go theme={"theme":{"light":"css-variables","dark":"css-variables"}}
// Any cloud infrastructure 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 **cloud infrastructure app** 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 cloud infrastructure app entitlements, because the role display name is always empty on a classic entitlement. To explicitly target only cloud infrastructure app entitlements, use this guard:
```go theme={"theme":{"light":"css-variables","dark":"css-variables"}}
// True only for cloud infrastructure apps; false for classic apps
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 cloud infrastructure apps, mirrors the role's display name. |
| `entitlement.app_resource_type_id` | Resource type the entitlement is on. For cloud infrastructure apps, the role's resource type. |
| `entitlement.app_resource_id` | Resource the entitlement is on. For cloud infrastructure apps, 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 *(cloud infrastructure apps only)*. |
| `entitlement.role.id` | Stable ID of the granted role *(cloud infrastructure apps only)*. |
| `entitlement.role.app_resource_type_id` | Resource type of the role *(cloud infrastructure apps only)*. |
| `entitlement.scope.display_name` | Display name of the scope the role applies to *(cloud infrastructure apps only)*. |
| `entitlement.scope.id` | Stable ID of the scope *(cloud infrastructure apps only)*. |
| `entitlement.scope.app_resource_type_id` | Resource type of the scope *(cloud infrastructure apps only)*. |
Configuration 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.