Role-Based Approval Routing Prompt Template

This prompt is for enterprise product teams building AI agents that must route high-stakes actions to the correct human approvers before execution. Instead of hardcoding approval paths in application code—which becomes brittle as organizational structures, policies, and risk tolerances change—this prompt encodes organizational policy into the AI workflow. It takes a proposed action, its context, and a role directory, then determines which specific roles or individuals must approve. The output is a structured routing list with justification, ready for consumption by an approval orchestration system. The ideal user is an engineering lead or platform architect who maintains a machine-readable role directory and needs the AI layer to reason over it rather than requiring developers to manually update routing logic for every new action type.

Use this prompt when your organization has a defined role directory but approval paths vary by action type, risk level, or domain. It is particularly effective for internal tools, operational workflows, and enterprise automation where the set of possible actions is known but the routing logic depends on contextual factors like dollar amounts, data sensitivity, environment targets, or cross-team impact. The prompt requires three inputs: a description of the proposed action, relevant context (risk tier, affected systems, change size), and a role directory mapping roles to their approval scope. Without a well-maintained role directory, the prompt will hallucinate plausible-sounding but incorrect approval paths. Before deploying, validate the role directory against your identity provider or HR system of record to ensure role names and scopes match reality.

Do not use this prompt for real-time safety-critical systems where deterministic rule engines are required by regulation. If an incorrect routing decision could cause physical harm, irreversible financial loss, or regulatory violation without a human-in-the-loop safety net, the approval logic belongs in application code with auditable, tested rule evaluation—not in a model's probabilistic reasoning. Similarly, avoid this prompt when the action space is unbounded or poorly defined; the model needs a concrete action description to reason about routing. For workflows where approval paths are completely static, a simple lookup table is cheaper, faster, and more reliable. The next section provides the copy-ready prompt template you can adapt to your organization's role directory and approval policies.

This prompt template is the core engine for role-based approval routing. It takes a proposed action, its operational context, and a structured directory of organizational roles, then determines which specific roles or individuals must approve before the action can proceed. The output is a machine-readable routing list with justification for each required approver, designed to be consumed by a downstream workflow engine or a human review queue. Use this template when you need to encode organizational policy into an AI workflow without hardcoding every approval path in application code.

textCopy
You are an approval routing specialist for a regulated enterprise environment. Your job is to determine which roles or individuals must approve a proposed action before it can be executed. You will receive an action description, contextual metadata, and a role directory. You must output a structured routing list with justification for each required approver.

## INPUT

### Proposed Action
[ACTION_DESCRIPTION]

### Action Context
- Risk Tier: [RISK_TIER]
- Affected Systems: [AFFECTED_SYSTEMS]
- Data Sensitivity: [DATA_SENSITIVITY]
- Dollar Amount (if applicable): [DOLLAR_AMOUNT]
- Environment: [ENVIRONMENT]
- Requester Role: [REQUESTER_ROLE]
- Regulatory Frameworks: [REGULATORY_FRAMEWORKS]

### Role Directory
[ROLE_DIRECTORY]

## CONSTRAINTS
- Do not invent roles not present in the Role Directory.
- If no single role clearly owns the decision, escalate to a default authority specified in [ESCALATION_ROLE].
- If the action spans multiple domains, sequence approvals logically (e.g., security before legal before executive).
- If the action is reversible and low-risk, a single approver may suffice. If irreversible or high-risk, require multi-stakeholder signoff.
- For any action involving PII, financial commitments, or production changes, require at least one senior reviewer.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "routing_decision": {
    "approval_type": "single_approver | multi_stakeholder | executive_signoff | auto_approve",
    "approvers": [
      {
        "role": "string",
        "individual": "string | null",
        "sequence": "integer",
        "justification": "string explaining why this role is required",
        "condition": "string describing the triggering condition",
        "timeout_hours": "integer"
      }
    ],
    "escalation": {
      "role": "string | null",
      "trigger": "string explaining when escalation occurs"
    },
    "blocking_conditions": ["string describing any conditions that block execution entirely"],
    "confidence": "high | medium | low",
    "uncertainty_notes": "string explaining any ambiguity in the routing decision"
  }
}

Adaptation guidance: Replace the square-bracket placeholders with live data before sending to the model. The [ROLE_DIRECTORY] should be a structured list of roles, their authorities, and any constraints (e.g., "Security Officer: can approve access changes up to Tier 3; requires CISO co-approval for Tier 4+"). The [ESCALATION_ROLE] is a fallback when no role clearly owns the decision—typically a department head or compliance officer. Use Structured Outputs or JSON mode in your model API to enforce the schema. For high-risk domains (finance, healthcare, critical infrastructure), always route the output to a human review queue rather than executing automatically, even if the model returns auto_approve.

The prompt is one component in a larger approval orchestration system. Before calling the model, assemble the role directory from your identity provider or HR system. Validate that every role referenced in the directory exists and has a defined scope. This prevents the model from hallucinating roles that don't exist in your organization. The directory should be a structured object mapping role identifiers to display names, scope descriptions, and any conditional constraints (e.g., 'VP of Engineering' only approves infrastructure changes above $50k). Pass this directory into the prompt's [ROLE_DIRECTORY] placeholder as a JSON array of role objects with id, name, scope, and constraints fields.

After receiving the model output, validate the JSON structure against the output contract before acting on it. The expected schema is an object with an approvers array, where each element contains role_id, justification, sequence_order, and optional escalation_to and timeout_minutes fields. Use a JSON Schema validator in your application layer to catch malformed responses. If validation fails, re-invoke the prompt with the error details appended to [CONSTRAINTS] rather than silently falling back to a default routing. For each approver in the routing list, resolve the role_id to actual user identities using your directory service—this is a deterministic lookup that should never rely on the model. If the model returns an escalation_to path, log it and notify the escalation target immediately rather than waiting for the timeout to expire.

Always log the full prompt, response, and resolved approver list for audit purposes. This is critical for regulated workflows where you must demonstrate who approved what and why. Store these logs in an append-only audit store with timestamps and request IDs. Implement a timeout mechanism: if an approver does not respond within the configured SLA window, re-invoke the prompt with the updated state (including which approvers have and haven't responded) to determine the next escalation step. Never execute the action until all required approvals are collected and verified. For model choice, prefer a model with strong JSON-following behavior (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set temperature=0 to minimize routing variability. If your approval policies change frequently, consider implementing a RAG retrieval step that pulls the latest policy documents into [CONTEXT] before each invocation rather than hardcoding policy into the prompt itself.