Admin console

Administration → Control Center → /admin

Every other page in Nyumba Zetu is scoped to your organisation and branch. The control center is not: it reads across the whole platform, in one list, with no branch or unit picker. It exists to answer operational questions that stop at no single tenant — did that job run everywhere?, who has admin anywhere?, which submissions are stuck?

The three sections

Operations

Every run-log the platform produces, in one place.

The useful pattern here is absence, not error. A job that failed is visible in its own module. A job that never ran for one organisation out of a hundred is only visible from a platform-wide list.

Integration jobs

The submission queue that carries documents to external providers. A job that keeps retrying is usually a credential or mapping problem at the organisation level rather than a transient outage — check the failure reason before requeuing, and fix the mapping rather than the job.

Audit & security

Auth events

Sign-in outcomes across the platform. Read it for patterns, not individual lines: repeated failures against one account, successful sign-ins from an unexpected location, or a burst of revocations.

Impersonation

Support work sometimes needs an operator to see exactly what a user sees. Every such session is recorded with its operator, its target workspace, its stated reason and its duration. Impersonation is a normal support tool; an impersonation session with no reason, or one that runs unusually long, is the thing to ask about.

Role grants

Review it on a cadence. A grant with no current owner — someone who has left, or a temporary escalation never withdrawn — is the most common finding.

Configuration

Overrides are where unexplained behaviour usually hides: a value set at branch or unit scope years ago that still wins over the organisation default. The override list shows the scope chain resolved, so you can see which level actually applies.

The platform directory

Two cross-tenant registers, for the whole platform rather than one organisation:

Filter by live, dormant or no units, search by name, sort by size or recency, and switch between cards and a table. A company links to its properties and a property links back to its company, so you can walk the tree either way.

Opening one shows its metrics — properties, blocks, units, occupancy and tenancies — and its identity and contact details.

Clients — who we are not billing

/admin/clients answers one question: which organisations on the platform are we actually invoicing, and which have fallen through. Four counts lead the page and the table follows whichever one you press.

The last two are both "not a client yet", and they are kept apart deliberately because the work each one needs is different.

Vendor links — which rows are one company

/admin/vendor-links records that several vendor rows are the same real company. A utility named separately under every property it serves is the common case: one supplier appearing as dozens of unconnected rows that no spend report can add together.

Linking records the relationship. It does not merge the rows or move their history — each keeps the expenses filed against it. See Vendors for scoping a vendor to the organisation so new spend lands on one record going forward.

The bank registry

Both surfaces are restricted to platform staff. An organisation administrator who reaches these routes is refused by the server, so use Bank accounts for anything tenant-scoped.

Standing a client or property down

When a client leaves, deactivate them rather than deleting them. Deactivate is on the record's drawer, and the archive lives at /deactivated.

1. See what it covers

   Before anything changes, you are shown the counts — properties, units, tenancies, schedules and staff — and any warnings, such as money still owed or tenancies still live.

2. Give a reason and a date

   The reason comes from a fixed list; some reasons require a note. The date they stopped is often earlier than today, and it is the date reports will use.

3. Confirm by typing the name

   Then the record and everything under it is hidden from live lists.

What deactivation does and does not do:

• Nothing is destroyed. The record and its history stay readable in the archive, and Bring back restores exactly what was stood down — not anything that was already deleted before.
• Deactivating a property does not deactivate the client, and standing down a client's last property does not cascade upward.
• Staff of a deactivated client can no longer sign in. This does not apply to property deactivation.

Records removed before deactivation was introduced appear in the archive with no reason recorded and cannot be restored — there is no list of what they affected to restore from.

Product feedback

/admin/feedback reads what people said when the product asked whether a surface was useful — how often each surface was asked about, how many answered, and how many found it useful.

Three reporting rules worth knowing: the response rate is a column, not a footnote; a dismissal is never counted as a "no"; and below a minimum sample the percentage is withheld and the raw counts are shown instead.

Using the console well

1. Start from the stream, not the organisation

   The console's value is the cross-tenant view. If you already know the organisation, work inside it.

2. Look for gaps

   Missing runs matter more than failed ones — failures are already surfaced locally.

3. Read before you act

   Most streams are read-only by design. Fix the cause in the owning module.

4. Review grants and impersonation on a schedule

   Both are access questions, and both drift quietly.

Common problems

Related