Accounts & learners | Mastria Docs

Mastria knows the difference between a developer evaluating your tool on their own and an engineer at one of your customers — because those are different populations with different business value, and your reporting should never mix them up.

Automatic account detection

When a learner signs in for the first time, their email domain decides where they land:

Business email (ana@acme.com) → the learner is attached to the Acme account. If no account for acme.com exists yet, one is created automatically, on the spot.
Free email (gmail.com, outlook.com, …) → the learner is an Individual — top-of-funnel, not tied to any customer.

Nothing to configure, no CSV to upload, no invitation flow to manage: your customer's engineers just sign in with their work email and show up under the right company.

Why this matters

Everything account-shaped builds on this: the "how is Acme's onboarding going?" screens in Admin → Accounts, per-account progress by course, and trained-vs-untrained comparisons against your product's own metrics (Admin → Analytics → Impact). If learners weren't attached to accounts from day one, none of that reporting would be possible retroactively.

Private courses per account

Accounts also do access control: a course can be restricted to selected accounts (Course settings → Access) — a paid onboarding course only Acme's engineers may see, an early-access course for two design partners. There's nothing to provision: learners sign in with their work email, land in the right account, and each person's home shows exactly the courses their company may see. Anyone else gets a 404; a signed-out visitor with the link is asked to sign in first.

Each account's page lists the private courses it can see, with a link into each course's settings — so "why can't Ana see this course?" is answered from Ana's account page, not by opening courses one by one.

Managing accounts (Admin → Accounts)

The Accounts page is a table of every customer: learners, how many were active in the last 30 days, course completions, and last activity — searchable by name or domain, sortable, 25 per page.

Create an account before its first learner signs in. Restricting a private course to Acme needs Acme to exist, so the page leads with a New account form: a name and, optionally, the email domain. With the domain claimed, everyone who signs in from it lands in the account automatically; without one, learners only reach it when you move them in by hand.

Open an account to see and manage it:

Progress by course — for each course anyone here opened, how many learners started it and how many finished every published lesson ("8 of 12"), with the last activity. This is the question a lessons-completed total never answered.
Course access — the private courses restricted to this account, each linking to that course's settings.
Email domains — claim more (acme.io, mail.acme.com) or release one. Claiming a domain also gathers any Individuals who signed in from it and were never placed by hand (someone you moved out to Individual stays out); releasing a domain moves nobody — future signups from it form a new account instead. Personal-email providers can't be claimed (their learners are Individuals by design), and a domain another account already holds points you at that account or at a merge.
Learners — the roster: the same table as the Learners page, fixed to this account, searchable and sortable.
Rename — auto-created accounts are named after their domain; give them the company's name.
Merge into another account — two accounts that turn out to be one company: learners, domains, and course access move to the account you pick, and this one goes.
Delete — only an empty account (one created in error). Move or merge its learners first; nobody loses their home through a delete. And if the account is the only one allowed on a private course, the delete refuses until you change that course's Access — otherwise the course would open to everyone.

Finding a learner (Admin → Learners)

Every learner of the academy in one table — Individuals included, filterable to them or to any account — with courses done, certificates, last activity, and join date. The search matches the name, the current email, and every address the person ever signed in with, so the old work address in a support ticket still finds them after an email change.

A learner's page shows:

Account — which account they're in and how they got there (matched by domain, or placed by an admin), with a Move into any account or out to Individual. Moving changes which private courses they can see immediately; progress and certificates stay with them.
Sign-in addresses — the primary, any confirmed recovery address, and former addresses (kept so product metrics sent to them still count for this person).
Learning record — every course they opened with progress and status, the same record they see on My profile, plus their lab activity.
Certificates — each credential with its public link, and a door into the ledger for resends and the name audit.
Merge into another learner — the duplicate-identity repair, described below.

Groups

Every account already behaves as a group. On top of that, manual groups (a "Q3 onboarding cohort", "Partners") let you organize learners across accounts. Signup-time enrollment rules — if learner matches this domain, auto-enroll them in this course — are planned on the same foundation.

One identity, per-academy profiles

A learner's identity is their email. If the same person learns at two different academies on Mastria, each academy sees only its own progress, records, and account attachment — nothing crosses tenant boundaries. The one thing that follows the person is their display name (set on the My profile page): it's their name, not the academy's data, and it renders on their certificates wherever they earn one.

When someone changes companies

Training platforms have a notorious failure mode: an identity keyed to a work email that stops existing the day the learner leaves. Mastria closes it at three layers:

A recovery email (My profile → Recovery email): a learner adds a personal address, confirms it from that inbox, and from then on either address signs into the same account — progress, certificates, everything. Set up once, whenever; the work inbox dying stops mattering. The primary inbox is notified whenever a recovery address is confirmed.
Changing the sign-in email: the confirmed recovery address can be promoted to the primary in one (deliberately two-step) click. The old address stops signing in immediately — a recycled company inbox can never inherit the account — while the impact reporting keeps matching product metrics sent to the old address to the same person.
Proof never lives behind the login anyway: certificates are public permalinks that never revoke, the learner is emailed the permalink the moment a certificate is issued, Add to LinkedIn puts the credential on their own profile, and the training history page prints a transcript with verification URLs.

For the person who left without setting any of this up and started over under a new address, the academy operator merges from the learner's page (or the Merge… link on any roster row): the tool opens with that learner locked as the source, you type the new address — preview, then two clicks. Progress unions, lab attempts and certificates move, and certificate URLs never break. A dead inbox can't prove ownership self-serve — but the operator knows their people.