Admin panels and CMS

01What every admin needs

Start with the users of the admin, not the database tables. An operator handling orders needs a fast order list with status filters and real-time updates. A content manager needs pages, a blog, media and SEO. A marketer needs promotions, segments and campaigns. A manager needs reports. Behind all of them sit the same building blocks: authentication (ideally with a second factor or one-time codes for admins), roles and permissions, CRUD screens (create, read, update, delete) with search, filters, sorting and pagination, bulk actions, a media library, settings, reports with exports, and an audit log. Notifications — web push or in-app — tell staff about new orders or failed syncs.

• Lists: server-side pagination, filters in the URL so views can be shared.
• Forms: validation on the server, clear errors, unsaved-changes warning.
• Bulk actions with confirmation and a summary of what changed.

02Roles, permissions and audit logs

A role is a named bundle of permissions ("order operator", "content editor"); a permission is a single action on a resource, such as orders.view or products.update. Check permissions on the server for every request — hiding a button in the UI is convenience, not security. Keep permission names consistent so the admin menu, routes and buttons can all read the same list. For sensitive actions, such as refunds, manual balance changes or role changes, add extra friction: a reason field, a confirmation, maybe a second approver. An audit log records who did what, when, to which record, and the before/after values. When something goes wrong in production, the audit log turns guessing into a two-minute lookup.

1// Laravel: one permission check per action, enforced on the server
2Route::middleware(['auth:admin', 'can:orders.refund'])
3    ->post('/admin/orders/{order}/refund', RefundOrderController::class);
4 
5// Audit every sensitive change with before/after values
6AuditLog::create([
7    'admin_id'   => $request->user()->id,
8    'action'     => 'order.refunded',
9    'subject'    => $order->getMorphClass().':'.$order->id,
10    'before'     => ['status' => $before],
11    'after'      => ['status' => $order->status, 'amount' => $amount],
12    'reason'     => $request->string('reason'),
13    'ip'         => $request->ip(),
14]);

03Config-driven CRUD

Most admin screens differ only in fields and columns. Instead of writing each list and form by hand, describe a resource in configuration: its API endpoint, list columns, filters, form fields with types (text, number, select, rich text, image, slug, category tree) and permissions. A generic engine renders the list and form from that description, so a new resource takes minutes, and every screen gets the same pagination, validation display and bulk actions. On the backend, a generic resource controller can serve standard CRUD while custom endpoints handle special logic. Keep an escape hatch: some screens — an order detail page, a promotion builder, a dashboard — deserve custom components, and the config system should let you mount them.

1export const brandsResource = {
2  name: "brands",
3  endpoint: "/admin/brands",
4  permission: "brands",
5  list: {
6    columns: ["logo", "name", "productsCount", "isActive"],
7    filters: [{ field: "isActive", type: "boolean" }],
8    search: ["name"],
9  },
10  form: [
11    { name: "name", type: "text", required: true, translatable: true },
12    { name: "slug", type: "slug", from: "name" },
13    { name: "logo", type: "media", accept: "image/*" },
14    { name: "description", type: "richText", translatable: true },
15    { name: "seo", type: "seo" },
16  ],
17} as const;

04Media library and SEO fields

A media library stores uploads once and lets editors reuse them: folders, search, crop, replace (keeping links working), alt text and usage tracking. Validate uploads by content, not just the file extension, limit size and dimensions, strip metadata, and generate resized variants such as WebP thumbnails in a background job. Store files in object storage (S3-compatible) behind a CDN rather than the app server's disk once the site grows. SEO fields belong on every public model: slug, meta title, meta description, social image, canonical URL and a noindex switch, with sensible defaults generated from the content. The admin should also manage redirects, because renamed slugs otherwise create broken links, and the site should generate its sitemap from the same data.

05Reports and exports

Reports answer business questions: sales by day and channel, best products, new versus returning customers, promotion cost, average delivery time. Build them on queries designed for reporting — aggregated tables, read replicas or nightly summaries — so a heavy report never slows down checkout. Always show the date range and time zone, and make sure numbers match the order list (the same definition of "paid" everywhere). Exports to Excel or CSV are essential, since finance and marketing live in spreadsheets. Generate large exports in a queued job, stream rows instead of loading everything into memory, and send a download link when ready. Exports contain personal data, so protect them with permissions, short-lived links and an audit entry.

