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

# Lease applications

> Take an applicant from public form to activated lease — inbox, checklists, review, decision and activation.

**Operations → Applications → `/applications`**

Applications is the intake pipeline: a prospective tenant applies, you collect documents, run
checks, decide, and — on approval — the application is **activated** into a real lease. It is a
workflow module, not a form: the same application moves through stages with an owner, a checklist
and a timeline.

## The pages

| Page                 | Route                                  | Purpose                                                            |
| -------------------- | -------------------------------------- | ------------------------------------------------------------------ |
| **Overview**         | `/applications/overview`               | Pipeline health: volume, stage distribution, ageing, conversion.   |
| **My work**          | `/applications/inbox`                  | Your assigned queue, with KPI badges and queue views.              |
| **All Applications** | `/applications/dashboard`              | Every application, filterable.                                     |
| **Review**           | `/applications/review`                 | The review workspace for applications awaiting a decision.         |
| **Activations**      | `/applications/activation`             | Approved applications waiting to become leases, and their outcome. |
| **Import**           | `/applications/bulk-import`            | Bulk intake from a spreadsheet.                                    |
| **Issues**           | `/applications/integration-exceptions` | Integration exceptions with a detail panel and resolution actions. |
| **Settings**         | `/applications/settings`               | Checklist templates and module configuration.                      |

## Statuses

| Status        | Meaning                                                   |
| ------------- | --------------------------------------------------------- |
| **Draft**     | Started, not submitted.                                   |
| **Submitted** | Received and awaiting triage.                             |
| **Pending**   | In progress — information or documents outstanding.       |
| **Approved**  | Decision made in the applicant's favour; not yet a lease. |
| **Rejected**  | Declined, with a reason.                                  |
| **Activated** | Converted into a live lease.                              |
| **Cancelled** | Withdrawn or abandoned.                                   |

<Warning>
  **Approved is not activated.** An approved application has a decision but no lease. Activation is a
  separate, deliberate step — which is why the Activations page exists.
</Warning>

## How applications arrive

| Route                            | Description                                                                       |
| -------------------------------- | --------------------------------------------------------------------------------- |
| **Public apply form** (`/apply`) | Prospective tenants submit directly; submissions land in the inbox.               |
| **Created in-app**               | Staff capture an application on behalf of a walk-in applicant.                    |
| **Bulk import**                  | A batch of applicants imported from a spreadsheet, typically at scheme launch.    |
| **Integration**                  | Applications received from an external system. Failures surface under **Issues**. |

## The application workspace

Opening an application gives you a working record with:

| Section        | Contents                                                                      |
| -------------- | ----------------------------------------------------------------------------- |
| **Overview**   | Applicant summary, requested unit, dates, and the next step.                  |
| **Parties**    | Applicant, co-applicants, guarantors and next of kin.                         |
| **Documents**  | Uploaded ID, payslips, references — with upload actions.                      |
| **Checklist**  | The stage-gating list: what must be done before the application can progress. |
| **Decisions**  | The decision record and its reasoning.                                        |
| **Assignment** | Who owns this application, with an assign action.                             |
| **Timeline**   | Everything that has happened, in order.                                       |
| **Notes**      | Working notes for whoever picks it up next.                                   |
| **Blockers**   | What is currently preventing progress.                                        |

The **next step panel** tells the assignee what to do now rather than leaving them to infer it from
the checklist.

## Checklists

Checklists gate progress. A checklist template defines the items required at each stage — ID copy
uploaded, employer reference received, deposit paid — and an application cannot advance until its
items are satisfied.

Templates are configured under **Settings**, so requirements can differ between schemes without
code changes. Editing a template does not retroactively change applications already in flight.

<Tip>
  Use **refresh checklist** on an application after changing a template if you deliberately want the
  in-flight application re-evaluated against the new requirements.
</Tip>

## Reviewing and deciding

<Steps>
  <Step title="Triage from the inbox">
    Assign the application to an owner. Unassigned applications are the ones that go stale.
  </Step>

  <Step title="Work the checklist">
    Collect documents and complete checks. The blockers card tells you what is missing.
  </Step>

  <Step title="Screen the applicant">
    Record background and reference checks on the resident record — see
    [Residents](/guides/residents).
  </Step>

  <Step title="Decide">
    Approve or reject with a reason. The decision is recorded on the timeline.
  </Step>
</Steps>

## Activation

Activation turns an approved application into an operational tenancy. Depending on the scheme it
creates or attaches the resident, creates or activates the lease, and applies the agreed terms.

Activation touches several systems, so it is designed to be **resumable**: if a step fails
part-way, the process can be resumed rather than restarted, and the Activations page shows what
completed and what did not.

<Warning>
  If an activation reports a partial failure, resume it from the Activations page. Do not create the
  lease manually as well — that produces two tenancies for one applicant.
</Warning>

For ownership schemes, activation produces a TPS contract rather than a rental lease. See
[Ownership plans](/guides/tps/overview).

## Issues (integration exceptions)

Applications arriving from an external system can fail validation or mapping. Each failure appears
under **Issues** with a detail panel explaining what went wrong and a resolution action. Clearing
this queue regularly is what stops silent intake loss.

## Overview metrics

The overview page answers the questions a manager asks weekly:

* How many applications came in, and from where?
* Where are they stuck?
* How old is the oldest one in each stage?
* What proportion convert to activated leases?

## Common problems

| Symptom                                           | Cause and fix                                                                                |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Application approved but no lease exists          | Approved ≠ activated. Run activation.                                                        |
| Applicant says they applied; nothing in the inbox | Check **Issues** for an integration exception, and confirm the public form's branch routing. |
| Checklist will not complete                       | An item's document is missing or was uploaded against the wrong party.                       |
| Duplicate applications from one applicant         | Submitted twice on the public form. Cancel one, and note the reason on the survivor.         |

## Next steps

<Columns cols={2}>
  <Card title="Residents" icon="users" href="/guides/residents">
    The person record an application produces.
  </Card>

  <Card title="Managing leases" icon="file-signature" href="/guides/managing-leases">
    What activation creates.
  </Card>

  <Card title="Assessments" icon="clipboard-check" href="/guides/assessments">
    Structured profiling questionnaires used alongside intake.
  </Card>

  <Card title="Ownership plans" icon="key" href="/guides/tps/overview">
    Activation into a TPS contract.
  </Card>
</Columns>