Manual for In-App Admins
The in-app admin role includes all keyholder functions and adds user management on top. Important context: this role manages accounts inside the tool — it is not the operator of the server and does not mean full data control. This section describes only the rights within the application. For questions about hosting and operations, see the reference at the end.
What the admin role is — and is not
As an in-app admin you manage user accounts and roles within a tracker instance. That is an application role, not server access.
If you use the portal, your instance runs on someone else's server as a free favour — with no SLA and no guarantees. Being an admin in the tool therefore does not mean you technically control the data yourself. Anyone who wants real data sovereignty runs the container on their own infrastructure (see Self-Hosting).
User management
In user management you create, edit, and delete accounts, assign roles, and reset passwords when needed. For testing you can create demo users.
User management is deliberately kept separate from the keyholder overview: control directives and account administration are two distinct tasks and live in separate areas.
Global and scoped admins
By default a global admin sees all users of the instance. If the instance is restricted to assigned relationships (the `USE_ADMIN_RELATIONSHIPS` configuration flag), an admin sees only their assigned users.
This lets an instance with several admins be cleanly partitioned instead of giving every admin insight into all accounts.
Admins as transparent keyholders
An admin appears in a sub's keyholder list as an implicit, read-only keyholder. That way the sub can always see who has insight into their data.
This principle ensures control never happens covertly: it is always clear who is controlling whom, even when the access comes from the admin role.
Role-aware portal
The portal title adapts to your role: acting as a keyholder you see the "Keyholder Portal"; in the administration view the "Admin Portal".
This makes it clear at any moment which context you are working in, and the two areas of responsibility do not blur together in the interface.
Per-user notifications
As an admin you manage the notification settings of individual users. This lets you, for a specific account, enable or disable particular event types.
This complements the sub's own self-service and is useful when central notification defaults are desired.
Enforce a mandatory device
Through the admin role a mandatory device is not only set as a directive but enforced: if a wrong device is worn and detected, the system marks it automatically.
This goes beyond the plain keyholder directive, where the device is only named as a requirement but not enforced system-side.
Operations and configuration
Topics such as feature flags and global language settings touch the operation of the instance. They are only touched on briefly here because they go beyond pure application administration.
For installation, configuration, and actual server operation, the existing Self-Hosting page is the authoritative source. Please consult that documentation for all operational topics.