Admin Pages for Phoenix SaaS Operators

It's a Tuesday afternoon and your first paying team reports that they cannot invite a new member. Support needs to look up the team, see who its owner is, find the failed invite in Oban, and — if it really comes to it — sign in as the owner for thirty seconds to reproduce the bug. Without an admin area, that turns into a remote iex session and a Slack thread that no one wants to read later.

This feature installs a proper backstage built with Phoenix LiveView so operators stop reaching for the production console. It is not a generic CRUD generator; it is a focused operator surface for the user, team, billing, and developer workflows that every SaaS eventually needs.

Give support and engineering a real place to work

Without an admin area, two things happen: support tickets escalate to engineering for trivial lookups, and engineering keeps a long-lived database shell open. Both are slow, both leak data, and both make your incident reviews much worse. A purpose-built admin surface keeps the day-to-day support flow inside the product and out of the database.

What This Feature Adds

• An admin LiveView area at /admin with charts, user management, team oversight, and developer tooling
• A user impersonation workflow so support can act as a user for short, deliberate sessions
• A chart.js hook (assets/js/hooks/chart.js) and real-time line / pie / bar charts in the dashboard
• An admin developer page that mounts LiveDashboard and the Oban dashboard alongside the rest of the admin
• Generated LiveView tests under test/my_app_web/live/admin/ so the admin keeps working as the app changes
• Role gating against the admin / superuser roles already created by the authentication feature

How It Fits Into Your Phoenix Application

The admin slots into your existing router behind an admin pipeline that checks current_user.role. It uses the Layouts.App layout from the layouts feature, the user roles from authentication, and the team scope from teams — so admins can pivot between teams while supporting customers. The chart hook is wired through assets/js/hooks/, so it picks up automatically if you used initial_setup to scaffold the hooks index.

Filtering and pagination across user / team lists are powered by Flop, which is included by the feature. The Oban dashboard and LiveDashboard are mounted under /admin rather than /dev, so production operators do not need a separate authenticated path.

Installation Notes

• Dependencies: authentication, layouts, and teams must be installed first. They are listed as hard dependencies in the manifest.
• The admin area is gated on current_user.role in [:admin, :superuser]. Make sure your config.exs admin email is set so the first user becomes a superuser.
• Impersonation is a powerful tool — decide and document the policy for when it is used. The feature gives you the mechanism, not the policy.
• If you also install error_tracker, the error dashboard is mounted under /admin/errors instead of beside the dev LiveDashboard.

Build This With Live SaaS Kit

Install saas_kit, then run mix saaskit.feature.install authentication, layouts, teams, and admin in that order to get a real operator console without writing the plumbing.