Enterprise approval governance: one model for every business unit

Enterprise approval governance works best as a federated operating model. Enterprise owners set one control baseline. Business-unit owners configure local routes within clear boundaries. Risk specialists define the reviews that their domains require. Platform administrators implement approved changes. Assurance owners check the evidence.

In short: centralize the contract, federate the configuration, and verify the evidence. Do not force every department through one giant route, and do not let every team invent its own decision states, authority rules, or audit record.

Source review: August 25, 2026. This guide provides an operating model, not legal, financial, audit, or compliance advice. Your policy, risk, and records owners should set the actual controls for your organization.

Standardize the control contract, not every local route

Enterprise approval governance defines how the organization creates, owns, changes, measures, and reviews approval workflows. It should make a decision consistent enough to trust across business units without pulling every routine choice into headquarters.

The model has three parts:

1. One shared contract: Every workflow follows the same minimum rules for identity, authority, states, evidence, exceptions, changes, and reporting.
2. Bounded local control: Business units choose local fields, reviewers, targets, and integrations when those choices stay inside the shared contract.
3. Independent verification: A named owner samples live decisions, tests important routes, and tracks corrective work across the portfolio.

This approach avoids two common failures. Total central control creates a queue of local changes that headquarters does not understand. Total local control produces different meanings for “approved,” inconsistent evidence, duplicate tools, and rules that no one reviews.

Current GOV.UK guidance offers a useful principle for multi-team work: more teams do not automatically need more governance, and leaders should not force every team to work in exactly the same way. Its governance guidance also recommends giving teams authority within known boundaries and escalating decisions only when they leave those boundaries.

Make seven elements mandatory across every business unit

The enterprise baseline should stay short enough to use and strict enough to protect the decision. Require these seven elements in every approval workflow.

1. Give every workflow a registered identity

Record a stable workflow ID, name, purpose, business owner, technical owner, risk tier, active version, effective date, review date, and system location. The register should also identify any replaced workflow so teams do not keep using an old route from a saved link.

2. Use one decision-state vocabulary

Define the states that every portfolio report can understand. A practical minimum includes Draft, Submitted, In review, Returned, Approved, Rejected, Cancelled, and Failed. A local team may add a specialist state, but it should map back to one enterprise state.

“Closed” should not hide whether a request won approval, failed, or disappeared. Keep the terminal result explicit.

3. Tie authority to roles and conditions

Every route should state which role may decide, which request facts trigger that authority, and which specialist reviews must occur. Use the approval matrix to define authority and the routing specification to translate it into conditions.

NIST SP 800-53 AC-5 tells organizations to identify and document duties that need separation and define access authorizations that support that separation. Apply that test across business units. The requester, approver, workflow administrator, and evidence reviewer should not collapse into one person when policy requires independent roles.

4. Control exceptions and overrides

Name every exception state, authorized owner, permitted action, required reason, evidence rule, expiry condition, and return point. An override should never mean “someone senior changed it.” It should identify the authority, reason, compensating control, decision time, and affected workflow version.

Keep the detailed paths in an approval exception contract.

5. Preserve one minimum evidence record

Require request identity, requester identity, material request facts, route version, reviewer identity and role, decision, decision time, rationale, evidence references, exception events, and final outcome. The approval audit-trail guide explains how to separate business evidence, workflow history, and system evidence.

6. Put every change through a release rule

Record the proposed change, owner, reason, risk review, test evidence, approver, release time, affected workflows, rollback plan, and version. Apply the new version to a defined set of requests. Do not let an editor change a threshold while open requests sit in the queue without deciding which version governs them.

7. Use one metric dictionary

Define when the clock starts, pauses, resumes, and ends. Use the same formulas for cycle time, review time, return rate, overdue rate, exception rate, and decision outcome across business units. The approval metrics guide provides the event and clock definitions.

Let business units control five bounded choices

Local owners need enough freedom to match their work. They can control these choices when the enterprise baseline does not prohibit them:

• Request fields: Add cost centers, product lines, regions, contract details, or operational evidence that the local decision needs.
• Review targets: Set service targets that reflect local volume and risk, while using the enterprise clock definitions.
• Additional reviewers: Add local finance, legal, security, procurement, or operational reviewers without removing mandatory enterprise reviews.
• Working views and notifications: Choose the queue layout and message timing that helps the local team act, while preserving access and evidence rules.
• Downstream handoffs: Connect an approved decision to the local finance, HR, procurement, CRM, or service system under the enterprise integration standard.

