Skip to content

docs: document entitlement lifecycle for role-scope bindings - #533

Draft
mindymo wants to merge 2 commits into
mainfrom
docs/entitlement-lifecycle-sparse-acl
Draft

mindymo wants to merge 2 commits into
mainfrom
docs/entitlement-lifecycle-sparse-acl

Conversation

@mindymo

@mindymo mindymo commented Sep 11, 2026

Copy link
Copy Markdown
Collaborator

Summary

Adds a new section to product/admin/cloud-infrastructure-access.mdx explaining that role-scope binding ("sparse ACL") entitlements only exist while they have an active grant, and what that means in practice for max durations and ID stability.

Context

From this thread: a Garmin ticket surfaced that a newly-created Azure entitlement had no max duration set, because it's a sparse-ACL/role-scope-binding entitlement that gets deleted and recreated based on grant existence. Nestor asked where this is documented — it wasn't, so this PR adds it.

⚠️ Please verify before merging

This is a best-guess draft based on reading ductone/c1 source, not confirmed with the platform team:

  • Entitlement lifecycle mechanic: based on pkg/mapper/entitlement/v2/uplift.go (an entitlement is marked deleted when the connector no longer reports a matching connector entitlement) plus this thread's confirmation that sparse-ACL connectors like Azure only report role-scope pairs with an active grant.
  • ID stability claim: based on pkg/controller/app/controller/entitlement.go's findOldEntitlement/createOrResurrectEntitlement, gated by FEATURE_FLAG_ID_RESURRECT_APP_ENTITLEMENTS (depends on RESURRECT_APP_RESOURCESRESURRECT_APP_RESOURCE_TYPES). In pkg/builtin_tenant/features_2025.go, RESURRECT_APP_ENTITLEMENTS is FEATURE_FLAG_STATUS_SKU_MANUAL with NewTenantDefault: true — i.e., on by default for new tenants, but must be manually enabled for tenants that predate that default. @GowthamiDommety, can you confirm this reading is correct, and whether it's safe to tell customers to "ask C1 Support" to check/enable it?
  • Also worth confirming: is resurrection matching reliable enough in practice (e.g., does the connector's re-sync reliably reproduce the same binding key) that we should recommend Entitlement Configuration Rules as the only safe way to set a max duration on these, or are there cases where setting it directly is fine?

@OneWhoNests — this is meant to answer the "where's this documented" question from the thread; let me know if it's missing the context you actually needed.

🤖 Generated with Claude Code

Explains that a role-scope binding (sparse ACL) entitlement only
exists while it has an active grant, and the practical implications:
use entitlement configuration rules instead of a per-entitlement max
duration, and don't assume entitlement ID stability across a
delete/recreate cycle unless entitlement resurrection is confirmed
enabled for the tenant.

Draft based on reading ductone/c1 (pkg/controller/app/controller/entitlement.go,
pkg/builtin_tenant/features_2025.go) — needs review from the platform
team before merging.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@mintlify

mintlify Bot commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated
conductorone 🟢 Ready View Preview Sep 11, 2026, 11:46 PM

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant