Enterprise Web UI Patterns: Menus, Permissions, Heavy-Duty Tables
An ERP screen is not a landing page. Users sit in front of it for eight hours, navigate by memory, and judge the whole system by whether a 2,000-row stock ledger scrolls without stuttering. Three UI problems account for most of the enterprise-web effort: menus driven by permissions, tables that carry serious data volume, and forms that must not lose work. Here is how we handle each.
Menus: generated from permissions, not hard-coded
In an ERP with role-based access, the menu tree is the permission model made visible. Hard-coding menu entries in the frontend guarantees drift the day someone adds a role. Instead:
- The backend owns the menu tree. Each menu item maps to a permission code; the frontend renders exactly what the user's permission set returns.
- Hide what you forbid. A menu item the user cannot open should not render at all. Security by obscurity is not security, but a wall of disabled items is noise; the route guard remains the real enforcement.
- Favorites and recency live client-side. Let power users pin their five daily screens to the top; it costs nothing and saves minutes every day.
Keep the tree shallow — three levels is the practical maximum before users lose orientation. If a module needs more, use tabs or an in-page second navigation, not a deeper tree. This mirrors the module structure of the modular monolith: one route subtree per backend module.
Heavy-duty tables: virtualization is non-negotiable
Enterprise tables routinely show hundreds of columns and tens of thousands of rows. DOM nodes are the enemy:
- Row virtualization — render only the visible window plus a small overscan buffer. Whether you hand-roll it or use a library, this is the single biggest win.
- Column virtualization for wide grids — financial ledgers with 40+ columns benefit from horizontal virtualization too.
- Pagination is still legitimate — for operational lists, a page size of 50–200 with server-side sorting and filtering is often better UX than an infinite virtual scroll, and far easier on memory.
- Sticky headers and frozen first columns — cheap to implement, disproportionate usability gain when scanning wide ledgers.
- Column show/hide and saved layouts — let each user curate the grid; persist per-user, per-screen.
Measure with real data before optimizing: a table that is "slow" at 500 rows is usually a cell-rendering problem (unmemoized components, expensive per-cell formatting), not a virtualization problem.
Master-detail and dirty-state protection
The ERP workhorse screen is master-detail: an order list on top or left, the selected order's lines below or right. Two rules keep it sane:
- One screen, one dirty form. If the user has edited an unsaved document and clicks another row, block with a dialog: "Discard changes / Save / Cancel". Losing an edited order because of a stray click is the kind of bug users never forgive — implement it as a router-level guard so it cannot be bypassed by keyboard navigation.
- Autosave drafts. For long documents, persist a draft to the server every minute or on field blur. "Saved 14:32" in the corner converts anxiety into trust.
Consistency beats novelty
Enterprise users do not want to be delighted; they want to be unsurprised. Lock down a small component vocabulary — one table component, one form layout, one dialog style, one date and one number format per locale — and route every screen through it. The approval center, the MRP exception list and the integration monitor from e-commerce integration should feel like the same application, because they are. Frontend consistency is the UI-level reflection of the backend's boundary discipline: same workflow engine underneath, same patterns on top.
Conclusion
Menus from permissions, tables that virtualize, forms that never lose work, and a component vocabulary small enough to memorize. None of it is glamorous; all of it is what makes a web ERP feel like a tool instead of a obstacle. Ship these four and the UI stops being the complaint users mention first.