Skip to main content
Access Policies in Lumos move through a defined lifecycle from the moment they’re created to the moment they affect real users. Understanding the lifecycle enables you to decide when to publish, when to leave something inactive, and how to safely iterate on policies without surprise impact.

​
The three states

Every access policy is in one of three states at any given time: Draft. The policy exists but is not enforced. It does not apply to any user, onboarding workflow, or mover workflow. Drafts are fully editable, can be deleted at any time, and don’t have to be unique. This is the safe space to design, review, and iterate. Published + Inactive. The policy has been published, but it’s turned off. It won’t apply to future onboardings or mover workflows. Use this state when you want a policy formally reviewed and ready to go, but not yet running. Published + Active. The policy is live. It applies to future onboarding and mover workflows that match its conditions.
image.png

​
How policies move between states

The full lifecycle is Draft → Publish → Active/Inactive.
  1. A new policy starts as a Draft. Whether you create it manually, through Albus, or through the API, it lands in the Drafts tab of the Access Policies table.
  2. You publish the draft when it’s ready. Click Publish from the policy detail page or directly from the Drafts tab. On publish, the policy moves to the Published tab.
  3. You toggle Active or Inactive. Newly published policies default to Inactive. Set them to Active when you’re ready for them to start applying to workflows.
Editing a published policy creates a new draft. The published version stays in effect until you publish the draft. See Editing Published Access Policies.

​
What being active actually means

“Active” means the policy is evaluated as part of onboarding and mover workflows. A policy is only enforced when it is Published + Active. In every other state (Draft, or Published + Inactive), the policy has zero effect on users. This is the key safety property of the lifecycle: nothing you do in the Drafts tab can accidentally grant or revoke access.

​
Overlapping conditions

Uniqueness of conditions is only validated at publish time. That means:
  • Two drafts can have overlapping conditions with each other.
  • A draft can have overlapping conditions with a published policy.
  • A draft cannot be published if its conditions overlap with an existing published policy. You’ll need to resolve the overlap first.
This lets you safely sketch alternative versions of a policy as drafts without conflicting with what’s currently live.

​
Albus and the API

The lifecycle applies regardless of how a policy is created:
  • Albus-generated policies always land as drafts. Admins explicitly publish and activate them.
  • The API creates drafts by default. If you want to skip the draft state and create a published policy programmatically, set the status parameter on the request.

​
When to use each state

Draft is for any work in progress: a policy you’re still designing, a policy waiting on review from security or an app owner, or a policy you want to stage as part of a phased rollout. Published + Inactive is for policies that are reviewed and ready but not yet running, for example, a policy you want to flip on at the start of a new quarter, or a policy you’ve temporarily paused. Published + Active is the live state. The policy is part of your enforcement model and applies to future workflows that match.