Approval policy template: turn rules into a working workflow

An approval policy should tell people and software exactly which decisions need review, who may decide, which facts change the route, what evidence the decision needs, and what happens when the standard route cannot continue. A policy becomes executable when every clause maps to a required input, a rule, a workflow state, an evidence record, and a test.

Use the template below to write that contract before anyone configures fields, notifications, or approval buttons. It works for purchase, contract, access, hiring, budget, content, and operational requests.

Source review: August 28, 2026. This guide offers a workflow-design method, not legal, audit, procurement, HR, security, or compliance advice. Your policy and control owners should set the real authority, evidence, retention, and review requirements.

What is an approval policy?

An approval policy is the authoritative set of rules that defines which decisions require approval, which roles may act, which conditions change the required route, and which evidence proves a valid outcome.

Keep four artifacts separate:

• Approval policy: states the organization's rules, authority, scope, exceptions, and evidence requirements.
• Approval matrix: lists roles and authority limits for defined decision classes. Use the approval matrix template to build that table.
• Approval workflow: applies the policy to one request by evaluating facts, assigning reviewers, changing states, and recording outcomes.
• Approval record: preserves the request, evidence, applied rules, people, events, reasons, and final result.

A matrix cannot replace the policy because thresholds alone do not define request evidence, risk reviews, exceptions, completion rules, or record requirements. A workflow cannot replace the policy because configuration shows what the system does, not who authorized those rules.

Use this 12-part approval policy template

Write each section in plain language. Give every rule a stable identifier so workflow builders and reviewers can trace configured behavior back to an approved clause.

1. Purpose and control outcome

State the decisions the policy governs and the outcome it protects. Name the operational, financial, security, legal, quality, or accountability risk that requires approval.

Example: “AP-1 governs company software purchases so authorized roles review budget, data handling, contract terms, and operational ownership before commitment.”

2. Scope and exclusions

List the business units, request types, regions, legal entities, channels, and systems covered. State exclusions explicitly and point each excluded class to its governing policy.

A phrase such as “all significant purchases” creates guesswork. Define the request classes and the facts that place a request inside or outside scope.

3. Definitions and source data

Define terms that affect the decision. Examples include total commitment, material change, sensitive data, policy exception, emergency, requester, reviewer, approver, delegate, and final authority.

For each important fact, name its authoritative source and normalization rule. If the policy uses contract value, specify currency, tax treatment, term, renewal, and aggregation. Otherwise, two teams can apply the same threshold to different numbers.

4. Roles, ownership, and accountability

Name the policy owner, workflow owner, request owner, reviewers, approvers, control owners, system administrator, and record owner. State which role answers each decision question.

The 2025 U.S. GAO Green Book tells federal agencies to establish organizational structure, assign responsibility, and delegate authority. Other organizations can use that as a control-design reference, but their own governance must set the actual roles.

5. Authority and separation rules

Link the policy to the approved authority source, such as a board delegation, signing authority schedule, role charter, or approval matrix. Define value limits, decision classes, specialist authority, and any actions one person may not combine.

NIST SP 800-53 Revision 5.1 AC-5 calls for organizations to identify duties that require separation and define access authorizations that support that separation. Translate that principle into explicit rules, such as blocking requesters from approving their own requests or keeping access administration separate from audit review.

6. Request and evidence requirements

List the facts and artifacts a requester must provide before review starts. Separate universal requirements from conditional evidence.

• Require a stable request ID, requester, business owner, request type, purpose, value, department, and desired date.
• Add contracts, quotes, data classification, security details, budget codes, designs, risk assessments, or supporting records when the request class needs them.
• Define which missing facts return the request and which ones stop it completely.

7. Decision and routing rules

Write each rule as a condition and result. Include the actor, authority, route, completion rule, and outcome.

“Large purchases need Finance” is not executable. “AP-7: When total annual commitment exceeds the approved department-manager limit, require Finance approval before contract commitment” gives builders a field, condition, reviewer, order, and stop point.

