diff --git a/product/admin/cloud-infrastructure-access.mdx b/product/admin/cloud-infrastructure-access.mdx index 7f5de12f..27150389 100644 --- a/product/admin/cloud-infrastructure-access.mdx +++ b/product/admin/cloud-infrastructure-access.mdx @@ -50,4 +50,18 @@ The following governance capabilities all work on the hierarchical model: **Provisioning** — C1 grants and revokes access at the specific scope it was requested or assigned, not at a flat entitlement level. +## Entitlements come and go with grants + +A role-scope binding only exists as an entitlement while it has at least one active grant. Cloud infrastructure connectors like Azure only report role-scope combinations that currently have someone assigned, so C1 doesn't sync a role-scope pair that no one holds. When the last grant on a binding is removed, the entitlement disappears; when someone is granted that same role at that same scope again, C1 creates it again. + +This has two practical implications: + +1. **Don't set a maximum grant duration directly on one of these entitlements.** If it gets deleted and recreated while no one holds it, a duration set on the old row doesn't carry over. Use [entitlement configuration rules](/product/admin/entitlement-config-rules) instead: a rule that matches on role and scope applies its maximum duration to every matching entitlement, including ones created after you save the rule. + +2. **Be cautious referencing one of these entitlements by ID** — for example, from an access profile or from Terraform. + + + Whether a recreated entitlement gets its original ID back depends on a tenant setting called entitlement resurrection, which is on by default for new C1 tenants. If your tenant predates that default, or you're not sure, ask C1 Support to confirm it's enabled. + +