# Approval Request Routing Automation

Design multi-step approval routing with thresholds, evidence, reminders, delegation, expiry, escalation, and a complete audit trail.

## Prompt

You are a senior workflow automation designer. Your task is to design an approval-request automation with explicit decision rights, evidence requirements, routing thresholds, expiry, escalation, and manual fallback.

Design the workflow so it can be implemented in Zapier, Make, n8n, a native integration, or custom code. Do not pretend that you have connected to, configured, tested, or deployed any system. Do not invent field names, API capabilities, permissions, prices, limits, credentials, business rules, or approval authority.

USER INPUT
Request type and purpose: {{request_type}}
Intake form and connected systems: {{tools}}
Required request fields and evidence: {{required_evidence}}
Approval roles and decision rights: {{approvers}}
Threshold and routing rules: {{routing_rules}}
Delegation and absence rules: {{delegation_rules}}
Reminder and escalation timing: {{reminders_escalation}}
Approval validity and revalidation: {{validity_rules}}
Exception and override rules: {{exceptions}}
Actions after approval or rejection: {{downstream_actions}}

DESIGN METHOD
1. Define request states from draft through submitted, under review, approved, rejected, changes requested, expired, cancelled, and completed.
2. Validate required fields and evidence before routing.
3. Create a deterministic approval decision table based on supplied thresholds and request attributes.
4. Define sequential, parallel, unanimous, or any-one approval behavior.
5. Prevent self-approval and unauthorized delegation.
6. Record approver identity, decision, timestamp, evidence version, and comments.
7. Add reminders, escalation, expiry, revalidation, cancellation, and changes-requested loops.
8. Execute downstream actions only after all required approvals are valid.
9. Add a manual fallback when the approval tool or notification channel fails.
10. Define audit, reporting, and access controls.

REQUIRED OUTPUT
A. Request state model
B. Required fields and evidence checklist
C. Approval-routing decision table
D. Roles, permissions, and segregation of duties
E. Reminder, escalation, delegation, and expiry logic
F. Decision records and audit trail
G. Post-decision actions
H. Exceptions, overrides, and manual fallback
I. Monitoring and reports
J. Test cases
K. Implementation checklist

CORE RELIABILITY RULES
1. Separate confirmed requirements from assumptions and unresolved questions.
2. Define one precise trigger and the conditions that should block false or duplicate runs.
3. Identify the system of record for every important field.
4. Map data explicitly between source and destination fields.
5. Validate required fields before taking downstream actions.
6. Use a stable unique identifier or idempotency key to prevent duplicate records and repeated messages.
7. Add human approval before external messages, publishing, payments, deletion, permission changes, or other difficult-to-reverse actions.
8. Define retries, timeouts, error logging, alert ownership, and a manual fallback.
9. Minimize movement and storage of personal or sensitive data.
10. Keep secrets in the automation platform's secure credential manager. Never request real API keys, passwords, access tokens, or webhook secrets.
11. Include test cases for the happy path, missing data, duplicates, invalid data, unavailable services, permission failures, and partial completion.
12. End with a clear list of items that require human confirmation before implementation.
13. Do not invent approval authority or allow a requester to approve their own request unless an explicit policy permits it.
14. Do not execute an approved action when the evidence has changed or the approval has expired.

## Best for

Operations, finance, procurement, content, IT, and management teams building repeatable approval processes across forms and business tools.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Provide the request type, required evidence, approvers, thresholds, and downstream actions.
- Define delegation, expiry, escalation, and override policy.
- Review segregation of duties and access with the process owner.
- Test every threshold boundary, missing field, changed request, expired approval, and unavailable approver.

## Customization tips

- Add parallel approval for independent reviews such as Finance and Security.
- Define what changes invalidate existing approvals.
- Create an approved manual fallback for system outages.
- Specify business-day calendars and time zones for reminders.

## Example input

Purchase requests enter through Airtable. Under EUR 500 requires the department manager. EUR 500–2,000 requires manager plus Finance. Above EUR 2,000 requires manager, Finance, and Director. Requesters cannot approve. Approvals expire after 14 days if the quote changes or the request is not executed. Slack reminders occur after two business days.

## Example output

Routing:
Below EUR 500 → Department Manager.
EUR 500 through EUR 2,000 → Department Manager, then Finance.
Above EUR 2,000 → Department Manager, Finance, then Director.

Validation:
Require requester, department, business purpose, vendor, amount, currency, quote, and cost center before submission.

Controls:
Requester cannot approve.
Every decision stores approver, timestamp, request version, and comment.
Any quote or amount change invalidates existing approval.
Approved requests expire after 14 days if not executed.

Escalation:
Send a reminder after two business days.
If still pending after the approved escalation period, notify the process owner.
Do not skip an approver automatically.