Branches are enforced, not suggested

In a lot of business software a branch is a filter on a report. Change the filter and you see everything. Here the server decides, and a refusal is a 404 that reveals nothing.

Most systems suggest branches. This one enforces them

In a lot of business software a branch is a filter on a report. Change the filter and you see everything. That is fine until the person doing it is a cashier at one shop looking at another shop’s till.

The server decides, not the screen

Every branch-scoped query in this system respects the branch the request arrives with. A user with one branch cannot read or write another branch's stock, till or ledger — and hiding the button was never the mechanism. Ask for another branch’s record by its id and the answer is a 404, identical to a record that does not exist, so the list cannot be enumerated either.

Reading is only half of it

A scoped query closes editing and deleting by id. It does not close a CREATE. That gap was real here: a one-branch user could post a delivery into another branch and be told 201 Created — a stock movement in books they cannot open. Writes are now refused by name, and the refusal names the branch and the field.

Accessible Branches

A user can be granted more than one branch. The important detail is the default: an account with no branches recorded is not isolated at all. There is an audit command that lists exactly those accounts, and it should be run before enforcement is relied on — a lockdown is only as real as that list is short.

Where it deliberately does not apply

Some flows are company-wide by design — the call centre and delivery dispatch among them — and they ignore the branch header on purpose. Where a figure is company-wide, the screen says so rather than letting somebody read it as their branch’s number.