06Built-in CMS or headless CMS?

A CMS (content management system) lets non-developers edit pages and content. A built-in CMS lives inside your own admin and database: pages, blog, FAQ, banners and blocks next to products and orders. It is ideal when content is tightly linked to commerce data, and it costs nothing extra. A headless CMS (Contentful, Sanity, Strapi, Payload) is a separate service that stores content and serves it over an API; it shines for editorial teams, rich block-based layouts, previews and workflows. A hybrid is common: structured business data in your own backend, editorial content in a headless CMS. Whatever you choose, model content as typed blocks rather than one giant HTML field, so the frontend controls design and content stays portable.

07Authorisation beyond roles: scopes and policies

Role-based access control (RBAC) answers "may this person refund orders?" but not "may they refund orders of this branch?". Real back offices need both. Combine permissions with scopes: a branch manager has orders.refund limited to their branches, a supplier user sees only their products. Implement the check in one place per resource — a policy class — that takes the user, the action and the record, and apply the same scope to list queries so people never even see rows they cannot touch. This is a step towards attribute-based access control (ABAC), where rules use attributes of the user and the record. Cache each user's permissions per request, invalidate the cache when roles change, and write tests for every sensitive policy, because authorisation bugs are silent until they leak data.

1// Laravel policy: permission plus scope in one place
2class OrderPolicy
3{
4    public function refund(Admin $admin, Order $order): bool
5    {
6        return $admin->can('orders.refund')
7            && $admin->branches()->whereKey($order->branch_id)->exists();
8    }
9}
10 
11// The same scope applied to list queries
12Order::query()
13    ->whereIn('branch_id', $admin->branches()->pluck('branches.id'))
14    ->latest()
15    ->paginate(50);

08Audit logs that hold up in an incident

An audit log is only useful if people trust it. Write entries at the service layer, so changes from screens, API calls, imports and console commands are all recorded. Record a diff of changed fields rather than whole rows, and mask secrets and sensitive personal data. Make the table append-only: the application's database user may insert but not update or delete, and retention cleanup runs as a separate privileged job. Add a request ID to each entry, so one admin action that touches ten records can be traced as one event. For high-value actions, also log reads — who exported the customer list, who viewed a full card-holder address. Keep audit data long enough for disputes and regulations, and make it searchable by record, by person and by time range.

1-- Append-only for the application user
2REVOKE UPDATE, DELETE ON audit_logs FROM app_user;
3GRANT INSERT, SELECT ON audit_logs TO app_user;
4 
5CREATE INDEX audit_logs_subject_idx ON audit_logs (subject_type, subject_id, created_at DESC);
6CREATE INDEX audit_logs_actor_idx   ON audit_logs (admin_id, created_at DESC);

09Admin performance with large tables

Admin lists often become the slowest part of a system: an order table with millions of rows, a dozen filters, and a total count on every page. Index for the filters people actually use, usually composite indexes that start with status or branch and end with created date. Exact total counts on huge filtered tables are expensive; show "many results" or an estimate beyond a threshold, or count asynchronously. Offset pagination degrades on deep pages because the database still walks skipped rows; keyset (cursor) pagination stays fast. Avoid N+1 queries by eager-loading relations shown in columns. Search across many text columns belongs in a search engine or a full-text index, not chains of LIKE. Finally, put heavy dashboards on a read replica or summary tables, so a manager refreshing reports never slows down checkout.

• Log slow admin queries and review them monthly.
• Prefer cursor pagination for exports and infinite scroll.
• Eager-load relations used in list columns.

10Securing the admin surface

The admin is the most powerful door into the business, so it deserves the strongest locks. Require a second factor for every admin account. Keep admin sessions short with an idle timeout, and re-authenticate before critical actions such as changing roles or payout details. Consider serving the admin on a separate subdomain, with stricter cookies and, where practical, an IP allowlist or VPN. Protect against CSRF on cookie-based sessions, and against stored XSS from rich-text fields by sanitising HTML on the server with an allowlist of tags. Uploaded files must never be executable: store them outside the web root or in object storage, and serve user-uploaded SVG carefully, because SVG can contain scripts. Monitor admin logins and alert on new devices or impossible travel.