Two Admin Panels, Not One: Separating Administrators From Frontline Staff

Most back offices start as one admin panel. As the business grows, more people need access, so menus get hidden behind permissions and the panel tries to be everything to everyone. For an operations backend behind a services marketplace, we took a different route: two genuinely separate admin experiences, one for platform administrators and one for staff.

The problem with one panel for everyone

A single panel with permission-gated menus works, but it has costs that grow with the team:

• Safety depends on getting every permission right. One misconfigured permission and a staff member sees administrator tools.
• Nobody gets an interface built for their job. Staff wade through an administrator's layout with sections hidden, instead of seeing the handful of things they actually do.
• Every change affects everyone. Rearranging the admin interface for administrators also rearranges it for staff.

The approach: separate Admin and Employee panels

The backend has two distinct panels, Admin and Employee, with role-based switching between them for people entitled to both. Each panel is designed for its audience:

• The Admin panel is built for the people who run the platform.
• The Employee panel is built for frontline staff and the work they do day to day.

The panels are built with Filament, which supports running multiple panels in one Laravel application, each with its own resources, navigation and access rules, as described in the Filament documentation.

Policies underneath both panels

Separate panels do not replace fine-grained authorisation. They sit on top of it. Underneath, access is controlled by category-level and service-level policies, managed with Spatie's permission package. That means:

• A staff member can be limited to particular categories or services, not just to "the Employee panel".
• The same rules apply however a record is reached.
• Changing who can work on what is a matter of assigning permissions, not editing code.

The panel decides what kind of interface someone sees. The policies decide exactly what they can do in it.

A catalog with media attached

The service catalog stores media alongside each service, so images and files are managed with the service they belong to rather than in a separate file store that drifts out of sync.

An API alongside the panels

The backend also exposes a conventional API layer next to the admin panels. Apps and integrations can work with the same catalog and the same rules, rather than depending on a separate system that re-implements them.

When to split your admin panel

Two panels are worth it when:

• Different groups of users do fundamentally different jobs in the back office.
• The consequences of a staff member reaching administrator tools are serious.
• Each group would benefit from its own navigation and dashboard.

A single panel remains the right choice for small teams where everyone does roughly the same work.

A checklist for designing back-office access

• List each group of back-office users and the jobs they do.
• If the jobs differ sharply, give each group its own panel.
• Enforce access with policies at the level of categories and records.
• Let people with more than one role switch panels explicitly.
• Expose the same rules through an API for apps and integrations.

The anonymised write-up is in our work library. For a much larger version of the access-control problem, across branches and tenants, see building a multi-branch ERP. Designing back offices around how teams actually work is part of our business automation service.