Draw the permissions before the dashboard

The demo always looks finished. A sidebar, four cards, a table. The question the demo hides is who is allowed to open row 400. OWASP’s access-control cheat sheet is blunt about the failure mode: the check lives in the interface, and the API returns the record anyway. Hiding a button is not a permission. The server has to refuse the read.

Write the roles as sentences before anyone draws a screen. A client can see their own jobs and upload a file to a job they are on. A manager can approve a job in their team. An admin can invite and revoke. Nobody can list another organisation’s rows. If you cannot say that in four lines, you are not ready for a layout. Off-the-shelf portal tools encode their own version of those sentences. They are the right buy until your sentence does not fit their form. That is the point a custom panel starts, not the point a logo is refreshed.

The states matter as much as the roles. Submitted, needs changes, approved, filed. A status that only exists in someone’s head will be re-implemented as a colour. Verallo’s tax team, written up by the people who watched it, dropped a portal and went back to email because bulk requests were slower than a bespoke message and nobody could see if the client had opened it. A portal that cannot answer ‘did they see it’ is a folder with a login.

Audit the boring paths. What happens when someone is removed from the team mid-task. What a client sees if they paste another client’s URL. What the export contains. OWASP’s guidance is to deny by default, check on every request, and log the denial. A portal without that log cannot tell you, later, who exported the list.

We will not start from a dashboard template. We start from the four sentences and the refusal tests. The screen is what is left once those pass.