> ## Documentation Index > Fetch the complete documentation index at: https://muveya.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Approval policy > Decide which submitted orders need approval and how many people must approve them, and publish those rules as a new version. The approval policy is your dental clinic's set of rules for orders. Every time an order is submitted, the policy in force turns it into an **approval plan**: the stages it must go through and how many people must approve each one. If no rule applies, the order is approved automatically. This page covers the **Approval policy** screen (`console.muveya.com/approvals/policy`). ## Who can change the policy | What you want to do | Permission you need (label in **Team**) | | - | - | | Open **Approval policy**, read and publish the policy | `approvals.policy.manage` (**Manage approval rules**) | | See and edit value thresholds | `approvals.policy.manage` **and** `orders.value.read` (**View order values**) | These permissions never come with a role: an **Owner** or an **Administrator** also needs them granted. See [Roles and permissions](/docs/en/account/roles-and-permissions). **Where:** open **Order approvals** in the main navigation and select **Approval policy** in the header. The link only appears with `approvals.policy.manage`. Without it, the screen says **You cannot change the approval policy. Ask your clinic's administrator for the permission.** While your dental clinic has no policy, people with this permission see a card on **Home**: **No approval policy yet: submitted orders wait until one is published**. ## What the screen shows The screen is titled **Approval policy**: "Which submitted orders need someone's approval before they are prepared." It has three parts. 1. **The version in force.** A line with the version number, the publication date and who published it. If the version has no rules, it adds **The current policy approves every order without a decision.** If nothing was ever published, you see **No policy yet: submitted orders wait here until one is published.** 2. **No approval required.** A shortcut to publish a policy without rules: "Every submitted order is approved by itself and goes straight to preparation." 3. **Rules.** An editor pre-filled with the rules of the version in force: "An order needs the approvals of every rule it matches. Leave a condition empty to match every order." The console shows only the version in force. There is no screen to browse earlier versions. ## How a rule works A rule is a set of **conditions** (which orders it applies to) and a **requirement** (the stage those orders must pass). ### Conditions All the conditions you set in a rule must be true for the rule to match. A condition you leave empty matches every order. | Field | Matches when | Left empty | | - | - | - | | **Applies to**: **General orders**, **Clinical orders** | The order type is the one ticked. | Tick none, or both, to match both types. | | **Only orders with high-value supplies** | At least one line of the order is a supply marked **High-value supply** in the catalog (the flag copied when the line was added). | Unticked: supplies do not matter. | | **Minimum order value (minor units, for example cents)** | The order value is equal to or greater than this number. | No lower limit. | | **Maximum order value (minor units, for example cents)** | The order value is equal to or less than this number. | No upper limit. | Values are whole numbers in minor units: in a currency with two decimals, `50000` means 500.00; in a currency without decimals, `50000` means 50,000. The order value is the one frozen when the order was submitted (see [Create and track orders](/docs/en/orders/create-and-track#value-and-hidden-data)). An order without a value never matches a rule that has a minimum or a maximum. An order has no value when none of its supplies has a cost. If such an order matches no other rule, it is **approved automatically**. Keep costs up to date in [Costs](/docs/en/catalog/costs), or add a rule without value conditions so every order needs at least one stage. The rule engine also understands a **category** condition (the order has at least one supply from a listed category, as copied when the line was added), but the console does not offer it. If a rule already carries a category condition, or a value threshold you are not allowed to see, the editor keeps it and shows **This rule also has conditions you cannot change here; they are kept.** See [Categories](/docs/en/catalog/categories). Rules cannot express anything else. In particular, there is no condition on the location, the requester, a specific supply, a quantity, a supplier or the date. Every rule applies to every location of the dental clinic. ### Requirement | Field | Meaning | Limits | | - | - | - | | **Stage name** | The name approvers see, for example "Clinic manager". Rules with the same stage name build one single stage. | Required, up to 64 characters. | | **People who must approve** | How many different people must approve this stage. | Whole number from 1 to 10. | The permission an approver needs is not a field: rules created in the console always require `approvals.decide`. Approvers also need access to the order's location, and the requester can never approve their own order. See [Order approvals](/docs/en/orders/approvals). ## How an order is evaluated When a submitted order is processed, the system takes the policy version in force at that moment and: 1. Checks every rule against the order. The order of the rules does not matter. 2. Collects the stage of every rule that matches. 3. Merges rules with the same stage name into one stage that needs the **highest** number of people among them. 4. Builds the plan with the resulting stages, sorted by stage name, and records the policy version used. 5. If the plan has at least one stage, the order moves to **Waiting for approval**. If it has none, the order moves to **Approved**. The order needs the approvals of **every** stage in its plan. One rejection in any stage rejects the whole order. ## Publish rules **Order approvals**, then **Approval policy**. The editor shows the rules of the version in force. Select **Add a rule** to append a rule (**Rule 1**, **Rule 2**, and so on). For each rule, fill **Stage name**, tick the conditions under **Applies to** and **Only orders with high-value supplies**, set **Minimum order value** or **Maximum order value** if you need them, and set **People who must approve** (it starts at 1). Each rule has its own remove button, for example **Remove rule 2**. Select **Publish policy**. The button reads **Publishing…** and then the screen confirms that the new version is now in force. The button is disabled while the editor has no rules; to publish a policy without rules use **Publish without approvals**. Publishing always sends the **whole** rule set shown in the editor as a new version. A rule you removed from the editor is not part of the new version. ## Publish a policy without approvals Use this when your dental clinic does not want approvals at all. It is in the **No approval required** section. The dialog **Publish a policy without approvals?** explains: "From now on no order waits for a decision. You can publish rules again at any time." Select **Publish without approvals**, or **Keep the current policy** to go back. From then on, every submitted order is approved automatically and goes straight to preparation. Orders already waiting for approval keep their plan. ## Versions * Every publication creates a new version with the next number (1, 2, 3...). The server records the publication time and who published it. * A published version is never modified. Changing the policy always means publishing a new version. * Each order keeps the plan it received, including the version number used. Publishing a new version does not re-evaluate orders that are already **Waiting for approval**, **Approved** or further along. * An order is evaluated with the version in force when the system processes its submission, which normally happens seconds after the requester submits it. * If two people publish at the same moment, only one version wins. The other person sees **Someone published the policy a moment ago. Reload it before publishing again.** * When a new version is read, the editor is reset to its rules, so you always edit what is in force. ### Before the first policy A dental clinic without any published policy approves nothing: submitted orders stay in **Submitted**. Publishing the first policy (with rules, or without approvals) unblocks them. Orders that were already waiting are picked up the next time the system processes submissions for your dental clinic, which happens each time an order is submitted. If an order still shows **Submitted** a while after you publish, write to [team@muveya.com](mailto:team@muveya.com). ## Worked example A dental clinic that works in a currency with two decimals publishes three rules: | Rule | Stage name | Applies to | High-value supplies | Minimum value | People who must approve | | - | - | - | - | - | - | | 1 | Clinic manager | (none ticked) | No | (empty) | 1 | | 2 | Finance | (none ticked) | No | `50000` | 1 | | 3 | Clinic manager | **Clinical orders** | Yes | (empty) | 2 | Rule 1 matches every order. Rule 2 matches orders of 500.00 or more. Rule 3 matches clinical orders with at least one high-value supply, and because it shares the stage name with rule 1, the two merge into one stage that needs 2 people. | Order | Type | Value | High-value supply | Rules matched | Plan | | - | - | - | - | - | - | | `#101` | General | 120.00 | No | 1 | Clinic manager (1) | | `#102` | General | 800.00 | No | 1, 2 | Clinic manager (1), Finance (1) | | `#103` | Clinical | 300.00 | Yes | 1, 3 | Clinic manager (2) | | `#104` | Clinical | 650.00 | Yes | 1, 2, 3 | Clinic manager (2), Finance (1) | | `#105` | General | No value | No | 1 | Clinic manager (1) | Order `#104` needs two different people for **Clinic manager** and one for **Finance**; none of them can be its requester. Order `#105` has no costed supply, so rule 2 cannot match it; without rule 1 it would have been approved automatically. ## Validation and limits | Check | Message | | - | - | | **Stage name** is empty | **Name the stage.** | | **Stage name** is longer than 64 characters | **The stage name can have up to 64 characters.** | | **People who must approve** is not a whole number from 1 to 10 | **Enter a whole number from 1 to 10.** | | A value is not a whole number of zero or more | **Enter a whole number of zero or more.** | | **Minimum order value** is greater than **Maximum order value** | **The minimum cannot be greater than the maximum.** | A policy holds at most 100 rules. Spaces at the start and end of a stage name are removed. ## What can go wrong | Message | Code | Why | What to do | | - | - | - | - | | **You cannot change the approval policy. Ask your clinic's administrator for the permission.** | | You lack `approvals.policy.manage`. | Ask a member manager for **Manage approval rules**. | | **Someone published the policy a moment ago. Reload it before publishing again.** | `approvals.policy_version_conflict` | Another person published at the same time. | Reload the page, review the new version and publish again if needed. | | **Review the entered values before trying again.** | `common.invalid_request` | The server refused a rule (for example, a minimum above the maximum). | Fix the rule. | | **Your account does not have permission for this action.** | `common.forbidden` | The permission was removed while you were editing. | Ask for the permission again. | ## The policy outside the console The policy can only be published in the console. The MCP resource `muveya://tenant/approval-policy-summary` is meant to give a read-only summary of the version in force, but it needs `approvals.decide`, which the current read-only OAuth scope set does not grant, so it always answers `common.forbidden`. See [MCP resources](/docs/en/mcp/resources). ## Related pages How approvers decide the stages of a plan. Order types, values and statuses. The costs behind order values and value thresholds. How supplies are grouped in the catalog. Who can manage the policy and who can decide. The vocabulary of orders and approvals. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.