Reports and the Report Permission Model

In myWork24, a report is a read-only screen that shows metrics, analytics, or an audit trail — it never lets you move stock, receive goods, or change a record. Because reports only show information, they get their own kind of access, separate from the buttons that do things.

Every report has its own permission

Each report in myWork24 is gated by its own dedicated permission, whose name always ends in _REPORT — for example FLEET_REPORT, ATTENDANCE_REPORT, or STOCK_AVAILABILITY_REPORT.

That deliberate separation is the whole point. A report permission grants "can view this report" and nothing else. It never carries any operate or write ability. So you can hand someone the numbers without also handing them the power to change the underlying data.

In short: holding FLEET_REPORT lets you read fleet analytics, but it does not let you check out a vehicle, take keys, or edit a trip. Those are separate, operational permissions.

Why this matters: analyst and auditor roles

Keeping reports on their own permissions lets you build read-only roles that would be impossible if reports were bundled into operational access:

• A Fleet Reports analyst who can study utilisation figures but cannot operate a single vehicle.
• An auditor who holds every _REPORT permission across the whole system — and can therefore review everything — yet cannot operate anything anywhere.
• A finance analyst who can review petty-cash spend and payroll cost figures without being able to post money or approve anything.

Because permissions are combined into roles (named bundles you assign to people), an administrator can gather several _REPORT permissions into one "Reports Analyst" role and grant it in a single step, safe in the knowledge that no write access sneaks in.

Access is enforced on the server

Report access isn't just about hiding a menu link. myWork24 checks your permission on the server, every time:

1. If you lack the permission, the report's menu entry is hidden from you.
2. If you follow a direct link to a report you're not allowed to see — a bookmarked URL, or a link someone shared — the system stops you and shows the shared Access Denied page.
3. You are never silently bounced to the dashboard. Access Denied clearly states that the link is valid but you don't have access, so it's obvious it was a permissions matter, not a broken link.

If you land on Access Denied for a report you think you should be able to see, ask your administrator to add the matching _REPORT permission to one of your roles. Permission changes take effect the next time you log in.

A few reports that exist today

These are real examples of reports and the dedicated permission each one needs:

• Available Stock Check — per-product actual availability across Stores and personal inventory, flagging over-committed and projected-short items (STOCK_AVAILABILITY_REPORT).
• Hours Analytics and other attendance analytics (ATTENDANCE_REPORT).
• Fleet utilisation report (FLEET_REPORT).
• Repair Performance — turnaround, stage timing, throughput and backlog (WO_REPAIR_REPORT).
• Subcontractor Report — material out at subcontractors, deadlines and overdue orders (EXTERNAL_SERVICE_REPORT).
• Procurement Business Intelligence — reorder, stock-cover and slow-moving analytics (PROCUREMENT_REPORT).
• Payroll Analytics and the Petty Cash report on the finance side (PAYROLL_REPORT, PETTY_EXPENSE_REPORT).
• Serial Number Locations, Leave Accrual, the Disciplinary report, and more — each with its own _REPORT permission.

Some reports show money or salary figures (payroll cost, petty cash totals). These are especially tightly gated and only appear behind their finance-oriented report permission — you will never see prices or pay figures on the ordinary floor and operational screens.

The takeaway: if you need to see the numbers, you need the matching _REPORT permission — and getting it gives you the view without ever giving you the ability to change what you're looking at.