--- title: "Approvals & delegation of authority" summary: "How governed decisions route to the right signer, what the approvals drawer asks for, and how the authority matrix is set." updated: "2026-10-07" section: "Everyday work" url: "https://zovos.ai/docs-approvals.html" --- # Approvals & delegation of authority Almost nothing important in Zovos takes effect because someone clicked save. Policies, finding closures, risk acceptances, vendor onboardings, monitoring workpapers, audit reports, board minutes and model approvals all become authoritative only when a second person signs them. This article explains how that routing works and what you will see when a decision reaches you. ## The approvals drawer Every governed decision lands in one queue, opened from the topbar pill or from the Dashboard's approvals panel. The drawer is titled **Approvals queue**. The items awaiting your sign-off come first, counted in the header. Below them, under **In the queue**, sit the other pending items you are allowed to see but cannot sign. Each of those says why, for example that you submitted it or that the delegation-of-authority matrix routes it to another role. The topbar pill counts only the first group. It loads a page at a time and says so as soon as a page comes back full, with a control to widen the window, so a long queue is never quietly truncated. Each item carries: - A **change preview** shows the specific diff you are signing, not a summary of it. - An effect sentence in plain language makes the button say what will happen. A policy reads **Approve & publish**. A finding closure reads **Approve closure**. A vendor reads **Approve & onboard**. A monitoring review reads **Sign off workpaper**. - A return path that is not a rejection lets you send the item back. It is usually **Request changes**, which sends the item back to its author with your reasons. - A **rationale field, which is required**. Every affirmative and every return is recorded with the words you typed. - Where the record has a screen of its own, an **Open** link takes you to it. For a board meeting, it opens that meeting's detail. If you submitted the item yourself, the drawer says so and gives you no decision buttons. You submitted it, so it is not yours to approve. ## How routing is decided Routing comes from the **delegation-of-authority matrix**, which lives in Governance settings and is editable by your workspace owner. Each cell in the matrix pairs an object type with a severity and names two things. The first is which roles may sign, and the second is how many distinct signers are required. The defaults follow the way a bank or credit union already delegates authority: - **Critical items require two distinct signers.** This four-eyes rule draws the signers from your owner and risk-approver roles. - **High, medium and low items require one signer.** A high item goes to the owner role by default, and a medium or low item to the owner or risk-approver role. - **Policies route by document tier.** A policy goes to the board. A standard, procedure or guideline goes to a single management signer from the owner role. - **The internal audit plan always goes to the audit committee.** That holds regardless of how the rest of the matrix is set. Changing the matrix is itself an audited change, and each cell must name at least one role and a signer count before it can be saved. ## When you are the only person who can sign Small teams hit a real problem. Sometimes nobody else in the institution holds the permission a decision requires. Zovos does not block the work or pretend a second person existed. It offers an audited **sole-operator override** instead. The drawer asks for a justification in addition to the rationale, the decision proceeds, and the audit row is tagged as a sole-operator action so an examiner sees exactly what happened and why. ## The Authority Engine Above the matrix sits the Authority Engine, which checks at decision time whether the person deciding was actually delegated that authority. That check includes delegations with an expiry. It runs in one of three modes, which are **Off**, **Monitor**, and **Enforce**. Monitor is the default. Every decision is checked and recorded but never blocked, so you can read the authority exceptions report for a few cycles before turning enforcement on. In Enforce mode a decision outside someone's delegation is stamped and not applied, unless the signer supplies a justification. Beside the clean result of within authority, the authority exceptions report records five outcomes: - **Escalated.** The decision exceeded the signer's authority, and the row names the nearest role that does cover it. - **Lapsed authority.** A delegation existed, but it had expired. - **Blocked ยท no grant.** No covering delegation existed at all. - **Break-glass override.** The signer supplied a justification and the decision proceeded. It is filed as an authority exception for ratification afterwards. It answers the same community-bank reality as the sole-operator override, and it is recorded just as visibly. - **Monitor-flagged.** This is what Monitor mode records. The decision proceeded, and the row says what enforcement would have done instead. ## What happens after you sign An affirmative decision does three things at once. It applies the change. It writes the decision, signer and rationale to the [audit trail](docs-audit-trail.html). It also appends a hash-chained row to the proof ledger. That ledger row is what lets you prove, months later, that the approval existed in that form on that date. ## Notes and limits Approvals are deliberately not automatable. Zovos publishes a Zapier app and supports Make and n8n, but no governance decision is exposed to them. You can automate opening a finding, but you cannot automate signing one. Approvals are never assignable to a named individual. Sometimes a decision is stuck because the role it is waiting on cannot act. In that case you can **Reassign** it from the drawer. That retags the waiting signer slot with a different required *role*, and it requires a rationale that goes on the record. The picker offers only live roles that hold the permission the decision needs, and never the reserved examiner role, so a reassignment cannot park an item on a role with no authority to sign it. Reassigning is an administrative act gated on settings permissions instead of on the permission to approve. That keeps unsticking a queue and deciding an item in separate hands. A reassignment you keep having to make is still a signal to fix the delegation-of-authority matrix in Governance settings, which is the record an examiner will read anyway. Roles and what each one can approve are covered in [Roles & permissions](docs-roles-permissions.html).