# Approval policies

> Turn your approval matrix into explicit conditions, responsible positions and controlled routes.

_Updated: 2026-09-12_

An approval policy describes which checks and decisions a request must pass before work may continue.

## Start from the company rule

Name the decision type, legal company, responsible positions, limits, evidence and exception handling. A spreadsheet can be the source for discussion; the published process must express the supported rule precisely.

## Example purchase matrix

| Amount | Illustrative route |
| --- | --- |
| Under $10,000 | Manager |
| $10,000 to $50,000 | Manager → Finance |
| $50,000 to $250,000 | Manager → Finance → CFO |
| Above $250,000 | Manager → Finance → CFO → CEO |

The table illustrates an organization-specific policy. It does not define Railbase's default limits or imply that every reviewer has final approval authority.

## More than an amount

Company, department, purchasing category, risk, delegation and separation of duties may affect the route. Document which conditions are mandatory and who owns an exception.

## From draft to active behaviour

Use [Workflow Studio](/en/learn/railbase-studio) to configure the supported process. Select positions and participants from trusted company sources, resolve missing dependencies and follow the required publication path.

A draft does not silently change running work. Preserve the effective process revision and the policy used for each decision.

## Test the boundary

Use representative requests below and above each limit. Include a missing document, an absent approver, expired delegation, conflicting duties and a returned request. Verify the assigned role, permitted action, visible result and recorded decision.

[Authority and delegation](/en/learn/authority-and-delegation) · [First-process guide](/en/learn/quickstart)
