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 for the complete permission model.

---

📘 Related Pages

• Delegation Lifecycle →
• Actions and Workflows →
• Roles & Permissions →
• System Settings →

---

Need help modeling approval workflows or enabling Change Approval for your tenant? Contact [e-mail] or visit the Aptly Support Portal.