FLOW LGX · PROBLEM SOLVED · JANUARY 2026

Problem solved: one layout for nine user roles, without leaking pages

Flow LGX ended up with nine user roles, each with its own menu, pages and permissions. Building nine separate apps would have been slow and inconsistent; building one app risked users seeing screens they should not. This is how we kept one layout and still kept every role in its lane.

About this project

Month by month, how a logistics platform for a Toronto client went from a simple brief to a live, multi-company SaaS product.

In short

Nine kinds of users share one product, but none of them can open pages meant for someone else. Access is checked at several levels, and the server always has the final say.

The problem

A super admin, an admin, warehouse staff, a dispatcher, a distributor, a direct customer, a customer, a vendor and a driver all sign in to the same product. Hiding menu items is not security: anyone can type an address into the browser. We needed every route to refuse the wrong user, without duplicating the layout or the navigation nine times.

The approach: checks in layers

Access is checked in layers, from broad to specific:

  • Route groups — each role’s section of the app is wrapped in a protected route that lists the roles allowed in. Wrong role, and the user lands on an unauthorised page.
  • One shared layout — inside the protected route, every role uses the same top bar and outlet; only the menu items change, built from the role.
  • Permission checks — inside the super admin area, some staff are not full super admins. A compliance reviewer, a vendor onboarding specialist, a support agent, a billing analyst, a security analyst or an executive viewer only get the actions their permissions allow.
  • The server decides — the interface hides what a user cannot do, but the API still enforces it. The front end is a convenience, never the lock.

Why one list of roles mattered

Every role has a code, a numeric id from the server, a display name and a home path. All four live in one file. Routes, menus, redirects after sign-in and permission checks all read from it. When new roles arrived during the move to SaaS, adding them was a matter of extending that file and the route table — not hunting through the codebase.

Result

Nine roles share one consistent product. Typing a forbidden address leads to a clear unauthorised page, limited staff see only their tools, and design changes to the layout reach every role at once.

Lesson learned

Hide what users cannot do, but enforce it somewhere they cannot reach. Menus are for convenience; routes and the API are for security.