A local choice leaves the boundary when it weakens separation of duties, changes the meaning of a decision state, removes required evidence, exposes restricted data, bypasses an enterprise risk review, or changes a shared integration. Route those changes to the enterprise owner.

Separate policy, business, platform, and assurance authority

Assign roles before anyone configures a form or rule. One person may hold more than one role in a smaller organization, but the decision rights should remain explicit.

Enterprise approval owner

Owns the baseline, risk tiers, state vocabulary, enterprise exception criteria, metric dictionary, review cadence, and portfolio register. This role approves changes that affect more than one business unit or weaken a mandatory control.

Business-unit workflow owner

Owns the local workflow outcome, queue, staffing, service targets, local evidence, and adoption. This owner may change local configuration inside the approved boundary and must raise anything outside it.

Specialist control owner

Defines when Finance, Legal, Security, Privacy, Procurement, HR, or another specialist must review a request. The specialist sets acceptance criteria and tests its own route. It does not own the entire workflow.

Platform administrator

Controls environments, permissions, releases, connections, technical monitoring, and recovery. The administrator implements approved policy. Administrator access alone should not grant business authority to approve a purchase or accept a risk.

Assurance owner

Samples decisions, reviews evidence, tests high-risk routes, tracks findings, and checks that teams close corrective work. This owner should have enough independence to challenge both business and platform owners.

Microsoft’s current Center of Excellence guidance similarly separates executive sponsorship, governance leadership, subject-matter expertise, technical administration, change management, and local champions. Its Business Approvals Kit example distinguishes the platform administrator, approval administrator, maker, and approver. That separation offers a useful pattern even when an enterprise uses another workflow system.

Classify workflows into three governance tiers

Do not apply the same review burden to a low-risk office-supply request and a customer-data access decision. Classify each workflow by consequence, not by department prestige.

• Tier 1, local: Routine, reversible decisions with limited value, low data sensitivity, and no enterprise-wide dependency. The business unit owns configuration and periodic self-review under the shared baseline.
• Tier 2, cross-functional: Decisions that require a specialist review, affect more than one team, touch a shared system, or carry meaningful financial, legal, privacy, security, or customer impact. The business unit owns the workflow, and enterprise specialists approve relevant controls and material changes.
• Tier 3, enterprise-critical: Decisions that can create major financial commitments, regulatory exposure, privileged access, broad customer impact, critical-service change, or organization-wide policy exceptions. Enterprise owners approve the design, release, and material changes, while local teams run the queue.

Write the tier triggers as observable facts. “Important workflow” invites argument. “Grants production administrator access” creates a testable rule.

Maintain six artifacts for the approval portfolio

A governance meeting cannot replace durable records. Maintain these six artifacts:

1. Workflow register: identity, owner, tier, version, status, review date, and system location.
2. Control baseline: mandatory states, roles, evidence, exception, change, security, and metric requirements.
3. Authority register: decision types, triggers, approver roles, specialist reviews, delegation, and escalation.
4. Exception register: active exceptions, authority, reason, compensating controls, expiry, and closure evidence.
5. Change and release log: proposed change, tests, approvals, versions, releases, and rollback results.
6. Portfolio scorecard: volume, age, overdue work, returns, exceptions, control failures, and unresolved findings by tier and business unit.

The 2025 GAO Green Book frames internal control around operations, reporting, and compliance, and it expects organizations to document and periodically review their controls. Use that principle here: treat the workflow, its evidence, and its review record as one control system.

See how the model works across four business units

Consider a fictional company with North America, Europe, Professional Services, and Product business units. Each unit handles routine purchases, software purchases, and policy exceptions.

The enterprise baseline requires the same request ID, requester identity, department, decision states, route version, reviewer evidence, exception fields, and outcome codes everywhere. It also requires Security and Privacy review whenever a vendor handles restricted data, regardless of amount or region.

Local owners retain bounded choices:

• North America adds a cost-center field and a regional Finance reviewer.
• Europe adds a data-location question and its approved privacy-review route.
• Professional Services adds a client-contract reference and account-owner notification.
• Product adds a production-access indicator and change-owner review.

