> ## Documentation Index > Fetch the complete documentation index at: https://help.dash.fi/llms.txt > Use this file to discover all available pages before exploring further. # Policy manager > Build the rules that control whether card requests, vendor changes, and bill payments are automatically actioned or held for review. The Policy Manager is where admins build and maintain the approval rules that govern their organisation's workflows. It's accessible from **Company → Policy**. Each policy is an ordered list of rules. When a request comes in, Dash.fi evaluates the rules top to bottom and applies the first rule whose conditions match. This makes it possible to express nuanced logic — for example, auto-approving requests from administrators while routing all others to a manager for review. ## Policies available The Policy page is organised into three categories: **Spend management controls** * Card request approvals **Vendor management** * Vendor creation approvals * Vendor update approvals **Bill management** * Bill pay approvals Each policy shows an **Active** or **Disabled** status badge. Clicking a policy opens a side panel where you can view, add, edit, and save its rules. ## How rules work Each rule has two parts: * **Conditions** — the criteria that must all be true for this rule to apply. A rule with no conditions matches every request. * **Outcome** — what happens when the rule matches: Approved, Declined, or Requires Approval. Rule order matters. More specific rules must sit above broader fallback rules — a broad rule placed too high will intercept requests intended for a more specific rule below it. ## Rule outcomes | Outcome | What happens | | --------------------- | ----------------------------------------------------------------------- | | **Approved** | The request is automatically approved and actioned without human review | | **Declined** | The request is automatically blocked | | **Requires Approval** | The request is held and sent to the specified approvers | ## The last rule The last rule in every policy is protected — it can't be deleted, and new rules are always inserted above it. It acts as the catch-all: any request that doesn't match an earlier rule is handled by it. Set the last rule's conditions to empty so it genuinely catches everything not handled above. Set its outcome to match your default posture — Approved for permissive defaults, Requires Approval for cautious ones. ## Approvers When a rule's outcome is **Requires Approval**, you specify who receives the request. Approvers can be any combination of: * **User group manager** — the manager of the requesting user's group * **Users** — specific named users * **Groups** — all members of one or more user groups * **Roles** — all users holding a particular role Group and role-based approvers reduce maintenance overhead as your team changes. ## Conditions by policy type ### Card request approvals | Condition | Description | | --------------- | ------------------------------------------------------------- | | User roles | Matches requests from users holding the selected roles | | User groups | Matches requests from users in the selected groups | | Spend limit | Matches by amount: ≤, \<, ≥, or > a threshold | | Spend frequency | Matches by frequency: per day, week, month, year, or lifetime | ### Vendor creation approvals | Condition | Description | | ----------- | --------------------------------------------------------------- | | User roles | Matches creation requests from users holding the selected roles | | User groups | Matches creation requests from users in the selected groups | ### Vendor update approvals | Condition | Description | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Fields changed | Matches updates that include changes to: payment methods, tax ID, name, legal name, address, country, owners, spend category, merchant category, status, external ID, or logo | | User roles | Matches updates submitted by users holding the selected roles | | User groups | Matches updates submitted by users in the selected groups | ### Bill pay approvals | Condition | Description | | ------------ | -------------------------------------------------------------- | | User roles | Matches payment requests from users holding the selected roles | | User groups | Matches payment requests from users in the selected groups | | Total amount | Matches by amount: ≤, \<, ≥, or > a threshold | ## Editing a policy 1. Click a policy to open the side panel 2. Click a rule card to enter edit mode — set conditions and outcome 3. Click **Apply** to stage the changes on that rule (doesn't save yet) 4. Click **Add Rule** to insert a new rule above the last rule 5. To remove a rule, use the delete icon and confirm — the last rule can't be deleted 6. Click **Save policy** to make all changes live 7. Click **Discard** to revert all unsaved changes Changes aren't enforced until you click **Save policy**. ## FAQ Apply commits edits on a single rule card and takes it out of edit mode. Save policy sends the entire updated rule list to the backend and makes it live. You must click Save policy for any changes to take effect. The last rule acts as the catch-all for any request that doesn't match an earlier rule. Removing it would leave some requests with no outcome. It matches every request in that policy — displayed as "All requests" or "All updates." This is the standard configuration for the catch-all last rule. Yes. Multiple conditions within a rule are additive — the request must match all specified conditions for the rule to apply. Yes. When a rule's outcome is Requires Approval, toggle on "User group manager" in the approvers section. This routes the request to the manager of the user group the requester belongs to.