Designing One Dashboard for Executives, Managers, and Warehouse Teams

The system served 5 different operational roles: Executives, AVPs, Store Managers, Brand Assistants, and Warehouse teams. Each group had different data needs, different action permissions, and different sensitivities around what they should see.

Building separate dashboards for each role was not practical. Building one dashboard that showed everything to everyone was a security and usability problem.

Problem

Executives needed aggregated analytics across all stores and brands. Managers needed store-level operational data. Warehouse teams needed stock movement and delivery records. Brand Assistants needed upload tools and store-specific views.

Without role control, every user sees everything. That creates noise, workflow confusion, and access risk. A warehouse staff member does not need sales analytics. A brand assistant does not need executive revenue summaries.

The other issue was action permissions. Not every role should trigger a CSV upload, approve a stock transfer, or access historical audit logs. View access and action permissions are different problems that both needed solving.

Solution

A permission model with two layers: module-level visibility and action-level permissions.

Each user record has an assigned role. When a session starts, the system loads the permission set for that role. Frontend components check the permission set before rendering. Backend actions check the same permission set before executing.

The module structure groups related functionality behind permission gates. Executives get analytics and cross-brand views. Managers get store-specific operations. Brand Assistants get upload tools and their assigned stores only. Warehouse gets delivery and stock movement.

Role-specific default views mean each user lands on a page relevant to their work. A manager logging in sees their store's daily summary, not an empty analytics page.

Result

All 5 roles use the same application. No separate codebases or deployments per role.

Data access risks are reduced. A brand assistant cannot access sensitive executive revenue data. A warehouse team member cannot modify sales records.

User adoption was better than expected. Because each role sees a filtered interface relevant to their work, the system felt less complex than it actually was.

The main ongoing work is managing role changes when people move between teams. That turned out to be the operational complexity, not the implementation.