Skip to main content
Skip to content

Set up lifecycle policies

Use Admin > Lifecycle > Setup to assign access based on identity attributes and lifecycle state. This is called birthright access: people receive it automatically when they meet a rule. The setup creates draft policies and previews their effects before you activate them.

Use the identity, target resource, and reversible Grant you checked in Connect your first provisionable target. This time, let a policy establish that Grant and keep it in place for your first review. If your directory is not populated and checked yet, complete Populate users from an authoritative source first.

Know which automation you are configuring​

Lifecycle automation uses:

  • Derived lifecycle state interprets current identity attributes as a normalized state such as HIRED, TERMINATED, or UNKNOWN. Ordered rules use the first match; a fallback handles identities that match none.
  • Access policies continuously decide what access an identity should have now. When attributes or lifecycle state change, Owlie evaluates active grant and deny policies again and sends required changes to provisioning.
  • Reactions run one-time actions after a qualifying transition. They are not a substitute for a continuing access rule.

The setup below configures derived state and access policies.

Diagram placeholder: Lifecycle decisions and actions. Show source attributes flowing to derived lifecycle state, then continuous policy evaluation and provisioning. Show reactions as a separate transition-triggered branch, not part of desired-access calculation.

Start with a narrow birthright​

Use one resource and a test department or a few selected identities. Check the grant preview before activation: the destructive-change safety breaker protects against excessive revokes, not grants to too many people.

You need access to read policies, identities, lifecycle rules, and resources. Preparing drafts requires permission to modify policies; activation requires permission to activate policies. Adding suggested lifecycle rules also requires permission to modify derived-state rules.

  1. Open Admin > Lifecycle > Setup.
  2. In Source check, inspect the lifecycle, department, employment-status, and employee-type distributions. If there are no identities, import them first. If most source statuses do not match or most identities are UNKNOWN, correct the source mapping or lifecycle rules before continuing.
  3. In Lifecycle states, review the ordered rules. Seeded rules match exact ACTIVE and TERMINATED employment-status values. If your source uses different labels, add rules above the seeded rules and confirm their order.
  4. In Birthright, choose Employee birthright or Contractor birthright. Build a predicate from lifecycle state, employment status, employee type, or other available conditions that selects your pilot population. Select the target resource and the particular Grant you tested, rather than widening to the account as a whole.
  5. In Leaver, confirm that Terminated access deny is active. This system deny starts removing access when effective lifecycle state becomes TERMINATED.
  6. Continue to Preview & activate and choose Prepare drafts and previews. Preparation creates policy groups, draft policies, and bounded activation previews. It does not activate access changes.

Employee and contractor birthright templates exclude identities whose lifecycle state is TERMINATED. Keep the termination deny active too: it enforces removal across managed access.

Check the preview before activation​

Each prepared wave activates one policy version and includes a preview of its effects. Check each preview:

  • the identity count matches the small population you intended;
  • the selected account or Grants are correct;
  • example identities include expected members and exclude terminated or unrelated people;
  • grant and revoke counts are explainable from current access;
  • no warning indicates that a destructive revoke has paused at the safety breaker.

If the grant population is larger than expected, cancel the preview, narrow the predicate or selected access, and prepare again.

When the preview is correct, acknowledge the number of grants and choose Confirm waves sequentially. Each confirmation activates a policy version and can start provisioning work. Check the policy group and test identities, then follow the operations through to completion.

Keep leaver behavior immediate​

The leaver setup enforces the termination deny immediately, with no delayed handover window. Removal can take longer in target systems; check their fulfillment outcomes.

Do not disable the Terminated access deny as a shortcut around a test result. That removes the offboarding prohibition for the tenant. Instead, correct the identity's derived lifecycle state or test with a non-production identity and resource.

Check the same intended, completed, and observed access checkpoints used for your first target. Keep the policy-backed test Grant in place and continue to Run your first access review.