docs: document policy references

product/admin/policies.mdx

@@ -66,6 +66,24 @@
 
 Each of these is created as a step in a policy rule. 
 
+### Use a policy within a rule
+
+A policy rule's outcome, or a policy's baseline, can point to another policy instead of listing out its own steps. Build a common flow once, like a security review or a manager-then-owner approval chain, and use it from every policy that needs it. Update the policy you're pointing to, and every policy that uses it picks up the change on its next request — no hunting down copies.
+
+For example, a rule could say: "If the requester is in Engineering, use the Security review policy. Otherwise, use the Standard approval policy."
+
+To point a rule or the baseline at another policy, select **Use a policy** as the action, then choose the policy.
+
+<Note>
+A policy you point to must be the same type (request, review, or revoke) as the policy pointing to it. You can chain up to five policies deep, and C1 rejects cycles or self-references when you save.
+</Note>
+
+A few things to know about how this behaves:
+
+- **The policy locks in when a task is created.** C1 resolves the full chain at that point and snapshots it onto the task, so editing a policy you point to only affects future requests, not tasks already in progress.
+- **You can see the routing.** A task's audit log shows which policy each step came from, and where a matching rule sent the request.
+- **You can't delete a policy that's in use.** If another policy points to it, C1 blocks the deletion and names the policy that's still pointing to it.
+
 ## Get agent help building policies
 
 <Warning>
@@ -117,7 +135,7 @@
 
    - Use the **Basic** condition builder to construct a rule from a combination of entitlements and [profile attributes](/product/admin/attributes) (see note below on which profile attributes are supported), with the option to add **and** and **or** statements to refine the rule.
    <Tip>
    **Supported attributes in the basic condition builder** The value input field in the basic condition builder currently only supports string values. Certain attributes are stored as enums (fixed lists of values) or arrays (multiple values), which cannot be correctly parsed when entered as a simple string in the basic builder. If you use these attributes in the basic builder, the system will treat the input as a literal string, and the policy or membership rule may not behave as expected.
 
    The following attributes are not supported in the basic condition builder:
 
@@ -129,10 +147,10 @@
 
    If you need to use any of the attributes listed above, you must compose a CEL expression in the **Expression** field.
    </Tip>
    - Use the **Expression** field to to compose a [CEL expression](/product/admin/expressions) that describes the membership rule.
 </Step>
 <Step>
