​
Overview

In Aptly, Decisions define what authority exists. To make that authority operational, it must be delegated — beginning with a Root Delegation, then cascading to others based on roles, limits, and organizational policies. This guide walks through that lifecycle:
1. Create a Decision → 2. Seed a Root Delegation → 3. Cascade authority

​
🎯 Step 1: Create a Decision

A Decision defines a specific authority — such as approving vendor contracts or signing NDAs. Each Decision includes:
  • A name and description
  • A category and section (e.g., “Legal → Contracts”)
  • Authority types (Approval, Signatory, etc.)
  • Conditions or constraints (optional)
  • Whether approval is required before delegation
🧠 A Decision alone doesn’t grant authority — it must be delegated.

​
🌱 Step 2: Seed a Root Delegation

A Root Delegation is the first issued delegation tied to a Decision.

​
Characteristics:

  • Requires the create_root_delegations permission
  • Establishes initial authority for others to inherit or extend
  • May include:
    • Limits (e.g., currency threshold)
    • Time boundaries
    • Delegation Pathway constraints (Matrix, Functional, Direct Line)
    • Delegable rights (yes/no)
    • Approval step (if required)
Root Delegations are often issued by System Admins or Global Authority Managers and represent the top of the delegation chain.

​
🔁 Step 3: Cascade Delegations

Once a Root Delegation exists, it can be cascaded to others — if:
  • The delegation is active
  • The user holds the create_delegations permission
  • The Decision permits downstream delegation

​
Downstream delegations:

  • Inherit constraints from the parent (value, expiration, delegable flag)
  • Are linked to their source for full traceability
  • May also trigger approval flows depending on Decision settings
✅ This supports flexible authority distribution across departments, regions, and position-based roles.

​
✅ Approval Requirements

If a Decision requires approval:
  • A Delegation Approval Action is generated when the delegation is created
  • Approvers are selected from users with approve_delegations permission
    • All scope → eligible for any delegation
    • Groups scope → eligible only when their assigned groups match the delegation’s groups (including inherited child groups)
  • Delegation remains in Pending status until approved
  • Upon approval, status changes to Issued
⚠️ Root and child delegations can both require approval — independently.

​
🧨 Revoking, Suspending, or Updating

Delegations can be modified as conditions change.

​
Actions include:

  • Suspend — Temporarily disables a delegation (can be resumed)
  • Revoke — Permanently ends the delegation (and cascades to all children)
  • Update — Adjusts limits, roles, or duration (may trigger reapproval)
Updating or revoking a parent delegation can impact all child delegations.

​
🔍 Managing Delegations

Delegations can be viewed and managed in multiple ways:
  • Delegation Register — View all active/inactive delegations
  • Decision Record — View all delegations tied to a Decision
  • User Profile — See delegations held by or issued by a user
Admins can:
  • Filter by group, status, category, or role
  • Export and audit delegation history
  • Search by user, decision, or document
Available actions depend on the delegation’s status (e.g., Pending can be approved/denied, Issued can be suspended/revoked).
Need help designing your delegation structure?
Reach out to [email protected].