Approval Delegation Chain Resolution Prompt

This prompt resolves the question: 'Who can approve this now?' when the designated primary approver is unavailable. It is designed for the approval routing layer of a human-in-the-loop workflow, sitting between the moment an absence is detected and the moment an approval request is dispatched. The ideal user is a platform engineer or product developer building an enterprise approval system who needs to encode organizational delegation policy into an AI workflow without hardcoding every possible delegation path in application code. The prompt requires three structured inputs: an organizational delegation policy that defines who can delegate to whom and any authority limits, an absence record that specifies who is unavailable and for how long, and a pending action that describes what needs approval, its risk level, and the original target approver.

This prompt is not a general-purpose approval router. Do not use it to determine the initial approval path for a new action—that responsibility belongs to sibling prompts like Role-Based Approval Routing or Conditional Approval Path. Do not use it to perform risk scoring on the action itself, to execute the final approval decision, or to handle multi-stakeholder consensus. The prompt assumes the primary approver has already been identified and is now unavailable. It walks the delegation chain step by step, checking for circular references, authority limit violations, and expired delegations. If the chain breaks—because no valid delegate exists, a cycle is detected, or the delegate lacks sufficient authority—the prompt should return a structured escalation signal rather than guessing or silently routing to an unauthorized individual.

Before deploying this prompt, ensure your delegation policy is available in a machine-readable format. The prompt works best when the policy is explicit about delegation scope (e.g., 'Director can delegate to any Manager in their reporting line for amounts up to $50,000') rather than relying on implicit organizational hierarchy. Test the prompt against known failure modes: circular delegations where Alice delegates to Bob who delegates back to Alice, authority limit violations where a delegate lacks the spending or access level required by the action, and missing delegation records where the policy is silent about a particular role's delegation rights. In high-risk domains such as financial approvals or healthcare signoffs, always log the full delegation chain with timestamps and require a human to confirm the resolved approver before the approval request is sent. This prompt reduces operational latency in approval workflows, but it does not replace the need for auditable delegation records and periodic policy reviews.

This prompt template is designed for a single-turn resolution call within an enterprise approval workflow. It accepts a primary approver, their unavailability reason, and a set of organizational delegation policies. The model is instructed to walk the delegation chain, apply authority limits, and detect circular delegations or authority violations. The output is a structured JSON object containing the final delegated approver, the complete delegation path, and any restrictions or warnings. Use this prompt when a workflow engine encounters an unavailable approver and must programmatically determine the next valid authority without hardcoding every possible delegation path in application code.

textCopy
You are an approval delegation resolver for an enterprise workflow system. Your task is to determine the correct delegated approver when a primary approver is unavailable.

## INPUT
- Primary Approver: [PRIMARY_APPROVER_ID]
- Unavailability Reason: [UNAVAILABILITY_REASON]
- Action Context: [ACTION_CONTEXT]
- Delegation Policy: [DELEGATION_POLICY_JSON]
- Organizational Hierarchy: [ORG_HIERARCHY_JSON]

## DELEGATION POLICY SCHEMA
The delegation policy is a JSON array of rules. Each rule has:
- `role` (string): The role this rule applies to.
- `delegates_to` (array of strings): Ordered list of roles or specific user IDs to try.
- `authority_limits` (object, optional): Constraints like `max_amount`, `allowed_action_types`, `requires_quorum`.
- `absence_rules` (object): Maps absence reasons (e.g., "vacation", "sick", "conflict_of_interest") to specific delegation overrides.

## TASK
1. Identify the primary approver's role from the organizational hierarchy.
2. Find the matching delegation rule in the policy.
3. Apply any absence-specific overrides.
4. Walk the `delegates_to` list in order. For each candidate:
   - Verify the candidate exists in the organizational hierarchy.
   - Check that the candidate is not the original requester (if [REQUESTER_ID] is provided).
   - Check that the candidate does not create a circular delegation (i.e., they have not already appeared in the chain).
   - Check that the candidate's own authority limits (from the policy) allow them to approve this action.
   - If the candidate is unavailable, use their own delegation rule to continue the chain.