Use the approval routing rules guide to define safe evaluation order, boundary conventions, risk overlays, and no-match behavior.

8. Decision states and completion rules

Name every allowed state and the action that enters or leaves it. A practical set may include Draft, Submitted, Needs information, In review, Changes requested, Approved, Rejected, Withdrawn, Exception, and Closed.

For multi-reviewer stages, state whether any one reviewer, every reviewer, a majority, or one named final authority must approve. Define what rejection, abstention, and no response do. Do not let a generic “Done” state hide whether the request gained approval or stopped for another reason.

9. Exceptions, delegation, and escalation

Define these paths separately. An exception handles a request that cannot follow the normal rule. Delegation gives a qualified substitute temporary authority. Escalation changes attention or ownership after a defined condition.

For each path, name the trigger, allowed actor, scope, evidence, expiry, return point, and prohibited actions. The exception guide and delegation guide provide reusable control contracts.

10. Decision evidence and records

State what the workflow must preserve for every request: subject and version, request facts, applied policy and rule version, reviewers, authority, decisions, reasons, timestamps, evidence references, exceptions, changes, and downstream actions.

Set access, retention, retrieval, and correction rules with the appropriate records, legal, security, and privacy owners. The approval audit-trail guide separates the current request, chronological event history, and control context.

11. Policy and workflow change control

Name who may approve policy changes and who may change the configured workflow. Require a change packet with the policy version, affected rules, impacted fields and routes, test cases, treatment of in-flight requests, effective date, and communication owner.

Do not let a builder quietly “fix” a rule that changes authority. Treat that as a policy decision and obtain the required approval first.

12. Monitoring and review

Define the signals that should trigger review: recurring exceptions, unmatched requests, policy breaches, self-approval attempts, overdue stages, reversed decisions, control failures, organizational changes, or new legal obligations.

Name the review cadence and owner. Record each decision to keep, revise, retire, or replace the policy and its workflow.

Map every policy clause to six workflow elements

A written policy and a configured workflow drift apart when teams cannot trace one to the other. Build a mapping sheet with one row per enforceable clause and these six columns:

1. Policy clause: stable ID and approved wording.
2. Required input: field, source record, role, amount, risk flag, or other fact that the rule evaluates.
3. Executable rule: complete condition, assigned actor, route, and completion behavior.
4. Workflow state: current and next state for every allowed result.
5. Evidence: values, identities, reasons, timestamps, versions, and events that prove the rule ran correctly.
6. Test: positive, negative, boundary, exception, and permission cases that demonstrate the expected behavior.

Run the traceability check in both directions. Every enforceable policy clause should map to workflow behavior or a documented manual control. Every configured workflow rule should cite an approved clause. An orphaned clause never runs. An orphaned rule has no documented authority.

A software-purchase example shows the mapping

Consider an illustrative policy for software purchases. The policy uses total annual commitment, data classification, contract terms, and system access to select reviewers.

• Clause AP-6: Every request must include a business owner, annual commitment, contract, data classification, and access description.
• Clause AP-7: Requests above the department-manager limit require Finance approval.
• Clause AP-8: Any vendor that handles company or customer data requires Security review, regardless of value.
• Clause AP-9: Nonstandard contract terms require Legal review.
• Clause AP-10: A requester cannot approve their own request.

The workflow collects the required facts, validates completeness, blocks self-approval, adds independent specialist reviews, and sends the completed package to the final financial authority. The record stores each applied clause, input value, reviewer, decision, reason, and evidence version.

Now test combinations. A low-value tool that handles sensitive data should still reach Security. A high-value renewal with standard terms should reach Finance without inventing a Legal requirement. A request that matches no authority band should stop with the workflow owner, not continue by default.

Test the policy and workflow together

Policy review alone finds unclear wording. Workflow testing alone finds configuration defects. Run both against the same cases.

