diff --git a/product/admin/policies.mdx b/product/admin/policies.mdx index cb5c58e6..947b4620 100644 --- a/product/admin/policies.mdx +++ b/product/admin/policies.mdx @@ -66,6 +66,24 @@ Policies can also fire webhooks, wait until conditions are true, and more. This 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. + + +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. + + +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 @@ -132,7 +150,7 @@ In the **If this condition matches:** box, choose how to form your policy rule: - Use the **Expression** field to to compose a [CEL expression](/product/admin/expressions) that describes the membership rule. -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. @@ -142,7 +160,7 @@ Repeat the **Add rule** process, adding as many conditional rules as needed. If Remember, for best results place more specific rules before less specific rules. -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. Click **Save**. diff --git a/product/glossary.mdx b/product/glossary.mdx index dd534b64..ef4bbbb3 100644 --- a/product/glossary.mdx +++ b/product/glossary.mdx @@ -125,7 +125,10 @@ A server an AI agent connects to over the Model Context Protocol (MCP) to call t 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). diff --git a/product/release-notes.mdx b/product/release-notes.mdx index df290366..f8d1be7d 100644 --- a/product/release-notes.mdx +++ b/product/release-notes.mdx @@ -16,15 +16,21 @@ sidebarTitle: Release notes Revoking one path to an entitlement — such as a direct grant — can leave the user with equivalent access through another, such as a group or role they also belong to. In these cases, the next sync often resurrects the grant, because group membership was never removed at the connector. The revocation task was complete, but the access never actually went away. -Smart revocation traces where an entitlement's access really comes from and revokes upstream sources too, not just the entitlement itself. Turn on **Revoke inherited access** and a revoke on that app follows the chain — direct grants, nested groups, role hierarchies, delegated provisioning — instead of stopping at the first result. It's off by default and set per app; a banner shows the downstream effects before an approver commits, so nothing gets revoked as a surprise. [Learn more.](/product/admin/access-requests#automatically-revoke-inherited-access) +Smart revocation traces where an entitlement's access really comes from and revokes upstream sources too, not just the entitlement itself. Turn on **Revoke inherited access** and a revoke on that app follows the chain — direct grants, nested groups, role hierarchies, delegated provisioning — instead of stopping at the first result. It's off by default and set per app; a banner shows the downstream effects before an approver commits, so nothing gets revoked as a surprise. [Set up automatic revocation of inherited access.](/product/admin/access-requests#automatically-revoke-inherited-access) -{/* REMOVED (2026-08-24): "Policy improvements" section — both items were SKU_MANUAL / not broadly available. - - "Create local policies for special use cases" (PR #22917): gated behind LOCAL_POLICIES, SKU_MANUAL on origin/main. - - "Reuse a policy instead of copying it" (PR #22677): gated behind POLICY_REFERENCES_POLICY. Initially marked "Confirmed GA" in error; developer confirmed on 2026-08-24 it's enabled for one customer only, not broadly available. The writeup and its policies.mdx/glossary.mdx docs (PR #455, reverted from main) are held on branch hold/policy-references-ga (PR #506) pending real GA. */} +### Reuse a policy instead of copying it + +{/* Held pending broader GA — see PR #506. Enabled for one customer only as of 2026-08-24; POLICY_REFERENCES_POLICY is SKU_MANUAL. Do not merge into main until the developer confirms wider rollout. */} + +A policy rule's outcome, or a policy's baseline, can now 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, so you're not hunting down and updating copies scattered across your policy library. + +To point a rule or the baseline at another policy, select **Use a policy** as the action, then choose the policy. 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. [Use a policy within a rule.](/product/admin/policies#use-a-policy-within-a-rule) + +{/* PR #22677 */} ### Access review and request improvements -- **Add context for campaign reviewers**: Reviewer-visible app user attributes (job title, department, cost center) previously only showed up in a hover tooltip, so reviewers had to mouse over every row to get them. Campaign admins can now configure any of these as their own column in the access review table — up to 10 per campaign. This option only appears once the campaign's **Default access review view** is set to something other than **None**. [Learn more.](/product/admin/campaigns#step-2-configure-how-the-campaign-will-run) +- **Add context for campaign reviewers**: Reviewer-visible app user attributes (job title, department, cost center) previously only showed up in a hover tooltip, so reviewers had to mouse over every row to get them. Campaign admins can now configure any of these as their own column in the access review table — up to 10 per campaign. This option only appears once the campaign's **Default access review view** is set to something other than **None**. [Configure review columns for a campaign.](/product/admin/campaigns#step-2-configure-how-the-campaign-will-run) - **Any reviewer can inspect what they're reviewing**: Previously, only users with appropriate permissions could click into the entitlement or resource under review from the review task; now any assigned reviewer can open a read-only details drawer without leaving the page. @@ -32,7 +38,7 @@ Smart revocation traces where an entitlement's access really comes from and revo ### Automation improvements -- **Scope automated revokes to the grants you actually mean**: An automation's revoke step always removed both a user's direct grants and anything they had through group membership, so automating cleanup of direct access meant accepting collateral revocation of group-inherited access too. Revoke steps now have a **Grant source** setting (**All** or **Direct**) to scope a revoke to only direct grants. [Learn more.](/product/admin/automations-steps-reference#revoke-entitlements) +- **Scope automated revokes to the grants you actually mean**: An automation's revoke step always removed both a user's direct grants and anything they had through group membership, so automating cleanup of direct access meant accepting collateral revocation of group-inherited access too. Revoke steps now have a **Grant source** setting (**All** or **Direct**) to scope a revoke to only direct grants. [Set the grant source on a revoke step.](/product/admin/automations-steps-reference#revoke-entitlements) - **Circuit-breaker logs now play nice with your SIEM**: Automation circuit-breaker system-log events include the standard OCSF time field, so you no longer need a workaround to parse them into your SIEM.