Delegation
Delegation lets one actor authorize another to carry out checker or approver duties on their behalf when they are unavailable — widening who is eligible to act without ever relaxing the rules that keep work honest.
What delegation is
In AIPM, work moves through three distinct roles: the maker who produces a deliverable, the checker who verifies it, and the approver who signs off. Sometimes the person normally responsible for a checker or approver duty is out — on leave, traveling, or simply away from their inbox.
A delegation is a grant in which one actor (for example, a sponsor or an approver) authorizes another actor to act in their place for those duties. The delegate steps in and performs the check or the approval, and the item keeps moving. See the Deliverables Workflow for how the maker → checker → approver stages fit together.
Separation of duties always holds
Delegation never breaks separation of duties (SoD). The maker → checker → approver three-role rule still applies in full:
- A delegate who is also the maker of the deliverable is still rejected — they cannot check or approve their own work.
- A delegate who was the checker on an item is still rejected from then approving that same item.
- Delegation widens who is eligible to act; it does not collapse the three distinct roles into fewer hands.
In short: the same person can never fill two of the three roles, no matter who delegated authority to whom.
Scope: limiting where a delegation applies
A delegation can be scope-limited rather than blanket. For example, you might grant authority only for a specific project, or only for a particular class of deliverables. Within that scope the delegate acts freely; outside it, they have no authority.
If a delegate tries to act outside the granted scope, the action is refused with a clear error — the system emits a delegation_scope_exceeded error code at its API surfaces. This keeps delegations narrow and intentional, so a grant for one project never quietly extends to another.
The “any eligible” coverage model
With a delegation in place, any eligible delegate may act — not just one named person. This is the practical point of delegation: it provides coverage. When the primary approver is away, you do not have to wait for one specific stand-in to be free; whoever is eligible under the grant can pick up the item and keep it moving. See the Dashboard to find items waiting on action.
Setting up a delegation in the UI
You delegate from your working surface rather than through any back-office screen. From the dashboard or your inbox, use the Delegate action on the relevant item or inbox:
- Choose the grantee — the actor who will act on your behalf.
- Optionally set the scope — the project or class of deliverables the grant covers. Leaving scope open grants broadly; setting it keeps the delegation tight.
Once granted, eligible delegates can act immediately, and their work flows through the same checker and approval gates as anyone else. For what an approver must attach when they sign off, see Approving with Evidence.
Audit and accountability
Every delegated action is recorded in the audit trail, attributed to both the delegate (the actor who actually performed the step) and the delegation grant that authorized it. Nothing is anonymized by acting on someone's behalf — you can always see who did the work and under whose authority. This preserves full accountability even when coverage shifts from person to person. See Export and Audit for how to review and export this trail.
What delegation does NOT do
- It does not let one person fill two of the three roles (maker, checker, approver).
- It does not bypass the checker-passed gate that must be cleared before an approval.
- It does not grant authority beyond the stated scope — acting outside it is refused with
delegation_scope_exceeded.