From 7680ef4aa87b99b5a14c68ae488b0c5f251c38c9 Mon Sep 17 00:00:00 2001 From: Melinda Moreland Date: Wed, 29 Jul 2026 15:49:20 -0700 Subject: [PATCH] Add access requests overview page and update nav New concept/routing page for the Access requests section. Serves two purposes: routes new admins to the right "Get started" guide for their setup, and explains the full two-axis model (visibility vs. request settings) and precedence hierarchy for admins who need to configure beyond the basics. Also adds the page as the first entry in the Access requests nav group. Co-Authored-By: Claude Sonnet 4.6 --- docs.json | 1 + product/admin/access-requests-overview.mdx | 81 ++++++++++++++++++++++ 2 files changed, 82 insertions(+) create mode 100644 product/admin/access-requests-overview.mdx diff --git a/docs.json b/docs.json index 931424e4..e7821bf1 100644 --- a/docs.json +++ b/docs.json @@ -213,6 +213,7 @@ { "group": "Access requests", "pages": [ + "product/admin/access-requests-overview", { "group": "Get started with access requests", "pages": [ diff --git a/product/admin/access-requests-overview.mdx b/product/admin/access-requests-overview.mdx new file mode 100644 index 00000000..ddc98bdd --- /dev/null +++ b/product/admin/access-requests-overview.mdx @@ -0,0 +1,81 @@ +--- +title: How access requests work +og:title: How access requests work - C1 docs +og:description: Understand ConductorOne's access request system and find the right starting point for your setup. +description: Understand ConductorOne's access request system and find the right starting point for your setup. +sidebarTitle: Overview +--- +{/* Editor Refresh: 2026-07-29 */} + +Access requests let your colleagues request the apps, roles, and permissions they need — and let you control exactly who can see what, and what happens when they submit a request. This page explains how the system works and points you to the right place to get started. + +## New here? Start with a guide + +If you're setting up access requests for the first time, pick the guide that matches your situation: + + + + Make entitlements requestable in about 5 minutes. A good first look at how access requests work in C1. + + + Set up requests for apps managed through Okta, OneLogin, or Microsoft Entra. + + + Configure just-in-time access to AWS resources via Identity Center. + + + Configure just-in-time access to Google Cloud Platform projects and roles. + + + Automatically grant or make available the right access when someone goes on-call. + + + +## How the system works + +Configuring access requests involves two independent concerns: **who can request** an entitlement, and **how that request is handled** once submitted. C1 gives you separate tools for each. + +### Who can request (catalog visibility) + +An entitlement only appears in the access catalog for users who are part of its audience. C1 gives you three tools to control this: + +| Tool | What it does | +| :--- | :--- | +| **Standard audience** | Sets the default audience for all entitlements in an app — everyone, no one, or users who already have specific access. Set on the app's **Access requests** card. | +| **Default access profile rule** | Assigns all entitlements of selected resource types to one or more [access profiles](/product/admin/profiles), making them visible and requestable to the users in those profiles. | +| **Per-entitlement Access controls** | Overrides visibility for a specific entitlement — assign it to different profiles or opt it out of the standard audience. | + +### How requests are handled (request settings) + +Request settings control what happens after a request is submitted: which approval policy routes it, how long the access lasts, and whether emergency access or a request form applies. + +| Tool | What it does | +| :--- | :--- | +| **App-level defaults** | Sets the fallback request and revoke policies for all entitlements in the app. Set on the app's **Access requests** card. | +| **Entitlement configuration rules** | CEL-based rules that match entitlements by their attributes and apply specific request settings. Up to five rules per app, evaluated in priority order — the first match wins. | +| **Per-entitlement Access controls** | Overrides request settings for a specific entitlement. Enable **Lock configuration** to prevent configuration rules from applying to it. | + +## How settings are resolved + +When someone requests an entitlement, C1 uses this order of precedence to determine the effective request settings: + +1. **Locked entitlement** — if Lock configuration is enabled on the entitlement, its own settings are used and no configuration rules apply. +2. **Entitlement configuration rules** — the first rule whose condition matches the entitlement provides the request settings. Any fields the rule leaves empty fall back to the entitlement's own settings. +3. **Entitlement settings** — the settings in the entitlement's Access controls (when not locked, these fill in any gaps left by a matching rule, or apply in full if no rule matches). +4. **App-level defaults** — the request policy set on the app's **Access requests** card. +5. **Built-in fallback** — app owner approval. + + +When you set an app-level request policy on the **Access requests** card, C1 automatically creates a corresponding entitlement configuration rule called "Access request defaults." You can view and edit it from the app's **Entitlement management** card. + + +## Which tool should I use? + +| Situation | Recommended approach | +| :--- | :--- | +| Most entitlements in an app should follow the same approval policy | Set app-level defaults on the **Access requests** card | +| All entitlements of a given resource type should be requestable by the same group | Use the **Default access profile rule** | +| Different entitlement types need different policies (for example, admin roles vs. standard groups) | Create **entitlement configuration rules** | +| One specific entitlement needs its own settings | Use **per-entitlement Access controls** | +| A specific entitlement must never be affected by app-level rules | Enable **Lock configuration** on that entitlement | +| Users need expedited access in urgent situations | Enable **Emergency access** — via a configuration rule or per-entitlement Access controls. See [Emergency access](/product/admin/emergency). |