1. Submit a request just below, exactly at, and just above every authority boundary.
2. Pair each value band with each specialist risk condition.
3. Remove one required fact and confirm the request cannot enter review.
4. Submit a request from the person who would normally approve it.
5. Remove the named approver and confirm the request reaches a controlled fallback.
6. Change material evidence after one reviewer approves.
7. Trigger a policy exception and confirm only the authorized exception owner may decide.
8. Activate a delegate and confirm scope, timing, separation, and attribution remain intact.
9. Change one policy clause and identify every affected field, rule, state, view, notification, and test.
10. Ask an independent reviewer to reconstruct the outcome from the record alone.

A critical failure should stop launch. Examples include self-approval, missing authority, silent no-match behavior, unrecorded evidence changes, an exception without an owner, or a decision that cannot trace to the active policy version.

Translate the policy into Formaloo without hiding the rules

Formaloo's current approval workflow guidance starts with a request Form and uses request fields, admin-only internal fields, Advanced logic, On submit and On update actions, Assignee routing, and Table or Kanban Data Blocks for review.

Use those documented building blocks to represent:

• the request facts and evidence that each policy clause requires;
• internal policy ID, rule version, status, assignee, decision, reason, and exception fields;
• Advanced logic conditions that apply the approved routing specification;
• On submit actions for initial validation, assignment, and notifications;
• On update actions for decisions, rework, reassignment, exceptions, and status changes;
• Table or Kanban views for pending work, exceptions, policy versions, and control review.

The current Formaloo approval workflow guide documents request fields, admin-only status and Assignee fields, routing, notifications, and review views. The Assignee guide explains assignment to people or teams and notes that email notifications require a separate rule. Confirm plan access, permissions, and deployment details for your workspace.

Current Help Center sources do not describe a dedicated policy-document object that approves and versions the written policy itself. Keep the approved policy as the authoritative source, store its stable ID and version in the workflow, and review the mapping sheet whenever either side changes.

If you want to turn approval policy into a working enterprise workflow, Book a demo.

Copy this compact approval policy skeleton

1. Purpose: This policy governs [decision classes] to protect [control outcomes].
2. Scope: It applies to [business units, entities, regions, systems, and request types] and excludes [named exclusions].
3. Definitions: Key terms and source-data rules include [terms, calculations, versions, and authoritative sources].
4. Ownership: [Policy owner] approves policy changes; [workflow owner] maintains configuration; [record owner] maintains evidence.
5. Authority: Roles and limits follow [approved authority source and version].
6. Request requirements: Every request must include [universal evidence]; conditional evidence includes [risk-based requirements].
7. Rules: Each rule states [policy ID, condition, actor, authority, route, completion rule, and outcome].
8. States: Allowed states and transitions are [state model and allowed actors].
9. Exceptions: Exception, delegation, and escalation rules define [trigger, owner, scope, evidence, expiry, and return].
10. Records: The workflow preserves [request, evidence, rule version, actors, decisions, reasons, events, and outcomes] for [retention rule].
11. Changes: Policy or workflow changes require [approver, impact review, tests, treatment of in-flight work, effective date, and communication].
12. Review: [Owner] reviews [signals and metrics] every [cadence] and records the decision.

Keep policy and workflow in parity

The policy should remain readable to people who never open the workflow builder. The workflow should remain testable by people who did not write the policy.

Review both whenever authority, organization structure, risk conditions, data sources, legal obligations, or system behavior changes. A signed policy that the workflow ignores creates false confidence. A workflow rule that the policy never authorized creates hidden governance.

Keep one traceable line from policy clause to input, rule, state, evidence, and test. That line turns approval policy from a document people acknowledge into a control people can operate and verify.

Sources

• U.S. GAO: 2025 Green Book, Standards for Internal Control in the Federal Government
• NIST SP 800-53 Revision 5.1
• Formaloo Help Center: How to build an approval workflow in Formaloo
• Formaloo Help Center: How to add Advanced logic to your form
• Formaloo Help Center: What is On update logic and how it works
• Formaloo Help Center: How to assign form submissions to a person or team

Sources and product guidance reviewed on August 28, 2026.