What you'll learn: This article explains how Roles and Conditions flow from Decisions to Delegations, what happens when authority is redelegated, and where you have control at the individual delegation level. Understanding these cascade rules is essential for managing governance requirements consistently across your delegation chains.

Who this is for: Administrators and managers who configure Decisions and issue Delegations. Regular users who view Roles and Conditions on their Delegations will also benefit from understanding where these requirements come from and why they may differ between Delegations.

Note: Roles and Conditions are only available if your organization's subscription and tenant configuration include them. If you don't see Conditions or Roles tabs on Decisions or Delegations, check with your administrator.

The big picture: Decision sets the baseline, Delegations inherit it

When a Decision is configured with Roles and Conditions, those governance requirements become part of the authority definition itself. Every Delegation issued from that Decision inherits the Roles and Conditions that were in place at the time of issuance. As authority flows downstream through redelegations, these requirements travel with it — ensuring that the governance context defined at the Decision level stays visible throughout the entire delegation chain.

However, "cascade" does not mean "locked." Aptly gives delegation managers specific controls to tailor Roles and Conditions at the delegation level — within boundaries that preserve the integrity of the governance chain.

How Conditions cascade

Conditions capture plain-language criteria that must be met for authority to apply — for example, "Requires dual signature above $250,000" or "Applies only to US entities." When you configure Conditions on a Decision, every Delegation linked to that Decision inherits those Conditions.

Cascade direction and behavior

Conditions cascade downward only. When a new Condition is added to a Delegation, it is automatically added to all child Delegations further down the chain. The Condition appears on each child in the same active or inactive state as it was on the Delegation where it was created. Conditions do not cascade upward — adding a Condition to a child Delegation does not affect its parent.

What happens on redelegation

When a Delegation is redelegated, all Conditions on the source Delegation carry forward to the new Delegation automatically. The recipient of the redelegation sees the full set of Conditions that applied to the authority they are receiving.

Editing a Condition

If the name or description of a Condition is edited, that change is reflected everywhere the Condition appears — across all Delegations in the chain. This keeps terminology and requirements language consistent regardless of where a user encounters the Condition.

Activating and deactivating Conditions per Delegation

While Condition text is shared across the chain, the active/inactive status of a Condition can be managed independently on each Delegation. This means a Delegation manager can deactivate a Condition for their specific Delegation without affecting whether that Condition is active on the parent Delegation, on sibling Delegations, or on child Delegations further down the chain.

This is useful when a Condition applies broadly but does not apply to a specific recipient's scope of authority — for example, a geographic restriction that is not relevant in a particular region's Delegation.

Deleting a Condition

Deleting a Condition removes it from all Delegations where it appears — both up and down the chain. This is a significant action. If a Condition needs to be removed from only one Delegation, deactivating it (rather than deleting it) preserves it on other Delegations in the chain.

How Roles cascade

Roles define oversight responsibilities attached to authority — such as reviewer, approver, co-signer, or initiator. Each Role on a Delegation identifies a position or person who has a defined responsibility in the decision-making process. When Roles are configured on a Decision, they cascade to Delegations in a similar (but not identical) way to Conditions.

Cascade direction and scope

Like Conditions, Roles cascade downward only. When a new Role is created on a Delegation, the creator can choose to apply it to just that single Delegation or cascade it down to all child Delegations in the chain. Roles do not cascade upward.

What happens on redelegation

When a Delegation is redelegated, all Roles on the source Delegation carry forward to the new Delegation. The full set of Role assignments travels with the authority.

Editing a Role

Edits to a Role are reflected on all Delegations where that Role appears, keeping the Role definition consistent throughout the chain.

Deleting a Role

When a Role is deleted, it is removed from the current Delegation and all child Delegations where it appears. Unlike Condition deletion, Role deletion does not cascade upward to parent Delegations.

Key differences between Conditions and Roles cascade behavior

While Conditions and Roles share the same general downward cascade pattern, there are important differences in how certain actions propagate through the delegation chain.

Decision-level vs. delegation-level: where governance is defined

Some governance data is defined on the Decision and inherited by every linked Delegation; other data can be set independently at the Delegation level. Understanding this distinction helps administrators decide where to make changes.

A practical example

To see how these rules work together, consider this scenario:

An administrator creates a Decision called "Approve Vendor Contracts" with two Conditions ("Dual signature required above $250,000" and "Must use approved vendor list") and one Role (Consulted: Legal). The administrator then issues a Root Delegation to the Finance Director.

The Finance Director's Delegation inherits both Conditions (active) and the Consulted: Legal Role. The Finance Director deactivates the "Must use approved vendor list" Condition because their region uses a different procurement workflow — this deactivation affects only their Delegation.

The Finance Director then redelegates part of their authority to a Plant Controller. The Plant Controller's Delegation receives both Conditions (in the same state they held on the source Delegation: "Dual signature required above $250,000" is active, "Must use approved vendor list" is inactive) and the Consulted: Legal Role.

Later, the administrator updates the Condition text from "Dual signature required above $250,000" to "Dual approval required above $250,000." This wording change is reflected on the Finance Director's Delegation, the Plant Controller's Delegation, and all other Delegations in the chain — because Condition text edits propagate universally.

Permissions required

Managing Conditions and Roles on Delegations requires the Manage Conditions and Roles permission, which can be scoped to All, Groups, or None. This permission is configured in Settings → Users & Roles → Roles under the Delegations permissions section.

Users who do not have this permission can still view Conditions and Roles on Delegations they have access to — they just cannot add, edit, activate/deactivate, or delete them.

Visibility in Matrices

Roles assigned on Delegations are visible in the Role Matrix, which displays authority holders alongside their configured roleholders. This gives stakeholders a cross-organizational view of who else must be involved in each decision-making process — reviewers, co-signers, consultants — without needing to open individual Delegation records.

Conditions are visible on individual Delegation records and in the Authority Matrix drawer view when viewing Delegation details, but they are not displayed as standalone columns in Matrix table views.

Frequently asked questions

If I add a Condition to a mid-chain Delegation, does it appear on the parent?

No. Conditions cascade downward only. The new Condition will appear on the Delegation where it was added and on all child Delegations below it in the chain, but not on any parent or sibling Delegations.

Can I add a Role to just one Delegation without affecting others?

Yes. When creating a new Role on a Delegation, you can scope it to that single Delegation only, without cascading it to child Delegations.

What happens if I delete a Condition — can I undo it?

Deleting a Condition removes it from all Delegations in the chain (both upstream and downstream). This action cannot be undone. If you want to remove a Condition from just one Delegation, deactivate it instead.

Do Condition and Role changes appear in the Changelog?

Yes. Changes to Conditions and Roles on a Delegation are recorded in that Delegation's Changelog, providing an audit trail of what changed, when, and by whom.

I don't see Conditions or Roles on my Delegations — why?

There are several possible reasons: Conditions and Roles may not be enabled in your tenant's Decision settings, the specific Decision may not have Conditions and/or Roles toggled on, or your role may not have the permissions to view them. Check with your administrator.

Related articles

• Roles vs. Conditions: When to Use Each — comparison guide for administrators deciding how to structure governance requirements
• Manage Roles on a Decision
  — step-by-step tutorial for configuring Roles on a Decision
• Manage Conditions on a Decision — step-by-step tutorial for configuring Conditions on a Decision
• Decision Authority Conditions & Roles (Settings) — admin configuration for enabling Conditions and Roles at the tenant level
• How Pathway Changes Affect Downstream Delegations — cascade behavior when Delegation Pathway options change upstream
• Invalid Delegations: What It Means and How to Resolve It — understanding and remediating invalid states caused by upstream changes