What it is genuinely good for
- Managing reference data — categories, rates, settings
- Investigating a specific record when something has gone wrong
- Occasional corrections by someone who understands the data
- Early development, before proper screens exist
- Administrative tasks nobody does daily
For those uses it saves weeks of building screens that would be used twice a month. That is a substantial and frequently underrated benefit.
Where it falls short
- Daily operational work — it is not optimised for speed of use
- Anything a customer touches — it exposes your data model
- Workflows with multiple steps and conditions
- Anything requiring guidance for the person using it
- Bulk operations with complex rules
Configure it deliberately
| Configuration | Why |
|---|---|
| List display and filters | Otherwise it is unusable at volume |
| Search fields | Finding a record quickly |
| Read-only fields | Protecting derived and audit values |
| Restricted permissions | Not everyone should edit everything |
| Inline related objects | Editing in context |
An unconfigured admin on a model with thirty fields and fifty thousand rows is technically present and practically unusable.
Restrict access properly
Admin access is powerful. Staff who need to edit one model should not have permission to edit all of them, and permissions should reflect actual job requirements.
Every admin action should be logged, and the log should be reviewed occasionally rather than only after an incident.
Know when to build a screen
When someone is doing the same thing in the admin many times a day, that is a signal to build a purpose-built screen for it.
Purpose-built screens can be faster, guided and safer. The admin should be the fallback, not the daily tool.