> ## Documentation Index > Fetch the complete documentation index at: https://docs.aptlydone.com/llms.txt > Use this file to discover all available pages before exploring further. # Delegation Lifecycle > Understand the full lifecycle of a delegation in Aptly — from Decision creation through issuance, approval, acceptance, redelegation, ongoing changes, and end states. ## Overview In Aptly, **Decisions** define *what* authority exists. To make that authority operational, it must be **delegated** — beginning with a **Root Delegation**, then optionally cascading to others through **Redelegations** based on roles, limits, and organizational policies. This page covers the full lifecycle: **1. Create a Decision → 2. Issue a Root Delegation → 3. Cascade authority through Redelegations → 4. Govern ongoing changes and end states** Along the way, two optional tenant-configurable workflows — **Approval** and **Acceptance** — gate when a delegation becomes operational. Every event is captured in the Change Log and Version History for full auditability. *** ## 🎯 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 (e.g., Approval, Signatory) * Authority value types and limits (Currency, Number, Percentage, Time, Authorized) * Conditions and Roles (optional) * Allowed Delegation Pathways (Matrix, Functional, Direct-Line, Down-Line) * Group assignments (Organizations, Locations, Departments, custom group types) > 🧠 A Decision alone doesn't grant authority — it must be delegated. Whether approvals are required for delegations is configured at the **tenant level** under Action Settings, not on each individual Decision. See [Delegation Approvals & Logic](/essentials/delegation-approvals) for full detail. *** ## 🌱 Step 2: Issue a Root Delegation A **Root Delegation** is the first delegation in any chain — issued directly from a Decision, with no parent delegation as its source authority. ### Characteristics * Requires the `tenant.create_root_delegations` permission * Establishes the initial authority that others can inherit or extend * May include: * Authority limits (Currency, Number, Percentage, Time, Authorized) * Effective and Expiration dates * Delegation Pathway constraints * Delegable rights (whether the recipient can redelegate) * Conditions and Role assignments * Document attachments ### Issuer options * A specific **user or position** as the Issuer, or * **Root Authority** — a toggle that indicates the delegation originates from the organization's governance authority itself rather than from a specific person or position. Used when no upstream individual issuer applies. > Root Delegations are typically issued by **System Admins** or **Global Authority Managers** and represent the top of the delegation chain. *** ## 🔁 Step 3: Cascade Authority via Redelegations Once a Root Delegation exists, recipients can issue **Redelegations** to others — provided: * The source delegation is active and **delegable** * The user holds the `delegation.issue_delegation` permission * The redelegation respects the Decision's pathway constraints and authority limits ### How Redelegations relate to their source * They **inherit constraints** from the parent (authority types, limits, pathway options, conditions) * They are **linked to their source** for full traceability and pathway visualization * They **cannot exceed** the source delegation's authority limits or the tenant's **Global Redelegation Limits** (unless the issuing user has the `tenant.limit_override_delegations` permission) ### Delegation Pathway types Pathways control to whom a recipient is allowed to redelegate. Each delegation can use one or more of the pathway options enabled on the parent Decision: | Pathway | Eligible recipients | | --------------- | ------------------------------------------------------------------------------------------------ | | **Matrix** | Any user or position in the tenant | | **Functional** | Users or positions in the same Department(s) as the issuer (requires the Departments group type) | | **Direct-Line** | Users who report directly to the issuer (immediate reports only) | | **Down-Line** | Users in the issuer's downstream reporting line (direct and indirect reports) | > When multiple pathways are selected, the **most permissive** logic applies. If **Matrix** is present alongside any other pathway, Matrix governs and redelegation is unrestricted. This supports flexible authority distribution across departments, regions, and position-based roles while preserving the boundaries set at the Decision level. *** ## ✅ Approval Workflow (if enabled) When **Delegation Approval** is enabled at the tenant level, every newly issued delegation — Root or Redelegation — enters **Pending** status and an **Approval Action** is generated for eligible approvers. The delegation does not become operational (and cannot be cascaded) until approved. When **Change Approval** is enabled, substantive edits to an already-Issued delegation also route for approval; the delegation remains Issued with a **Pending Re-approval** indicator until the change is reviewed. > See [Delegation Approvals & Logic](/essentials/delegation-approvals) for full detail on when approvals are required, how approvers are assigned, and how the Change Approval flow works. *** ## 🤝 Acceptance Workflow (if enabled) When **Delegation Acceptance** is enabled at the tenant level, recipients must **explicitly accept** an issued delegation before the recipient's authority is acknowledged on the record. Acceptance generates an Action assigned to each recipient, and the acceptance date is recorded on the delegation. If a recipient **rejects** the delegation, the rejection is recorded and the recipient's authority does not take effect. If all recipients reject the delegation, its status changes to **Rejected** and the chain terminates at that point. If Acceptance is not enabled, issued delegations are acknowledged automatically. > When **neither approval nor acceptance** is enabled, a delegation moves directly from **Draft** to **Issued / Active** in a single step upon issuance. *** ## 📊 Delegation Status Model A delegation's status reflects where it sits in the lifecycle. The status determines what actions are available and how the authority is treated. | Status | Description | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Draft** | Being configured; not yet issued. | | **Pending** | Issued but awaiting approval (when Delegation Approval is enabled). | | **Issued / Active** | Issued and operational. If Acceptance is enabled, the delegation is operational only for recipients who have accepted; if Acceptance is not enabled, the delegation is fully active on issuance. | | **Accepted** | The recipient has accepted the delegation (used when Acceptance is enabled). | | **Suspended** | Temporarily disabled. Authority is not active during suspension; the delegation can be **reissued** to restore it. | | **Revoked** | Permanently ended — manually by the issuer or an administrator, or automatically via Auto-Revoke. Revoking a parent cascades to its children. | | **Expired** | The Expiration Date has passed. Authority is no longer active. | | **Archived** | Archived for historical and audit retention. | | **Rejected** | All recipients have rejected the delegation (Acceptance workflow only). The chain terminates at this delegation. | > When neither approval nor acceptance is enabled, a delegation moves directly from **Draft** to **Issued / Active** in one step. The Pending and Accepted stages only appear when their respective workflows are enabled. *** ## ⚠️ Invalid Delegations **Invalid** is a flag, not a status. A delegation can be Issued *and* flagged Invalid at the same time. Invalid is a review indicator that something upstream has changed in a way that breaks alignment with the delegation's parameters — for example: * A Group, pathway option, or Authority Type was removed from the parent Decision or source delegation * The parent's authority limit was reduced below the child's current limit * A recipient designated as **Personnel in Position** no longer holds the required position (when Auto-Revoke is off) * A Functional pathway is in use but the recipient's department changed * A Direct-Line or Down-Line pathway is in use but the reporting line changed The delegation's **status is not automatically changed** when it becomes Invalid — administrators are alerted and can update the delegation to bring it back into alignment, clearing the flag. > See the [Invalid Delegations Knowledge Base article](https://support.aptlydone.com/portal/en/kb/articles/invalid-delegations-what-it-means-and-how-to-resolve-it) for the full set of triggers and remediation steps. *** ## 🧨 Ongoing Changes Delegations can be modified throughout their life as conditions change. Each of these actions is captured in the Change Log with full attribution. ### Update / Edit Authorized users can edit a delegation's substantive fields — authority limits, recipients, conditions, roles, dates, groups, document attachments, or pathway. Inherited fields (Section, Category, Description, Guidance) are managed on the parent Decision. When **Change Approval** is enabled at the tenant level, edits to an Issued delegation route for approval before the changes are committed to the live record. The delegation remains Issued with a **Pending Re-approval** indicator while the change is under review. See [Delegation Approvals & Logic](/essentials/delegation-approvals) for the full re-approval flow. ### Suspend and Reissue **Suspend** temporarily disables a delegation; the authority is not active during suspension. **Reissue** restores it to its prior state. ### Revoke **Revoke** permanently ends a delegation. Revoking a parent cascades to all of its child delegations. Revocation can also occur automatically through Auto-Revoke for Personnel-in-Position recipients (see below). ### Expire A delegation transitions automatically to **Expired** when its Expiration Date passes. Authority is no longer active, but the record remains in place for audit and history. ### Archive Archiving moves the delegation into a historical/audit-retention state without deleting the record. > Updating, suspending, revoking, or archiving a parent delegation can affect all of its child delegations. Aptly displays a confirmation warning when an upstream change will impact downstream records. *** ## 👤 Position Automation: Auto-Issue & Auto-Revoke For delegations issued to **Personnel in Position** recipients, two optional behaviors automate the lifecycle as people move into and out of positions: * **Auto-Issue** — Any user who currently holds, or later assumes, the designated position is automatically issued the delegation (subject to pathway constraints). * **Auto-Revoke** — Users who no longer hold the position (or no longer meet the pathway alignment, where applicable) have the delegation automatically revoked. Auto-Issue and Auto-Revoke apply only when the **Personnel in Position** recipient type is enabled at the tenant level. They do not apply to Position Only or Specific Personnel recipients. > See [System Settings → Delegation Settings](/essentials/system-settings) for tenant-level configuration of recipient types and position automation. *** ## 🔍 Managing Delegations Delegations can be viewed and managed in several places: * **Delegations module** — view all delegations across the tenant, filterable by status, group, category, role, issuer, recipient, and more * **Decision record** — view all delegations tied to a specific Decision * **User profile** — see delegations held *by* or *issued by* a particular user * **Pathway view** — visualize the delegation chain for a Decision in an org-chart-style layout Authorized admins can: * Filter and search by user, decision, group, status, category, role, or document * Export delegation data for reporting or audit * View the full **Change Log** and **Version History** for any delegation, reconstructing the state of the authority on any prior date > Available actions on a delegation depend on its **status** (e.g., Pending can be approved or denied; Issued can be edited, suspended, or revoked) and on the user's role and capacity on the record. *** ## 🧭 Related Pages * [Delegation Approvals & Logic →](/essentials/delegation-approvals) * [Actions and Workflows →](/essentials/actions-and-workflows) * [Roles & Permissions →](/essentials/roles-permissions) * [System Settings Overview →](/essentials/system-settings) * [Group Management →](/essentials/groups) * [Matrix Management →](/essentials/matrix-management) * [Document Management →](/essentials/document-management) *** Need help designing your delegation structure or configuring approval and acceptance workflows? Reach out to [support@aptlydone.com](mailto:support@aptlydone.com) or visit the Aptly Support Portal.