People
Who is on the installation, who runs it, what a team is, and where support questions are answered.
Five screens decide who exists, what they may do and how they are helped. Two of them are used daily and three are used when something needs attention.
Users
People → Users is the directory: every account, with search, filters and sorting, and a row of actions per
person.
| Action | What it does | Reversible? |
|---|---|---|
| Set the plan | Moves somebody between plans without a payment | Yes, by setting it back |
| Confirm the address | Marks an email address as confirmed by hand | Yes, in the sense that nothing is lost |
| Add credits | A hand top-up, with a reason | No, but the ledger records it |
| Set a ceiling | A per-account limit, or clearing one | Yes |
| Delete | Removes the account, after a typed confirmation | No. See the note below |
Deletion is the one that cannot be walked back
Deleting an account removes the person. Take a snapshot from System → Backups & exports first if there is any doubt, and treat a typed confirmation as the
last chance to change your mind rather than a formality.
The screen also lists, in plain words, what it deliberately cannot do: it cannot sign in as somebody, it cannot suspend an account, and there is no second factor for administrators yet. Capabilities that are absent are written down rather than hidden, which is the habit everywhere in this panel.
Admins & roles
People → Admins & roles lists who can open the panel, and what each role is for.
| Role | The short version |
|---|---|
| Owner | Everything, including licensing, updates and the destructive screens |
| Admin | Everything operational: models, money, people, content |
| Support | Read and light actions: users, invitations, support messages |
Everyone who can open the panel appears with their role and when they last signed in. The permission matrix and invitations for administrators are not in this version, and the screen says so.
Teams & seats
People → Teams & seats is the view of teams across the installation: which account formed one, what plan is
paying for it, how many seats it holds and how many are used.
Seats come from the plan, so an upgrade is what buys more of them. The screen is read-mostly: a team is created by its owner inside the product, in Team, and this is where you see all of them at once and answer "why is this account over its seat count".
Invitations
People → Invitations is every invitation, pending and accepted, with the three actions that matter:
- Resend, for the invitation that went to the wrong folder.
- Revoke, which stops the link working immediately.
- Extend, for the case where the expiry passed while somebody was on holiday.
An invitation is tied to an address, so revoking one and sending another is the correct way to fix a typo rather than editing it.
Support
People → Support is the product's own inbox: messages people send from inside the product, the promises you
have made, and canned answers.
| Part | What it is |
|---|---|
| Messages | What people wrote, with the account it came from |
| Promises | Anything you have committed to, with its state |
| Canned answers | Replies you can reuse, which send through the same mail configuration |
Support mail needs the mail names
A reply here is sent through the deployment's mail configuration, so
RESEND_API_KEY and EMAIL_FROM have to be set for it to leave. Without them
the message is recorded and not sent, and the screen says which of the two is
missing.
The three habits that save support time
Look at the audit log before answering System → Audit log answers "why
did it change" with a name and a timestamp, which turns a long guess into one sentence.
Check the ceiling before the plan Most "I ran out too fast" questions
are a per-account ceiling or a heavy model being used more than usual.
Money → Credits shows the movements behind the number.
Reach for confirmed, not for resend If the address is right and the
person cannot sign in, confirming the address by hand is one click and settles whether the problem was mail or the account.