> ## 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 Approvals & Logic > Learn how Aptly governs delegation approvals — at original issuance, on changes to issued delegations, and across the full audit trail. ## Overview In Aptly, delegations may require **approval** before they become active — and, optionally, again whenever a substantive change is made to an issued delegation. This ensures every grant of authority and every modification to an existing one is reviewed by the right people, and that the full history is captured for audit. Whether and when an approval is triggered depends on: * The tenant's **Delegation Approval** configuration — whether approval is required for newly issued delegations * The **Change Approval** configuration — whether approval is also required on changes to issued delegations * The **delegation context** — who is delegating, to whom, with what limits, and within which Groups * Each user's **role permissions and group scope** — who is eligible to approve Both Delegation Approval and Change Approval are tenant-level toggles configured under **Settings → Account Settings → Delegations → Action Settings**. They can be enabled independently of each other. This page explains when approvals are needed, how approvers are determined, and how every approval and change is recorded. *** ## ✅ When Is Approval Required? Aptly evaluates approval requirements at two moments in a delegation's life: ### At original issuance When **Delegation Approval** is enabled for the tenant, every newly issued delegation — whether a Root Delegation or a redelegation — enters **Pending** status and an **Approval Action** is generated for eligible approvers. The delegation does not become Issued (and cannot be cascaded) until approved. ### On changes to an issued delegation When **Change Approval** is enabled, edits that affect the substantive content of an already-Issued delegation also generate an Approval Action. The delegation **remains Issued** while the change is reviewed, but is flagged with a **Pending Re-approval** indicator until the approver completes the review. If approvals are not enabled, delegations and their edits take effect immediately on save (subject to other validations and notifications). > Both **initial issuance approval** and **change approval** can be enabled independently, allowing organizations to tailor oversight to their governance model — approval at issuance only, on changes only, or both. *** ## 🔁 Change Approval (Approval on Changes) When Change Approval is enabled, the following types of edits to an **Issued** delegation will route the change for approval: * **Authority** — primary, secondary, or tertiary limits, and authority types * **Recipients** — addition, removal, or change of recipient(s) * **Conditions** — additions, removals, or modifications * **Roles** — additions, removals, or changes to role assignments and designees * **Effective Date** and **Expiration Date** * **Groups** — Organizations, Locations, Departments, or custom group assignments * **Document Attachments** — linked or uploaded documents associated with the delegation * **Delegation Pathway** — Matrix, Functional, Direct-Line, or Down-Line constraints Cosmetic edits that do not affect the substance of the authority — such as description-only refinements — do not trigger re-approval. ### Behavior during re-approval * The delegation **remains Issued** and prior values **remain in effect** while the change is under review. This preserves continuity of authority for downstream users. * A **Pending Re-approval** indicator is displayed on the record so all stakeholders can see the change is awaiting review. * An **Approval Action** is generated and assigned to eligible approvers, exactly as for initial issuance. * On **approval**, the proposed revisions are **committed** to the live delegation, overwriting the prior values; the new state takes effect from that point forward. * On **denial**, the proposed changes are discarded and the delegation continues with its prior, approved values. * The **Change Log** captures both the proposed change and the approver's decision, with full attribution. > Change Approval is an optional configuration on top of standard Delegation Approval. It can be enabled in addition to — or independently of — approval at original issuance. *** ## ⚙️ How Approval Actions Work When Aptly determines that a delegation needs approval — at issuance or on a change — it creates a **Delegation Approval Action**: * **Linked** to the specific delegation and the revision under review * **Tracked** through the standard Action lifecycle (To Do → In Progress → Completed, or Cancelled if the underlying delegation is withdrawn before approval) * **Assigned** to all eligible approvers simultaneously * **Notified** to assigned approvers based on tenant and user notification settings The first eligible approver to complete the action — by approving or denying — closes it for all assignees. The approver's decision and identity are recorded on the delegation record and in the Change Log. > While an initial-issuance approval is pending, the delegation is in **Pending** status and cannot be cascaded. While a change approval is pending, the delegation remains **Issued** with a **Pending Re-approval** indicator and continues to operate under its prior, approved values. *** ## 👥 How Are Approvers Assigned? Eligible approvers are determined by each user's `delegation.approve_deny` permission and its scope: 1. **Scope = All** — the user is eligible to approve every delegation in the tenant. 2. **Scope = Groups** — the user is eligible only when their effective group membership overlaps with the delegation's assigned Groups (parent groups inherit their child group assignments). 3. **Scope = None** — the user is not eligible. All eligible approvers are assigned to the Approval Action at the same time. The first to act completes it. ### Issuer & Recipient guardrail A designated approver **cannot approve a delegation on which they are also the Issuer or a Recipient**, even if they otherwise qualify. This safeguards segregation of duties: a user cannot both grant (or receive) authority and authorize the grant. > **Exception:** When the **Root Authority** option is used to issue a Root Delegation, the approval action is assigned to all eligible approvers per the standard permission model — including the user who created the Root Delegation — because Root Authority delegations originate from the system itself rather than from another delegation in a chain. Other stakeholder relationships do not disqualify a user from approving. For example, being a **Role Designee** on the delegation does not block approval. Approvers also do not need to be in the same department or reporting line as the issuer; only the role permission, group alignment, and the Issuer/Recipient guardrail apply. *** ## 🔄 Approval Flow ### Initial issuance 1. A user creates and issues a delegation (`tenant.create_root_delegations` for a Root Delegation, or `delegation.issue_delegation` for a redelegation) 2. Aptly checks whether Delegation Approval is enabled 3. If so, an **Approval Action** is created and assigned to all eligible approvers 4. Assigned approvers are notified 5. The first approver to act **approves** or **denies** the issuance (`delegation.approve_deny`) 6. Delegation status updates to **Issued** (on approval) or returns to **Draft** (on denial) 7. Recipients are notified upon issuance, and the Change Log captures the full trail ### Change to an issued delegation 1. An authorized user edits and saves a substantive change to an Issued delegation (`delegation.edit`) 2. Aptly checks whether Change Approval is enabled 3. If so, the proposed change is staged and an **Approval Action** is created 4. The delegation remains **Issued** with a **Pending Re-approval** indicator; prior values remain in effect 5. Assigned approvers review and either **approve** or **deny** the proposed change 6. On approval, the revisions are **committed** to the live delegation, overwriting the prior values 7. On denial, the proposed changes are discarded and the delegation continues unchanged 8. The Change Log records both the proposed change and the approver's decision > Denied issuances and denied changes can be revised and resubmitted by users with the appropriate permissions. *** ## 🧾 Change Log & Version History Every approval, denial, and edit is captured in Aptly's audit trail: * The **Change Log** records every revision to a delegation — who made the change, when, what role they held at the time, the original and updated values for each affected field, and any approval or denial decision tied to the change. * The **Version History** allows authorized users to view a delegation as it existed on any prior date, reconstructing the full state of the authority as of that point in time. * Both views are available on the delegation record, subject to the `delegation.view_change_log` and `delegation.view_version_history` permissions. > Together, these capabilities give organizations a tamper-evident record of every authority grant and every change — answering questions like *"who held this authority, with what limits, on a given date"* in seconds. *** ## 🔒 Permissions Involved | Permission | Grants ability to… | | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | `tenant.create_root_delegations` | Create the first (root) delegation directly from a published Decision | | `delegation.issue_delegation` | Issue a redelegation from an existing Issued delegation | | `delegation.edit` | Edit an existing delegation (subject to record capacity) | | `delegation.approve_deny` | Receive and complete delegation approval actions, including approvals for changes (eligibility narrowed by scope: All / Groups / None) | | `action.view` | View approval requests and their status | | `delegation.view_change_log` / `delegation.view_version_history` | View the change history and prior states of a delegation | > Eligibility for approving a delegation comes from `delegation.approve_deny` and its scope, applied against the delegation's group assignments. The **Issuer** and **Recipient** are the stakeholder relationships that disqualify a user from approving — other relationships (e.g., Role Designee) do not. See [Roles & Permissions](/essentials/roles-permissions) for the complete permission model. *** ## 📘 Related Pages * [Delegation Lifecycle →](/essentials/delegation-lifecycle) * [Actions and Workflows →](/essentials/actions-and-workflows) * [Roles & Permissions →](/essentials/roles-permissions) * [System Settings →](/essentials/system-settings) *** Need help modeling approval workflows or enabling Change Approval for your tenant? Contact [support@aptlydone.com](mailto:support@aptlydone.com) or visit the Aptly Support Portal.