Accounts & learners

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.

Private courses

Accounts also do access control. A course can be open to everyone, or only to some accounts (Course settings → Access → Who can access → Only some accounts), chosen three ways at once:

• Every account of a type: all your partners, say, for a partner certification track.
• Every account carrying a tag: enterprise for a paid onboarding course, beta-program for early access.
• Named accounts: search by name or email domain and add them. Two design partners, Acme alone.

An account that matches any of these gets in. It's checked every time a page loads, so when you (or your CRM) tag Globex enterprise, Globex's engineers see the course on their next page load, and when the tag goes, so does the course. There's nothing to enroll and nothing to backfill.

There's nothing to provision on the learner side: people 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.

Managing it from the group. Filter the Accounts page to a type or a tag and a Courses open to … card lists the private courses open to that group, with Remove and a search to give the group another course. Two changes stay on the course's own Access tab, because they switch a course between "everyone" and "some accounts": opening a published course that is currently open to everyone, and removing the last group a course is open to.

Why can Ana see it? Each account's Access tab lists the private courses its learners can open and why: named, open to its type, or tagged. Ana's account page answers it without opening courses one by one.

Managing accounts

Admin → Accounts is a table of every company: its type, learners, how many were active in the last 30 days, course completions, and last activity — searchable by name or domain, sortable, 25 per page, and filterable by type, by tag, and to the accounts you own (see Describing accounts).

Open an account to see and manage it. The header shows the owner, the renewal date, and four linked counts, each opening the matching learner list:

• Learners — "26", with "of 40 seats, all time" when you've recorded seats;
• Active in the last 30 days;
• Finished a course — people with a recorded finish, all time;
• Certified — "1", with "of 2 people needed" against a target, in the warning color while it falls short.

Four tabs follow:

• Overview — five course-progress rows ("12 started", "8 finished (67%)"), a Recently certified card with the five most recently certified learners, and Course ratings: how many ratings the account's learners gave and their five newest, each course opening all of its ratings from this account; View all opens the full lists. Course progress can be searched and paged, and its started and finished counts open the people behind them. A course finish here means every current published lesson is complete; the header's historical count keeps earlier recorded finishes even if the course later grows.
• Learners — search, sort and paginate the account's roster. Filter to active learners, people who finished a course, or certificate holders.
• Access — search and page through private courses granted directly, through the account's type, or through its tags. Each row explains why access was granted and links to that course's Access settings.
• Settings:
  • Account details → Edit details changes the company name and the account fields together (next section). Saved values stay visible as a compact summary until you edit; Save checks that another editor or CRM sync hasn't changed the account since you opened the form.
  • 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.
  • Merge 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. The account you keep keeps its own details, takes this one's where it has none, and gains its tags.
  • Delete account — only an empty account (one created in error). Move or merge its learners first; nobody loses their home through a delete. 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.

Tabs and filters live in the URL. Back to Accounts restores the search, filters and page you came from. Releasing domains, merging and deleting ask for confirmation with the consequences spelled out.

Describing accounts

An account starts as a company name and its domains. Every business email that signs in creates one, so a real academy soon has hundreds, and most are prospects, not customers. Give an account a few facts and it becomes something you can sort, filter and act on. On the Settings tab, each account has an Account details card:

• Type: Customer, Partner, Prospect or Internal. Accounts created by a sign-in start Unsorted. Internal is your own company.
• Tags: free labels, whatever your team groups customers by (enterprise, eu, beta-program). Up to 20 per account, stored lowercase.
• CRM id: your CRM's id for the company. It's unique within the academy, and it travels on webhooks and in accounts.csv so your tools can join on it (the other exports carry the account's Mastria id).
• Owner: the person on your team who looks after the account.
• Seats and Renews on: what the customer bought and when it renews. With a seat count the account header reads "of 40 seats" under its learner count.
• Certified people needed: a partner tier's requirement (say, 2 certified people). The header then reads "of 2 people needed", in the warning color while it falls short.

The top of each account page answers the questions a CS team asks: how many learners it has and how many were active lately, how many finished a course (a finish stays a finish even if the course grows later), how many are certified (hold a certificate), and how long the account took from its first sign-in to its first finished course.

The Accounts page filters by type (with counts), by tag (the most used tags are listed above the table; a tag on any row or account page is a link to it), and to Mine, the accounts you own. Show → Renewing soon, nobody trained lists the accounts that renew in the next 90 days where nobody has finished a course yet — the list to hand your CSMs. A Certified column counts certified people ("1 of 2" against a target). To change many at once, tick rows and use the bar above the table: set a type, add a tag, or remove one.

From your CRM. Paste a CSV in Update accounts from a CSV at the bottom of the Accounts page, or have your CRM call the accounts API with the same fields. Each line finds its account by domain, crm_id or account_id; a domain no account holds creates the account, which also gathers anyone who already signed in from that domain. Empty CSV cells leave a field as it is. Lines that can't apply are named, and the rest go through. accounts.csv uses the same column names, so you can download it, edit it, and paste it back.

Finding a learner

Admin → Learners is 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. Admin → Reach opens this list filtered by how people first arrived (a campaign, a shared certificate, another site).

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).
• Arrived by — in the header: the campaign, shared certificate or site that brought them, and the first page they opened, when the academy's sign-in form recorded it (see Reach in Dashboard & analytics).
• Learning record — every course they opened with progress and status, the same record they see on My profile, plus their lab activity (exercises passed, attempts, and presses of Run).
• 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.

