> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nyumbazetu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Approvals

> Route high-impact actions for sign-off, work the approvals inbox, and understand what you can decide.

**Approvals → `/approvals`**

Some actions are deliberately not granted to one person end to end. Instead of firing directly they
create an **approval request**, and someone with the right authority decides. The decision, the
decider and the reason are recorded on the underlying record.

## What routes for approval

| Area               | Typical routed actions                                                                                |
| ------------------ | ----------------------------------------------------------------------------------------------------- |
| **Receivables**    | Issuing an invoice above a threshold; credit notes and write-offs.                                    |
| **Payables**       | Paying an expense.                                                                                    |
| **Collections**    | Issuing a demand letter, handover, fee waiver, hardship restructure, closing a case with a write-off. |
| **Communications** | Publishing a message template or broadcast.                                                           |
| **Operations**     | Activating schedules and other material configuration changes.                                        |

Low-impact confirmations — sending a single reminder on a case you are assigned — stay one-click
actions. The distinction is deliberate: routing everything through approvals makes approval
meaningless.

## The approvals inbox

| Column                            | Meaning                               |
| --------------------------------- | ------------------------------------- |
| **Request title**                 | What is being asked for.              |
| **Module**                        | Which part of the platform raised it. |
| **Entity type**                   | The kind of record involved.          |
| **Action type**                   | What will happen on approval.         |
| **Applicant / customer**          | The party affected.                   |
| **Amount**                        | The money at stake, where relevant.   |
| **Branch / block / unit / lease** | Where it applies.                     |
| **Requested by / requested at**   | Who asked, and when.                  |
| **Risk**                          | The assessed risk of the action.      |
| **SLA / age**                     | How long it has been waiting.         |
| **Status**                        | Pending, approved, rejected.          |

Filter by module, entity type, action type and status to work one kind of decision at a time —
approving twenty expenses in a row is faster and more consistent than context-switching.

## Deciding

<Steps>
  <Step title="Open the review">
    **Open Review** shows the request in context, including a preview of what will be sent or
    posted where the action produces a document or a message.
  </Step>

  <Step title="Check the substance, not just the amount">
    For an expense: is it attributed to the right unit, with the vendor's invoice attached? For a
    demand letter: are the figures and the tenant's details right?
  </Step>

  <Step title="Approve or reject">
    Rejection requires a reason. Write it for the person who has to act on it.
  </Step>

  <Step title="Confirm the outcome">
    Approval triggers the action. Check the underlying record shows it happened.
  </Step>
</Steps>

<Note>
  The actions available to you on a request are **computed by the server**, not by the browser. The
  buttons you can see are the buttons you may actually use — if an approve button is absent, you do
  not hold that authority for that request.
</Note>

## What happens on a decision

| Decision     | Effect                                                                                                     |
| ------------ | ---------------------------------------------------------------------------------------------------------- |
| **Approved** | The staged action executes — the invoice issues, the letter is sent, the expense is paid, the case closes. |
| **Rejected** | The staged action is marked skipped with the reason, recorded on the record's timeline.                    |

Because the action is *staged* rather than duplicated, there is no risk of the action happening
twice or of an approved action being forgotten.

## Delegation and policy

Approval policies define what routes where, and delegation covers absence. Both are administrator
configuration — a manager on leave with no delegate is the most common cause of a stalled approval
queue.

## Working the queue well

<Steps>
  <Step title="Work by SLA, not by date">
    The age column exists so the oldest request does not quietly become the most urgent.
  </Step>

  <Step title="Batch by type">
    All expenses, then all credit notes. Consistency of judgement improves markedly.
  </Step>

  <Step title="Reject with substance">
    "Rejected" with no reason produces a resubmission of exactly the same request.
  </Step>

  <Step title="Watch the volume">
    A rising approval queue usually means a threshold is set too low, not that the team is
    misbehaving.
  </Step>
</Steps>

## Audit

Every approval decision is recorded: who decided, when, what they decided and why. Combined with
the [activity log](/guides/activity-log), this is what makes separation of duties demonstrable
rather than merely intended.

## Common problems

| Symptom                                | Cause                                                                    |
| -------------------------------------- | ------------------------------------------------------------------------ |
| Request stuck pending                  | No approver available, or no delegate configured for an absent approver. |
| Approver cannot see the approve button | They do not hold the required role for that request type.                |
| Action did not happen after approval   | Check the underlying record's timeline for a failure after approval.     |
| Everything routes for approval         | The policy threshold is set too low.                                     |