> ## Documentation Index > Fetch the complete documentation index at: https://docs.xenora.ai/llms.txt > Use this file to discover all available pages before exploring further. # Approval Processes > Who signs off on a case, and in what order — after every document is verified. > [!NOTE] > > Approval processes are available on the **Business** plan and above, alongside Custom Templates. Find them under **Workflows** in the sidebar. **My Approvals** is open to every approver, whatever their role. A **flow** decides *what documents* a case collects. An **approval process** decides *who signs off* once they are all verified — the manager, the credit head, the partner — and in what order. Attach one to a case, or none: without a process the case completes the moment the last document is verified, exactly as before. ## Two things you pick when creating a case > **Flow or custom template** > > The document checklist. Unchanged. > **Approval process** > > **None** (default), a built-in process, or one your team built. Each level gets a person — or an approver group — and you can save that mapping as the default for the flow so the next case is one click. If the person creating the case is also picked as an approver, Xenora stops you and asks you to choose someone else — nobody approves their own case. ### Adding a process to a case that already exists Forgot to pick one, or decided later that a case needs sign-off? Open the case and use **Add approval process**. It works on any open case that does not have one yet. Pick the process, choose who handles each level, and attach it. ### Recurring cases If a flow runs on a schedule, each new case it creates automatically gets the flow's **default** approval process, with the same people you saved for it. ## How a case moves **1. Documents are collected and verified** Same as today: the client uploads, your team **verifies** each document. (We now say *verified* for documents, so it never blurs with *approved* for the case.) **2. The process starts — the case is In approval** Level 1 activates and its owner is emailed the details. Approvals always happen in Xenora — sign in and open **My Approvals**. The case's *Assigned to* follows whoever holds the current level. **3. Each level approves — or returns the case** Approving moves it to the next level. You can add a comment when you approve. Returning sends it **back to the submitter** (the person who was collecting) with a reason; they fix, verify, and **Resubmit**, and the case resumes at that level (or from level 1, if the process is set to restart). Everyone who already decided a level is kept in the loop. **4. The last level approves — the case completes** The client is told the outcome. The case **timeline** holds the full audit trail: every level activation, decision, comment, return and resubmission, with who did it and when. > [!NOTE] > > While an approval process is running, the case can't be marked **Complete** by hand. It completes on its own when the last level approves. ## Return, decline or withdraw — what is the difference? | Action | Who | What happens | | - | - | - | | **Return** | The person deciding the current level | The case goes back to the submitter with your reason. Nothing is lost — they fix it and resubmit. | | **Decline** | The person deciding the current level | A final **no**. The case is cancelled, document collection stops, and the client is told the outcome. You must give a reason. | | **Withdraw** | The submitter (or an Admin) | Pulls the case out of approval and cancels it — for example, when the client no longer needs it. | > [!TIP] > > **Return** is for your team only. If the problem is with a client's file — wrong document, blurry scan — reject that **document** instead. The client is asked for a new one, and the case is returned automatically. ### Reopening a finished case If a case that was approved, declined or withdrawn is **reopened**, its approval process is reset. Once every document is verified, the submitter clicks **Submit for approval** and the process runs again from level 1. ## Built-in processes | Process | Levels | | - | - | | Simple sign-off | Approval | | Expense approval | Manager approval → Finance approval → Reimbursement | | Loan processing completion | Manual check → Credit approval → Disbursement | | Audit completion | Manager review → Partner sign-off → Report issued | | Filing sign-off | Senior review → Partner sign-off → Filed | They are copied into your workspace the first time you open **Approval Processes**, so you can edit them freely. ## Building your own **Workflows → Approval Processes → New process.** Give it a name and a short description of when to use it. Then add levels — as many as you need — and drag them into order with the up/down arrows. For each level: * **Name, role and default owner** — a team member, an **approver group**, or "pick on each case". * **Days to act** — the owner is reminded from the day before it is due; once it is more than two days late, the submitter and case creator are pulled in. * **Button label** — "Approve", "Mark done", "Mark disbursed". Process-wide: **separation of duties** (on by default: the submitter can't approve any level of their own case, and each level needs a different person), **strict assignment** (below), and **what happens on resubmit** (resume at the level that returned it, or start again from level 1 — pick the latter for lending and audit, where a changed document invalidates earlier sign-offs). ### Managing your processes * **Active / Inactive** — switch a process to *Inactive* to stop it being picked for new cases. Cases already using it carry on. * **Default for a flow** — the list shows which flows use each process as their default. * **Delete** — a process can't be deleted while a flow still uses it as its default. Change the flow's default first. ## Approver groups **Workflows → Approver Groups.** Create a group (for example, "Credit approvers"), add team members to it, and use it as the owner of a level. Team members must be invited under **Settings → Team** first. A level owned by a group is offered to every member. Choose how the group decides: * **Any one member** — the first to act takes it. A member can **Claim** the level to show they are handling it, or just approve, which claims it too. Changed your mind? **Release** it back to the group. * **Every member must approve** — the level moves on only when all members have approved. The case shows who has approved so far and who is still pending. Any one member can return it. Editing a group doesn't change cases that are already in approval — they keep the members they were offered. ## Your queue and your inbox * **My Approvals** — your queue, with everything waiting on your sign-off on one screen. Two tabs: **Awaiting me** and **Returned to me**, oldest first. Approve straight from a row, tick several and approve them together (with one shared comment), or return one with a reason. If some cases in a bulk approval can't go through — say, a colleague already decided one — the rest are still approved and Xenora tells you which ones failed and why. Keyboard: `j`/`k` to move, `x` to select, `a` to approve, `enter` to open. On a phone, the queue shows as easy-to-tap cards. * **All Cases → Awaiting my approval / Returned to me** — the same two filters on the full case list, when you want them next to everything else. * **Dashboard** — an **In approval** tile shows how many cases are in approval, how many are waiting on you, and how many were returned to you. * **Emails** — you get an email when a level lands on you, when a case is returned or resubmitted, and when a level is running late. Emails notify you of the details only; you sign in to Xenora to act, so an approval is never made from an inbox. If an email can't be delivered, the case timeline records it, so nobody waits on someone who was never told. * **Out of office** — send your approvals to a colleague for a date range (Approval Processes → *Out of office*). Leave the dates empty to start now and keep it on until you remove it. If your stand-in is someone who isn't allowed to approve that case (for example, its submitter), the level stays with you. ## Reminders for late or stuck cases * **Late approvals** — the level owner is reminded from the day before the level is due. Once it is more than two days late, the submitter and case creator are also told. * **Returned cases** — if a returned case sits with the submitter for three days without being resubmitted, they get a reminder. * **Someone leaves the team** — if the owner of a level is removed from your workspace, the level is handed back to the submitter so they can pick someone else. Nothing gets stuck. ## Reassigning a level Need someone else to handle a level? Use **Reassign** on the case and pick a team member. The level owner, the submitter, the case creator and Admins can reassign. Xenora won't let you reassign to someone who isn't allowed to approve that case — for example, the submitter or someone who already approved an earlier level. Every reassignment is recorded on the timeline. ## Stepping in for a colleague By default, level ownership is a *default*, not a lock. If a level is assigned to someone else, an Editor or Admin can still decide it — the app first asks **"This level is assigned to Priya. Approve on their behalf?"**, and the decision is recorded as *you*, stepping in for them, on the level and in the timeline. ### Strict assignment Turn **Strict assignment** on for a process and that door closes: only the assigned person — or a member of the assigned group — can decide a level. Nobody else, Admins included, and no confirmation opens it. The card shows a **Strict** badge, and the way to let someone else act is to **reassign** the level, which is recorded on the timeline. > [!TIP] > > Use strict assignment where the identity of the approver is the control — a credit sanction, a partner sign-off. Leave it off where cases must keep moving when someone is on leave (the out-of-office delegation covers planned absences either way). > [!NOTE] > > Separation of duties is **not** overridable: if the process enforces it, the submitter cannot approve any level, and nobody can decide more than one level — no matter who they are. A **Read User** who is an approver can only act on levels assigned to them. ## Skipping a level An **Admin** can **Skip** a level when it genuinely isn't needed on a case. A reason is required, and the skip is recorded on the timeline. The case then moves to the next level. ## What the case shows The **Approval process** card on each case shows every level as a step, with: * **Status** — waiting to start, your turn, unclaimed, approved / done, skipped, returned. * **Who it is waiting on** and when it is due ("due in 2 days", "overdue by 1 day"). * **Who decided** each level and when, including *covering for* (out of office) and *stepped in for* (on someone's behalf). * The overall result once finished — **Completed**, **Declined**, **Withdrawn** or **Cancelled**. ## Who can do what Acting on your own level is granted by **being assigned to it** — or being in its group — not by role, so a Read User who is made an approver can approve. Editors build processes and groups, attach processes to cases, and can step in on a colleague's level; Admins can additionally **skip** a level. > [!NOTE] > > If your subscription lapses, you can still see cases and their approvals, but nobody can approve, return or attach a process until it is renewed. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.