All four units report the same enterprise states and clock events. A portfolio owner can compare overdue work and exception rates without pretending that every local route looks identical. A reviewer can also trace any approval back to the baseline, local route, and active version.

Roll out enterprise approval governance in seven steps

1. Inventory live workflows. Find forms, inboxes, spreadsheets, portals, finance routes, HR routes, access requests, and informal exceptions. Record the owner and system before judging quality.
2. Group by decision family. Combine workflows only when they share the same job, evidence, authority, and outcome. Keep materially different intents separate.
3. Assign a risk tier. Use value, reversibility, data, legal duty, access, customer impact, and system dependency as observable triggers.
4. Approve the minimum baseline. Set the seven mandatory elements and name the enterprise owner for each one.
5. Document local boundaries. State what business-unit owners may change without enterprise review and what must escalate.
6. Pilot one decision family. Test one shared contract across two different business units. Include normal approval, return, rejection, absence, override, integration failure, and rule-change cases.
7. Review evidence and expand. Fix the model before adding more workflows. Expand by decision family, not by copying one department’s route across the company.

Run the approval security review on the implemented pilot. Use the enterprise software requirements checklist when the current system cannot enforce the approved model.

Review the portfolio without building a meeting factory

Use a short operating rhythm based on tier and evidence. The cadence below gives a starting point, not a universal control requirement.

• Monthly operations review: Inspect overdue work, returns, failed routes, unresolved exceptions, and owner gaps.
• Quarterly control review: Sample Tier 2 and Tier 3 decisions, test material routes, review access, and close findings.
• Event-driven review: Reassess the workflow after a policy change, reorganization, new integration, data-class change, major incident, control failure, or material threshold change.
• Annual portfolio decision: Retire unused workflows, consolidate true duplicates, renew accepted exceptions, and confirm owners and tiers.

Track trends by workflow age and volume. A new route with ten requests needs different interpretation from a mature route with ten thousand. Do not hide critical control failures inside a favorable average cycle time.

Translate the governance model into Formaloo

Start with the approved specification. Formaloo’s current approval workflow guide uses a request form, admin-only status and Assignee fields, Advanced logic, On submit and On update actions, plus Kanban and Table Data Blocks for review.

Use one shared request form when business units share the same decision facts, states, and evidence rules. Add a department or business-unit field, collect the routing facts, keep decision fields admin-only, and configure the approved conditions in Advanced logic. Give reviewers a Data Block view that matches their role and queue.

Use separate forms when business units need materially different request data or evidence. Keep their workflow IDs, enterprise-state mappings, route versions, and review results in the governance register. Do not claim a cross-form portfolio view until you have verified the reporting design for your workspace.

Formaloo’s Help Center documents multiple-condition rules in Advanced logic and actions that run on submission or record update. Its current Assignee guidance explains how rules assign a form submission to a person or team and labels Assignee as an add-on with Enterprise availability. Confirm plan access, permissions, integrations, and reporting requirements for the deployment before building around them.

If your enterprise needs to turn a shared approval standard into working business-unit workflows, Book a demo.

Use this quarterly governance checklist

• Every live workflow has an owner, tier, active version, and review date.
• Every local route maps to the enterprise state vocabulary.
• Authority and specialist-review triggers match current policy.
• Requesting, approving, administering, and assurance duties remain appropriately separate.
• Exceptions name an owner, reason, expiry, and compensating control.
• Material changes include approval, test evidence, release details, and rollback steps.
• Portfolio metrics use shared event and clock definitions.
• Samples prove the workflow preserved identity, authority, decision, evidence, and version.
• Retired links, rules, and access no longer reach active work.
• Findings have owners, due dates, and verified closure evidence.

Good enterprise approval governance does not drag every decision upward. It gives local teams clear authority, gives enterprise owners reliable evidence, and makes every exception visible before it becomes an inbox tradition.

Sources

• 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: How to assign form submissions to a person or team
• U.S. Government Accountability Office: 2025 Green Book
• NIST SP 800-53 Revision 5.1
• Microsoft Learn: Establish a Power Platform Center of Excellence
• Microsoft Learn: Business Approvals Kit user journey
• GOV.UK Service Manual: Governance principles for agile service delivery
• GOV.UK Service Manual: Running more than one service team

Sources and product guidance reviewed on August 25, 2026.