Sharing progress with a customer

The question a customer's manager asks your customer-success team — "how is my team doing in your academy?" — has its own answer: a private, live page for one account. On the account's page in Admin → Accounts, the header's Share progress → Create a link makes it. Copy the link and send it; the manager needs no account and no sign-in.

What the manager sees — on your academy's own domain, in your branding, read-only:

• people signed in (against the account's seats when you recorded them), active in the last 30 days, who finished a course, and who holds a certificate;
• how long it took from the account's first sign-in to its first finished course;
• progress by course: for each course someone at the account started, how many of them finished it. Only live courses this account can see appear — drafts, deleted and hidden courses never do, and neither does a private course the account isn't in the audience of (say, one a learner started at their previous company). The tiles and each person's courses and certificates follow the same rule, so every number on the page agrees;
• names only for people who chose to share theirs (below), each with their number of courses finished, their certificates, and when they were last active, 50 per page. Everyone else counts in the numbers without being named, and the page says how many people that is.

Course ratings never appear on the report: learners rate a course knowing only your team sees it.

The numbers are read when the report opens; Refresh updates them, and the timestamp shows when they were read. Because the report excludes unavailable courses, its totals can differ from the admin overview — the sharing panel explains that scope before you preview or send the link.

The link:

• It works for 90 days. On the account's page you can see when it expires, how many times it was opened and when last, and who created it. Copy link and Preview report are the main actions.
• Under Manage link: Extend expiry keeps the same URL working for another 90 days; Replace link creates a new URL (the old one stops working at once); Turn off link ends it. Replacing or turning off asks for confirmation. An expired link has a Renew link button; a turned-off link needs a new URL, but its history stays visible.
• An expired or turned-off link shows nothing about the account — not even its name.
• Opens by your own team (the card's Preview report button) and link previews in email or chat don't count as opened — only a person loading the page in a browser does, once per visit.
• If someone else on your team changed the link since you opened the account page, the buttons refuse and ask you to reload, rather than acting on a link you haven't seen.
• Merging this account into another moves its link to the account you keep, so the manager's URL keeps working; if both accounts have a link, the one you keep stays and this one is turned off.

Learners decide whether they're named. A learner who belongs to an account sees Sharing with Acme on their My profile page: tick Include my name and progress in Acme's report to share their name, number of courses finished, certificates and last activity date with anyone holding the link, including forwarded copies. Untick it any time to go back to being counted only; changes save automatically. It's off until they turn it on. Once their company has a report link, a home-page prompt invites them to choose; it links to these settings, never turns sharing on itself, and once dismissed (or once they choose) stays gone on every device. The choice is for that one company: moving to another account or to Individual clears it, including if they later return to the old account; if two accounts are merged (duplicates of one company) it carries over. People with a personal email address belong to no account, so the setting doesn't appear for them.

Accounts in your other tools

Every account leaves Mastria with an id your CRM or warehouse can join on. Webhook events name the learner's account (its id, name, email domains, CRM id, type and tags); the learner, certificate, lab-event and quiz-answer exports carry an account_id column; and Export accounts on the Accounts page downloads accounts.csv: one row per account with its domains and the same numbers as the table. Field-by-field details are in Integrations & exports.

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. What follows the person is their display name (set on the My profile page) and their sign-in addresses — the primary and any recovery email: they're the person's, not the academy's data, and the name 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 with a two-step Make primary. 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 (the Merge learners card at its foot): the tool opens with that learner locked as the source, you type the new address — preview, then two clicks. People → Learners has a Merge learners card too, for the email-in-a-support-ticket case where you type both addresses. Progress unions; lab attempts, runs, hint reveals and certificates move; the earlier of the two sign-up sources is kept; and certificate URLs never break. If you use the outbound webhook, a learner.merged event tells your warehouse which learner id and addresses to re-key (see Integrations & exports). A dead inbox can't prove ownership self-serve — but the operator knows their people.