View / Allow: permissions that match how a business actually runs

Access in SeroBooks is a View/Allow tree over every screen and action: what a role can see, and separately, what it can do. Build roles like Counter, Manager, Bookkeeper — each a policy, assigned to people, maintained in one place. The cashier who can sell but not discount, the manager who can discount but not edit closed periods: each is a role definition, not a conversation.

Buttons the role cannot use do not tempt anyone: gates apply in the interface itself, so the product each person sees is the product they are allowed.

Permissions are enforced server-side, not politely requested client-side. A revoked permission reaches the device and stops the action even if the screen was already open — control that holds on a network of tills, not just in a demo.

That architecture is why the permission tree can be trusted with real money: the till obeys the server, and the server obeys the role.

One owner behind one counter needs none of this and never sees it. Two hundred licenses across a retail group need all of it and get it without an enterprise-tier upsell: roles, gates and audit are the same product at every size.

Every gated action that happens is logged with who did it — permissions decide, the audit trail remembers.