5. Stop at the first valid, available candidate.
6. If no valid candidate is found, return a failure with the reason.

## OUTPUT SCHEMA
Return ONLY a valid JSON object with this exact structure:
{
  "delegated_approver": {
    "user_id": "string",
    "role": "string",
    "delegation_path": ["string"],
    "restrictions": ["string"]
  },
  "resolution_status": "resolved" | "failed",
  "failure_reason": "string | null",
  "warnings": ["string"]
}

## CONSTRAINTS
- Do not select an approver who is the original requester.
- Do not create a delegation chain longer than [MAX_CHAIN_LENGTH] steps.
- If an authority limit is violated, skip that candidate and try the next.
- If a circular delegation is detected, abort the chain and return a failure.
- If the action type is not covered by any candidate's authority, return a failure.

To adapt this prompt, replace the square-bracket placeholders with live data from your workflow engine. [PRIMARY_APPROVER_ID] is the user ID of the unavailable approver. [UNAVAILABILITY_REASON] should match the keys in your policy's absence_rules (e.g., "vacation"). [ACTION_CONTEXT] is a JSON object describing the action, including type, amount, and requester_id. [DELEGATION_POLICY_JSON] and [ORG_HIERARCHY_JSON] are the serialized policy and hierarchy data. Before deploying, validate the model's output against the expected JSON schema. If the resolution_status is failed, your application should escalate to a human administrator rather than retrying the prompt. For high-risk actions, always log the full delegation path and warnings for auditability.

This prompt is not a standalone chatbot interaction; it is a deterministic resolution function wrapped in an LLM call. The application layer is responsible for providing the canonical source of truth for organizational policy, absence records, and authority limits. The model resolves the delegation chain from that structured input, but it must never be the system of record. Before calling the model, assemble a pre-processed context object containing the primary approver's status, the full delegation policy, any temporary overrides, and the action's risk tier. This ensures the model operates on a complete, consistent snapshot rather than relying on stale or hallucinated organizational knowledge.

Post-processing must validate the output against the input constraints. Implement a strict schema validator that checks: (1) the resolved approver exists in the provided directory, (2) the delegation path does not contain cycles, (3) no authority limit is exceeded by the action's risk tier or value, and (4) the chain depth does not exceed a configurable maximum (e.g., 5 hops). If validation fails, do not retry blindly. Log the failure with the input snapshot, the invalid output, and the specific validation error. For high-risk actions, route the failure to a human review queue with the full context rather than attempting automated recovery. For lower-risk actions, a single retry with an explicit error message injected into the prompt context is acceptable, but cap retries at one to avoid loops.

Model choice matters here. This is a structured reasoning task that benefits from models with strong instruction-following and JSON mode support. GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate defaults. Avoid smaller or older models that may hallucinate delegation paths or ignore authority limit constraints. Set temperature=0 to maximize determinism. Enable structured output mode if the model provider supports it, binding the response to a typed schema rather than relying on prompt-level format instructions alone. Log every resolution attempt—including the model, input snapshot, output, validation result, and latency—to an append-only audit table. This audit trail is essential for compliance reviews and debugging incorrect delegations.

The application should maintain a short-lived cache of resolved delegation chains keyed by a hash of the input parameters (approver ID, policy version, action context). Cache TTL should align with the volatility of your absence and policy data—typically 5 to 15 minutes. Invalidate the cache immediately when an absence record is updated, a delegation policy changes, or an override is applied. This reduces latency and cost for repeated resolution requests within the same operational window while preventing stale delegation decisions from persisting.

Finally, implement a circuit breaker. If the model returns invalid outputs for more than a configurable threshold of requests within a time window (e.g., 5 failures in 60 seconds), stop calling the model and escalate all pending resolutions to the designated fallback approver or human review queue. This prevents a cascading failure where a model degradation or upstream data issue blocks all approval workflows. The circuit breaker should auto-reset after a cool-down period, but require a human to acknowledge the incident before normal resolution resumes for high-risk action categories.