What this surface represents
Staff does not expose a separate generic detail page. Instead, several staff workflows rely on the same backend detail payload:
- Staff View uses it to render the read-only Overview and Permissions tabs.
- Staff Edit uses it to prefill editable identity, group, and permission values.
- Staff Create uses selected parent-admin detail reads when a Support account needs permission seeding.
- The staff list shell also reads current-operator detail to decide whether some staff actions should be visible.
Why this matters
- When operators see one set of fields in the read-only page and another in the edit form, they are still looking at the same underlying admin detail source.
- Role, group, identity fields, and permission data should be interpreted as one shared record model.
- If the detail payload is wrong, both the view and edit experiences can be affected.
- Non-root operators can be scoped by backend parent/current-admin rules when requesting another staff record.
- Root-superadmin detail can resolve to a backend-defined full permission set.
- Root-level detail reads can include extra operational metadata that Staff View and Staff Form do not render as staff fields.