software-sob-medida

When does a spreadsheet need an operational dashboard with permissions?

The spreadsheet tracks requests, but a change can alter approval information or remove an important value. As the team grows, reading information and operating on it need different rules.

The spreadsheet tracks requests, but a change can alter approval information or remove an important value. As the team grows, reading information and operating on it need different rules. An operational dashboard is not simply a reporting screen with extra buttons: it must define authorised actions and verifiable change.

Separate reading, editing and deciding

List actual roles and actions for each record. One person may view progress without changing a value; another may review but not approve their own request. Do not copy a generic job hierarchy before understanding the workflow. Server-side authorisation must follow the resource and operation.

ActionRule to establish
CreateRequired data and owner
EditPermitted state and fields
ApproveAuthorised role and responsibility conflicts
CancelReason and downstream consequences
ExportInformation the role may actually access

Document the matrix first. If approval rules are unresolved, the application should not silently choose them. A prototype can illustrate transitions, but the operating decision remains necessary.

Test concurrent changes

In a hypothetical request, one person reviews while another changes its value. The system needs conflict detection or an explicit precedence rule rather than silently accepting the last submission. Versions and history help reconstruct change; they do not replace an approval process.

Try unauthorised access, retries and interruptions. Hidden buttons are not protection. OWASP's authorisation guidance supports checking protected operations; tests need both permitted and prohibited paths.

Keep demonstrations within their scope

This site's dashboard demonstration contains a table, filter and totals over fictional records. It does not implement business accounts, approval or operational audit. Those features require a separate scope, authorised sources and validation criteria.

Through custom software, I can map roles, states and events, implement permissions and history, and test conflicts. Read-only indicators may fit a smaller dashboards and BI scope.

Bring an anonymised record, an initial action matrix and a real exception. That helps define the missing operational capability without replacing a simple file with more software than the work needs.

Sources and further reading

About the author and editorial process

Rafael de Sanzio Nonato develops websites, web applications and integrations independently. Scope and responsibilities are agreed for each engagement.

Prepared with AI assistance. Examples are hypothetical unless explicitly documented. Publication is subject to the author's editorial approval.

Approach and responsibilities →

Define permissions before operating through a dashboard

Explain who reads, changes and approves each record. I can design an operational workflow with server-side authorisation and change history.

Define permissions before operating through a dashboard ↗