Skip to main content
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.
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?

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

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.
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).
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.
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.