Approval Policies

Summary

Approval policies define when a sensitive action needs sign-off and who must approve it. They are separate from the day-to-day Approvals queue.

Use Settings → Approvals to define the control. Use Workflows → Approvals to review a request that matched the control.

Capabilities

What an Approval Policy Controls

Each policy applies to one action type. The policy can define:

• a threshold amount
• a currency
• one or more ordered approval steps
• an approver role for each step
• specific named approvers
• the minimum number of distinct approvals for each step
• whether the policy is enabled

Approval policies can protect sensitive work such as invoice write-offs, payment settlements, invoice cancellation, workflow actions, and Assistant actions when the selected action type supports them.

Prerequisites

Access

Workspace owners can create, edit, enable, and disable approval policies. Other members can browse the policies when their access allows it, but the server rejects unauthorized changes.

Keep at least two workspace owners when approval governance is business-critical. A policy that depends on one unavailable person can delay operations.

Concepts

Threshold and Currency

The threshold determines when the policy applies.

• No threshold means the policy can apply at any amount.
• A threshold means the action must meet or exceed that amount.
• A currency narrows the monetary control to that currency.
• No currency avoids a currency-specific threshold.

Check the source action's amount and currency before you assume that a policy should have matched.

Approval Steps

Steps run in order. A later step does not begin until the earlier step has enough distinct approvals.

Each step can use:

• Any member
• a supported workspace role
• one or more Specific approvers
• Min approvals of one or more

Any rejection halts the request.

Build a satisfiable step

The minimum approvals cannot be greater than the number of eligible named approvers. For example, a step that requires two approvals but names only one person can never complete.

When you use a role, make sure the workspace has enough active members with that role. The settings page warns about a role or named-approver rule that cannot satisfy its minimum.

Multiple Steps

Use multiple steps when one group must review before another group.

Example:

1. A finance member confirms the record and amount.
2. An owner gives final approval.

Do not create many steps only to record awareness. Use comments, notifications, or review notes when a person does not need decision authority.

Workflow

Create a Policy

1. Open Settings → Approvals.
2. Select New policy.
3. Choose the Action type.
4. Enter Threshold amount, or leave it empty for any amount.
5. Choose a Currency, or choose No currency when the action is not currency-specific.
6. Configure the first approval step.
7. Add more steps when approval must happen in sequence.
8. Select Save policy.
9. Confirm that the policy appears under Approval Chains.
10. Confirm whether it is enabled.

The action type cannot be changed after the policy is created. Create a new policy when a different action type needs the same chain.

Enable, Disable, and Edit

• Disable a policy when the control must stop matching new work temporarily.
• Edit thresholds, currency, and steps when governance changes.
• Create a new policy when the action type changes.

After you change a policy, test it with a representative low-risk action. Confirm that the request reaches the correct queue and that every approval step behaves as expected.

A policy change does not necessarily rewrite the state of requests that already entered the queue.

Behavior specification

Approval Queue Behavior

When an action matches an enabled policy, the request appears in Approvals with its action and context.

An operator can:

• claim the request
• inspect the amount, customer, invoice, workflow, or Assistant context
• approve or reject when eligible
• follow execution after approval
• use undo when the completed action supports it

Approval and execution are separate states. An approved request can still be executing, fail during execution, or complete later.

Diagrams

Rendering diagram…

Screenshots

Approval policies for invoice write-offs and settlement offers, including thresholds and review steps.

Shown with synthetic data in a local workspace.

Verification

Governance Checklist

Before you enable a policy, confirm:

• the action type is correct
• the threshold and currency match the intended risk boundary
• every step has enough eligible approvers
• the order matches the real operating process
• the backup approvers are active
• the team knows where to review requests
• the first test request completed as expected

Review approval policies when roles, team membership, payment authority, or finance procedures change.

Troubleshoot

Save policy is disabled

Check each step. A minimum approval count can exceed the number of named approvers, or a required field can be incomplete.

A request did not enter Approvals

Confirm that the policy is enabled, the action type matches, and the amount meets the threshold in the selected currency. Also confirm that the action supports approval policies.

A request cannot advance

Check the active step, required role, named approvers, and minimum approval count. A rejection stops the request.

A non-owner can see the policy but cannot edit it

Browsing and management are separate permissions. Ask a workspace owner to make the change.

An approved request did not finish

Open the request and check whether it is Executing, Done, or Failed. Approval allows execution. It does not guarantee that the downstream action succeeds.

1. Create a test policy for a specific action with threshold and multi-step approvals. Expect policy to appear under Approval Chains and be enabled.
2. Perform an action that matches the policy. Expect the request to appear in the Approvals queue.
3. Approve a request at each step only if sufficient eligible approvers are active. Expect subsequent steps to unlock as prior steps complete.
4. Attempt to approve with fewer than the minimum required or by an ineligible user. Expect request to remain pending or blocked.
5. Disable the policy, then perform a matching action. Expect no approval to be required.
6. Edit threshold/steps in an enabled policy and repeat checks to ensure new rules apply.
7. Review the Approvals queue as a non-owner. Expect browsing access only, with management options restricted.
8. Attempt to progress a request post-approval during known system downtime or simulate approval for an unsupported action. Expect status to remain at Executing, Failed, or Done as per execution outcome.
9. For troubleshooting, intentionally misconfigure a step (e.g. set minimum approvals higher than eligible approvers) and expect Save policy to be disabled or the step flagged for correction.
10. Monitor completed requests to verify approval flows worked as intended compared to the policy design.

Related

Related Pages

• Configure Approval Policies
• Inbox and Approvals
• Assistant Automation
• Workflow Executions
• Security and Access