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 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 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 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 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 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 →
• Actions and Workflows →
• Roles & Permissions →
• System Settings Overview →
• Group Management →
• Matrix Management →
• Document Management →

---

Need help designing your delegation structure or configuring approval and acceptance workflows? Reach out to [e-mail] or visit the Aptly Support Portal.