One question keeps arriving through the feedback form, almost word for word the same every time: someone has set the instance up themselves — as the wearer, not as the keyholder — and now wants to bring their keyholder in. How do you invite her, and how do you give her the rights?
The short answer: there is no e-mail invitation. Accounts are created by hand. The longer answer is the more interesting one, because there is not one correct setup but two — and because the obvious third variant works better than its reputation suggests.
Not an invitation, an account
An account consists of a username, a password, an e-mail address and a role. You can create it two ways, both leading to the same result: in the portal under Dashboard → your instance → Tracker users, or inside the instance itself in the keyholder/admin area under Users → New user. The portal additionally lets you change roles and reset passwords without signing in to the instance.
You then pass the credentials on in person, through whatever channel the two of you already use. She changes the password herself in her settings afterwards; the old password is not required for that. This is a deliberate product decision: being signed in already is the proof of identity.
That gets the account created. The real question is the next one — which role it should carry.
Three roles, two role values
The tracker has three roles: the wearer, who documents their lockup; the keyholder, who sets directives and runs inspections; and the in-app admin, who manages user accounts. What separates the three in practice is covered in Does a keyholder have to track themselves?.
The account itself holds only two of those as values: "user" and "admin". That is not a contradiction — it is the heart of the whole question. Keyholder is not a role stored on an account; it is a relationship between two accounts. Who counts as a keyholder therefore follows either from the admin role, which sees everything anyway, or from an explicit assignment.
The two sensible setups follow directly from that.
Setup 1: she directs, you administer
Your keyholder gets an account with the role "user" and is then assigned to you: Users → your account → Settings → Keyholder. That gives her the full keyholder powers over your account — requesting inspections, setting lock periods, assigning tasks, defining training goals, keeping the penalty log — but no access to the administration of the instance.
Only an admin can make that assignment, which means you, as long as you are still an admin. User management therefore stays with you in this setup. That is the honest price: she directs you, but technical control over the instance remains with the person being directed. For plenty of arrangements that is exactly right — the dynamic lives on the agreement, not on how permissions are distributed in a database.
The practical advantage of this route: it hangs on the assignment, not on a role. It therefore works regardless of which role you carry yourself, and it survives someone changing roles later on.
Setup 2: she takes over, you become the wearer
Here she gets an account with the role "admin", or her existing account is switched over: Users → the person → Settings → Role. An admin sees every account on the instance; no additional assignment is needed for that.
You then demote yourself to "user", the same way, via your own account. This is expressly provided for and permitted as long as at least one other admin remains. The last admin cannot demote themselves — otherwise nobody could reach the admin area any more and the instance would be left unadministered. That lock applies in the instance as well as in the portal.
The order is therefore fixed: her account to "admin" first, then yours to "user". It does not work the other way round.
And if you both stay admin?
This is the state most people end up in by accident: the keyholder is made an admin and the wearer stays one too. And it works — better than you would expect.
A keyholder with the admin role sees every card on the instance in the overview, including that of a wearer who is an admin himself. She opens his detail page and can issue any directive: inspections, lock periods, tasks, verdicts in the penalty log. The permissions hang on her role, not on yours.
Two things are missing all the same.
The first is the rows in the keyholder inbox. For a wearer with the admin role the app does not create any, because there would be no reader for them — the inbox does not carry wearers who are admins. Importantly: the message is not lost. Mail and push go out unchanged; all that is dropped is the re-readable row in the inbox.
The second is the start page. A wearer with the admin role cannot be set as the landing page after sign-in, so she has to reach him through the overview each time.
Both are inconveniences, not blockers. Demoting yourself to "user" is therefore tidying up and the inbox, not a precondition for being directed. If you want to keep the role, you can — and if you do not need it anyway, hand it over and gain the inbox.
The portal account stays where it is
One distinction that is easy to miss: the admin role inside the app and the account in the portal are two different things. Whoever registered the instance in the portal keeps control over the instance itself — creating, deleting, updating it and resetting passwords — even when they are only a "user" in the app. Handing over the in-app admin role changes nothing about that.
If that is to be in her hands too, the cleanest route is for her to register the instance in the portal herself from the start; after the fact it can be transferred on request to the operator. And what generally holds for the portal holds here too: it is a free goodwill service, the instance runs isolated but on trublue's server — no SLA, no guarantees, and no data control of your own.
With self-hosting the line moves, but it does not disappear: someone operates the container there, and that is again something other than the admin role in the tool. Whoever provides the server has access to the database, regardless of the role their account carries.
Which setup fits
If your keyholder is to direct you but has no wish to deal with account administration, setup 1 is the right one. It is quicker to arrange, keeps administration where it already sits, and is insensitive to later role changes.
If the handover is meant to be complete — she administers, you wear — then setup 2 is the right one, self-demotion included. And if you also want the instance itself to be hers, have her register it from the start.
And if you both end up staying admin, nothing is broken. You lose the inbox rows on her side, and that is all.
The click paths for quick reference are in the manual for in-app admins.