B Bulawayo BillingRoles & access · Council portal and resident portal

City of Bulawayo Digital Billing Platform · access model

Who sees what, and who is allowed to change it

The platform has two front doors. Council staff sign in to the portal with one of seven roles; residents sign in to the resident portal (and the mobile app) as owners, tenants, businesses or newly registered users awaiting verification. Every screen, button and API call checks the same permission list, so what you read here is what the software enforces, not a policy on paper.

7staff roles in the Council portal
34named permissions behind every screen and API call
24portal navigation entries, 36 Council screens (P-01…P-83)
4resident types on the web and mobile side

Roles

Eleven ways into the system

Each staff role owns a slice of the revenue cycle; the four resident types differ in what part of an account they may see and change.

Council portal · staff

Resident portal · people paying the bills

Access matrix

Screen access by role

Rows are the portal's navigation entries with their PRD screen IDs. Click a role in the header to spotlight its column.

Full — can change state on this screen Maker only — can request, a different officer approves View only No access (hidden from navigation, blocked by the route guard and the API)
Screen

"Full" on Billing cycles and Adjustments still needs two different people: the officer who approves a cycle or an adjustment cannot be the one who requested it. The District Officer's view is additionally filtered to the suburbs of the assigned district.

Role by role

What each role sees, does, and is kept away from

Cross-cutting rules

Rules that apply whatever your role

4E Four eyes on money

Three actions require two different people, enforced by the API with a 403 maker_checker error rather than a greyed-out button:

  • A billing cycle is approved by one Finance Officer and checked by a second before bills are issued.
  • Account adjustments above US$200 (credit note, debit note, write-off, tariff change, interest freeze) wait in the approval queue for a Finance Officer other than the requester. Smaller ones apply immediately but are still logged.
  • A payment reversal is requested by Finance or Support, approved by a different Finance Officer, then executed.

R Reason, then record

Every state change asks for a reason and writes an audit entry with who, what, when and the before/after values. The Auditor, Council Admin and Thinkn Ops read the log; nobody edits it.

Read-only roles are read-only in the API too: an Auditor who somehow reaches a write endpoint gets 403, not a quiet success.

D District scope lives in the API

A District Officer's session carries the assigned district(s). The API filters properties, bills, payments, arrears and tickets to that district's suburbs and rejects anything outside it with 403. Dashboard KPIs are scaled to the district. The interface never has to remember to filter.

P Property ownership for residents

Every resident call checks that the property is linked to the signed-in resident. Tenants are further scoped to the services the owner shared (typically water and refuse) and to the expiry the owner set. Pending residents can see bills and pay, but cannot edit their name or phone until Support verifies the registration.

Resident portal

Four kinds of resident

Same screens (W-10 … W-76, identical to the mobile M-xx screens); what differs is the slice of the account each type may see and change.

Capability Owner Tenant Business Pending verification
Owner is the primary account holder on the Council register; several properties may sit under one login. Tenant access is created by the owner with a share code (W-72) and expires on the date the owner chose. Business is an owner with many stands and accountant-grade exports.

Try it

Demo identities

Any password works and every one-time code is 123456. The avatar menu switches identity without logging out. Deep links sign you in and land on the screen directly.

RoleSign in asGood first thing to tryDeep link
Base URL http://localhost:3077 Council login /login Resident login /my/login Reset demo data from the avatar menu returns everything to the seeded state.

Deep links use /demo?as=<id | email | phone>&to=<route>: the identity is signed in without password, 2FA or OTP and sent straight to the route. Point a role at a screen it may not open and you get the portal's own "no access" page — a quick way to see the guards at work. /demo on its own lists every seeded identity. Demo environment only.