Users, roles and access
The three login roles (Admin, Billing and Team Member) who can invite whom, how logins relate to the people you measure, and what each role can see.
Updated 12 July 2026
Two ideas underpin access in EngLedger, and keeping them separate answers most permission questions. A user is a login. A person is someone being measured. Most people never need a login (sync and attribution work entirely from provider identities), and most logins belong to the people running the org, not the people being measured.
The roles
| Role | What it's for | Can see |
|---|---|---|
| Admin | Running the organisation | Everything: integrations, people, reports, classification, settings, billing, audit log and the AI surfaces |
| Billing | Finance contact for billing and plans | The payment method and account settings, nothing else |
| Team Member | A person's own login | Their own profile, work, identities and AI usage |
The first account created with the organisation is an Admin. Reports, integrations and settings are admin territory; the governance reports in particular are admin-only by design: the privacy model starts from org and team views, not from broad access to individual data.
Inviting admins and billing users
Admins invite other admins and billing users from Settings: enter an email, pick the role, Send invite. Invitations show as pending until accepted, can be revoked while pending and resent once expired.
Team Member logins
Team Member logins aren't created by invitation: they're switched on per person. Enabling login on a person's profile creates the account and emails them; switching it off deactivates it. That coupling is the point: a Team Member login is that person's window into their own data.
A signed-in Team Member can:
- see their own profile and work, the commits and tickets attributed to them;
- review and link their own provider identities, using the same email matching admins use;
- see their own AI usage, the same detail their organisation holds, not a summary of it;
- see their own hourly rate only if the organisation has enabled showing rates to team members (off by default).
What they can't do is browse anyone else's data. Requests for another person's detail are refused server-side, not just hidden in the UI.
Managing existing users
From the team members list an admin can rename a user, change their role, deactivate and reactivate them, reset their MFA, or remove them. Two guardrails apply: you can't perform these actions on your own account, and the last admin can't be demoted, deactivated or removed: an organisation always has at least one.
Deactivation is the right tool for departures: the login stops working, while the person's record (and every number attributed to it) stays intact. Removing a user never deletes measurement data, because users and people are separate records.
Two-factor authentication
Any user can switch on two-factor authentication for their own account from account settings. Admins can go further and make it mandatory: Settings → Security → Require two-factor authentication for all users. The requirement covers every role, admins included.
Setup happens in the app the first time it's needed. The user scans a QR code with an authenticator app (or enters the key manually), confirms with a six-digit code, and is shown a set of recovery codes (once, with a download prompt). Recovery codes are the fallback when the authenticator is lost, so saving them is the one step worth insisting on. From then on, signing in means password first, then a code from the app (or a recovery code).
Turning the requirement on takes effect immediately, not at next login. Users who already have two-factor set up notice nothing. Everyone else (including anyone signed in at that moment) is taken to the setup flow before they can do anything further. There's no grace period to manage and no window where the requirement exists on paper but not in practice.
When someone loses both their authenticator and their recovery codes, an admin resets their two-factor from the team members list. The reset clears their setup entirely and emails them to say so; they sign in with just their password and (if the organisation requires two-factor) are walked straight back through setup. As with the other member actions, you can't reset your own: a second admin has to do it.
Where access questions usually land
- "Why can't this person see the reports?": they're a Team Member; reports are admin surfaces.
- "Do your people need accounts for metering to work?": no. AI metering and identity mapping work without logins; a login only adds the self-service view.
- "Can people see what the org sees about them?": for their own AI usage, yes, by design. See the governance model.