Technology · Access control
A role is a rule,
not a menu.
Supervisors need enough authority to keep a shift moving without inheriting every company setting. That distinction belongs in the system's enforcement boundary, not only in which buttons the app chooses to display.
The principle
The server must make the same decision from every door.
A polished interface hides actions that do not apply to a user. That reduces confusion. It does not prevent a modified client, an old app version, or a direct network request from attempting the action anyway.
Real authorization evaluates the authenticated person, the company and location involved, the resource being changed, and the requested operation at the trusted boundary.
The boundary
Visibility guides. Authorization decides.
Separate the two layers
Interface visibility
GUIDANCE- Keeps irrelevant actions out of the way
- Explains the role's expected workflow
- Can be bypassed or become stale
Server authorization
ENFORCEMENT- Evaluates every write at the trusted boundary
- Applies across web, mobile, and integrations
- Produces an auditable refusal
→Use both. A secure product can still be confusing, and a clear product can still be insecure.
Model duties before titles
Job titles vary across operators. The durable policy starts with actions and scope, then maps local titles onto them.
Operate
Run today's shift
Receive vehicles, coordinate retrievals, resolve routine curb exceptions, and view the stand's current work.
Review
Oversee assigned locations
Inspect time, incidents, and performance within the locations this person is responsible for.
Configure
Change company policy
Pricing, payout, integration, and identity settings have a wider blast radius and deserve a narrower audience.
Own
Control membership and authority
Granting roles changes who can act. Treat it as a sensitive operation with explicit scope and history.
→The exact Valletto role matrix remains internal. The public lesson is that operational authority and settings authority are not the same tier.
Test the refusal path
Permission tests should prove both isolation and denial, not only that an authorized manager succeeds.
The buyer's question
What happens if I call the action directly?
Ask a vendor to demonstrate an allowed action, the same action in another company's record, and a settings action above the user's role. The answer should be a server refusal with no change, not 'the button is hidden.'
The takeaway: software knows someone is a supervisor when every trusted boundary enforces the responsibilities of that role.