-In the **Then perform this action:** section of the rule, select an automatic action (the exact actions vary by policy type) or **Execute a workflow** to wait for a condition to be met or assign the task to a reviewer workflow (see below).
+In the **Then perform this action:** section of the rule, select an automatic action (the exact actions vary by policy type), **Execute a workflow** to wait for a condition to be met or assign the task to a reviewer workflow (see below), or **Use a policy** to [point this rule at another policy](/product/admin/policies#use-a-policy-within-a-rule) instead of building steps inline.
 
    If necessary, click **Add step** to add additional actions or workflows to the rule.
 </Step>
@@ -142,7 +160,7 @@
    Remember, for best results place more specific rules before less specific rules.
 </Step>
 <Step>
-Edit the [baseline rule](/product/admin/policies#the-baseline-rule). The baseline rule can be set to take an automatic action (the exact actions vary by policy type), or to assign the task to reviewers, as described below.
+Edit the [baseline rule](/product/admin/policies#the-baseline-rule). The baseline rule can be set to take an automatic action (the exact actions vary by policy type), assign the task to reviewers as described below, or [use a policy](/product/admin/policies#use-a-policy-within-a-rule) to point it at another policy.
 </Step>
 <Step>
 Click **Save**.
@@ -244,7 +262,7 @@
 
 3. Set whether the reviewer (or the fallback reviewer, if applicable) can reassign the task, and whether reassigned tasks require a reason for their reassignment.
 
    Use the **Limit reassignment to** field to create an allowlist of users who the task can be reassigned to. If the task can be reassigned to any user, leave this field blank. 
 
 3. Set whether this step allows the task to be reassigned to an assigned delegate, either a [delegate set by an admin](/product/admin/delegate#set-a-delegate-for-another-user), such as for an executive or employee out on long-term leave, or a [delegate set by an individual user](/product/admin/delegate#set-your-own-delegate) while they are out of office.  
 
@@ -252,11 +270,11 @@
 
 4. **Request and review policies only.** Set whether this step requires a distinct approver. This means a user who approved an earlier step in the workflow cannot approve this step, ensuring a different set of eyes reviews each stage.
 
    If **Require distinct approvers** is enabled, the system automatically assigns the task to an approver who has not previously approved the request. If the policy can't find a distinct approver, it will automatically route the approval to fallback users (Campaign Admins or Super Admins).
 
 5. Set whether approvals and denials require the reviewer to enter a justification for their choice.
 
 6. **Optional.** If desired, check to enable **Trigger SLA violation after** and set the timeframe for a service-level agreement (SLA) to kick in. If no action has been taken on the task when the time elapses, select what happens next:
 
    * **Use a new policy** - Select a different policy from the list to take over the approval process.
 

product/glossary.mdx

@@ -11,7 +11,7 @@
 An access conflict occurs when two entitlements assigned to the same user violate a separation of duties (SoD) policy or other regulation. See [Conflict monitor](/product/glossary#conflict-monitor). 
 
 #### Access profile
 A group of resources and entitlements curated for their applicability to a certain audience and only visible to that audience. Access profiles limit what resources and entitlements each user can see and request, so only relevant access is visible and available. An access profile can be set up so that users can request each app or permission it contains individually (in their app catalog), or so that the entire bundle of access is requestable as a unit (also called a profile). See [App catalog](/product/glossary#app-catalog). 
 
 #### Account
 A unique record associated with a specific actor (such as a human, a system account, or a service account) within an application. An account in an application is granted permissions and roles in that app. 
@@ -32,7 +32,7 @@
 A custom risk level or compliance framework tag that you create and apply to entitlements, such as “SOC2” or “High risk”. 
 
 #### Automation
 A custom workflow built in C1 that automates repetitive tasks such as onboarding, offboarding, and role transfers. An automation consists of a trigger (the event or schedule that causes it to run) and one or more steps (the actions it performs). Automations can run automatically based on their trigger or be started manually on demand. See [Task](/product/glossary#task) and [Policy](/product/glossary#policy).
 
 #### Baton
 The open-source code framework that powers connectors. Named for an orchestra conductor’s baton, which focuses and directs the musicians, and for the baton transferred from one runner to the next (like data!) in a relay race. We like a double meaning around here. 
@@ -47,7 +47,7 @@
 C1 groups are collections of C1 users that you create and use within C1. They can be useful for organizing groups of employees as access recipients or assignees to tasks.
 
 #### Campaign (UAR)
 User access review (UAR) campaigns are a framework for periodically reviewing user access. A campaign has a scope (the access to be reviewed) and a timeframe (the start and end dates of the campaign). 
 
 #### CEL
 Common Expression Language (CEL) was developed by Google and is used in C1 to write conditional expressions that use variables and user data known to C1. 
@@ -68,10 +68,10 @@
 The open, OAuth-based protocol that [enterprise-managed authorization](/product/glossary#enterprise-managed-authorization-ema) is built on. No single vendor owns it; any provider can implement it, and C1 does. Under XAA, C1 exchanges a signed-in user's identity for a short-lived, scoped token (an [ID-JAG](/product/glossary#id-jag)) addressed to a specific MCP server, after checking the user's entitlements; the agent then calls the server directly, so C1 is not in the data path. See [Enterprise-managed authorization overview](/product/admin/enterprise-managed-authorization/overview).
 
 #### Custom form
 Additional fields added to an access request that require requestors to provide context when making a request, such as a cost center code, ticket reference, or start date. Custom forms help IT and security teams make informed approval decisions and support audit and compliance requirements. See [Request](/product/glossary#request).
 
 #### Deprovision
 The process of removing previously assigned permissions or shutting down user accounts in connected systems after a revocation proposal is confirmed. In C1, deprovisioning tasks are assigned to users when manual deprovisioning of access is required. See [Revoke / Revocation](/product/glossary#revoke-/-revocation). 
 
 #### Digest
 A personalized email sent to C1 users that includes an overview of open tasks, connector sync errors, expiring access, and more. Sometimes called “daily digest”, but can be set by your organization for daily or weekly delivery. 
@@ -98,10 +98,10 @@
 Identity risk data from external security tools — such as risk scores and security findings — that C1 syncs and surfaces alongside the identities it describes. External insights are shown during access reviews and at the moment of approval so reviewers can make more informed decisions without switching tools. 
 
 #### External ticketing system
 An integration with your organization’s IT ticketing system, such as Jira or ServiceNow. Once configured, when manual provisioning of new access is required, C1 automatically creates a ticket in the connected external ticketing system. C1 will monitor the status of the ticket and mark the provisioning step complete in C1 once the ticket is closed. 
 
 #### Function
 Serverless TypeScript functions that extend C1's capabilities with custom automation logic. Functions can call external systems, run on events, implement organization-specific workflows, and access C1 data through the C1 SDK. A function can be invoked from an automation step, the C1 web UI, or the API.
 
 #### Grant
 A record indicating that an application account has been explicitly assigned an entitlement on a resource. See [Entitlement](/product/glossary#entitlement) and [Account](/product/glossary#account).
@@ -113,7 +113,7 @@
 An existing relationship between an entitlement in an IdP and one in a standalone application. Linked entitlements commonly connect IdP resources with the apps the IdP controls access to. 
 
 #### Managed app
 An application that you’re actively managing with C1. A managed application has an active connector or other data source. See [Application](/product/glossary#application), [Connector](/product/glossary#connector), and “Unmanaged app”. 
 
 #### Mapping
 The process of matching how key data points are labeled in an integrated software or service with how they’re labeled in C1, so data can be pulled in and used correctly across sources. 
@@ -122,10 +122,13 @@
 A server an AI agent connects to over the Model Context Protocol (MCP) to call tools and reach data. Under [enterprise-managed authorization](/product/glossary#enterprise-managed-authorization-ema), C1 issues a scoped, short-lived token addressed to a specific MCP server. In the underlying [Cross-App Access](/product/glossary#cross-app-access-xaa) protocol, the MCP server is the "resource server."
 
 #### Membership
 A rule set on an access profile that automatically creates enrollment or unenrollment requests for users who meet — or no longer meet — defined criteria such as department, job title, or manager. Membership automates access changes when users join, leave, or move between teams without requiring manual requests. See [Access profile](/product/glossary#access-profile) and [Enrollment](/product/glossary#enrollment).
 
 #### Policy
-A reusable rule set that defines a process for requesting, reviewing, or revoking access. Policies can contain instructions such as who a certain task should be routed to, as well as instructions on sending notifications, triggering webhooks, conditional routing, and much more. 
+A reusable rule set that defines a process for requesting, reviewing, or revoking access. Policies can contain instructions such as who a certain task should be routed to, as well as instructions on sending notifications, triggering webhooks, conditional routing, and much more. See [Policy reference](/product/glossary#policy-reference).
+
+#### Policy reference
+A policy rule or baseline set to the **Use a policy** action, which points to another policy of the same type instead of defining its own steps. Policy references let a common flow, such as a security review or an approval chain, be reused across every policy that needs it. See [Policy](/product/glossary#policy) and [Task](/product/glossary#task).
 
 #### Profile attribute
 A piece of information about an application account that is pulled in from an application, and that can be used to scope UAR campaigns or build policies. See [Account](/product/glossary#account). 
@@ -139,10 +142,10 @@
 #### Request
 Broadly, when a user asks for a new permission, this is a request (or more formally, an access request). In C1, the user submits the request and a request task is created, which is governed by a request policy. See [Task](/product/glossary#task) and [Policy](/product/glossary#policy). 
 
 #### Requestable action
 An automation exposed to end users as a requestable object, allowing them to trigger a workflow — such as requesting temporary elevated access or initiating an offboarding task — through a standard approval process rather than requiring standing permissions. See [Automation](/product/glossary#automation) and [App catalog](/product/glossary#app-catalog).
 
 #### Requestor
 The person making a request for access. This is most commonly the user who will be granted the access, but it can be a manager or other admin making the request on the user’s behalf. 
 
 #### Resource
@@ -179,7 +182,7 @@
 Shadow apps are applications and cloud services not managed or approved by an organization’s IT department that employees sign into using their corporate email. 
 
 #### Step-up authentication
 An additional authentication challenge required of approvers before they can approve sensitive access requests. C1 implements step-up authentication using the RFC 9470 OAuth 2.0 Step Up Authentication Challenge Protocol, generating a fresh challenge for each qualifying approval so that prior authentication state is never reused. See [Policy](/product/glossary#policy) and [Request](/product/glossary#request).
 
 #### Sync
 The process of reaching out to an integrated software tool or service via a connector to read new data or to write data to the tool or service based on changes and decisions made in C1. Based on the type and configuration of the connector, syncs can happen automatically on a schedule, or can be triggered manually. See [Connector](/product/glossary#connector). 
@@ -193,7 +196,7 @@
 #### Template
 A pre-configured, reusable framework for creating recurring UAR campaigns. Templates make it faster and easier to set up identical or very similar campaign configurations when you need to run a certain campaign on a recurring schedule. 
 
 #### Unmanaged app
 The child apps that are discovered by a connector for an app that is an identity provider (IdP), SSO, or federation provider, but that you haven’t yet added a connector or other data source to so you can begin managing them in C1. See [Managed app](/product/glossary#managed-app). 
 
 #### User
@@ -212,6 +215,6 @@
 A special proxy entitlement that is created in C1 and does not get written back to the source software. Virtual entitlements are ideal for making easy-to-understand user-facing target entitlements that can be bound to more complex existing entitlements in your IdP, SSO, or federation provider. 
 
 #### Webhook
 An HTTP callback that connects C1 to external systems. Outbound webhooks fire from C1 to an external URL when certain events occur, such as when a provisioning step completes. Inbound webhooks allow external systems to trigger C1 automations by sending authenticated HTTP POST requests to a C1 listener endpoint.