Almost every framework that touches a security or compliance program starts with the same question: who works here, and how do we know? SOC 2 calls it out in CC6.2 (registration and authorization of internal users prior to issuing system credentials). ISO 27001:2022 carries it in A.6.1 (screening of personnel), A.6.5 (responsibilities at termination or change of employment), and A.5.16 (identity management). HIPAA’s Workforce Security rule (§164.308(a)(3)) requires documented authorization, supervision, clearance, and termination procedures. The auditor will pick a name off the wall, then expect you to answer where did this person come from, when did they show up, and what happens when they leave — without rifling through chat threads to find the answer.
Most teams handle workforce data by writing it in two places at once — an HRIS, a directory, a spreadsheet — and hoping the lists agree. They never do. Names that left months ago still show up in audits. New hires don’t appear until someone adds them. “Who is Sam Taylor?” turns into a half-hour search through chat and email. Talarity treats the workforce roster as a deduplicated view across the ingestion paths that actually feed it, and stamps every row with its source so the question takes one second.
Who’s involved
- HR / People Ops — owns the joiners, leavers, and changes; adds non-employee contractors who don’t have a Microsoft account.
- IT admin — owns the Microsoft directory connector; new hires Microsoft provisioned, and leavers Microsoft disabled, should both surface in Talarity without a hand-off.
- Compliance lead — pulls the roster at audit time, slices it by source to explain “who came from where,” and confirms terminated workers are actually terminated.
What’s on the page
Open the workforce roster (/app/workforce):
- The roster table — one row per joiner / leaver / contractor, each carrying a Source badge (MANUAL / INTUNE (or ENTRA ID) / ORG LOGIN) and a status, with inline status / type filters.
- + Employee — the manual-add modal (first/last name, email, title, type, status).
- View selector — three system presets (Active humans only, Hide external (#EXT#) accounts, Hide service accounts) plus your org’s saved/shared views, one pinnable as the default.
- ⚙ Filter modal — an AND/OR rule builder over the roster’s typed columns, plus Always include / Always exclude override lists and Save as new view (with share + set-as-default).
Step 1 — Open the workforce roster
/app/workforce is the canonical roster — every joiner, leaver, and contractor in your program. The page has the usual filters at the top, plus one column on the right you might not have noticed before: Source.
The badge on every row is the answer to “where did this name come from.” Three colours, three ingestion paths. Talarity stamps the source on the row at write time — the badge is a static, queryable fact, not a guess.
Step 2 — Manual roster adds
The classic HR path. Click + Employee in the header and the modal collects the minimum a roster row needs — first name, last name, email, optional title and type (employee / contractor / intern / vendor) and status. (If the employment type has default onboarding bundles, a checkbox here applies them on create — assigning standard assets and queuing policy acknowledgements.)
Fill it and Add Employee. The row lands in the roster with a MANUAL badge — Talarity stamps source_system = 'manual' on the record so an auditor can later distinguish “the HR team typed this person in” from “Microsoft told us this person exists.”
Manual is the right path when the person doesn’t have a Microsoft account — contractors who use their own email domain, auditors visiting for a quarter, the office manager at a one-person remote site. Every other path needs an upstream identity; manual is the catch-all when none exists.
Step 3 — Microsoft Graph (Intune / Entra ID) sync
This is the source most teams don’t fully understand — and the most common cause of “who is this person?”
When you connect Talarity to your Microsoft tenant (the same connector that pulls device inventory), the sync also fetches /v1.0/users from Microsoft Graph and upserts every account it finds into the workforce roster. Every row that lands carries an INTUNE badge (or ENTRA ID if the connector is configured for Entra-only). Status mirrors the directory: accountEnabled = true lands as Active; accountEnabled = false flips the row to Terminated — the same direction Microsoft is signalling.
The directory pulls everyone, not just employees. Microsoft Graph’s
/v1.0/usersendpoint returns every account in the tenant — full-time staff, contractors with a corporate identity, service accounts, accounts from a since-acquired subsidiary that nobody got around to clearing, and a long tail of test accounts named after old projects. If you see a name in your Talarity roster you don’t recognise, the answer almost always is Microsoft still has it. The fix is in your Microsoft admin centre, not in Talarity: disable the account upstream, and the next sync flips the row to Terminated automatically.
A name with a purple INTUNE badge is Microsoft’s authoritative truth. To remove it, off-board on the Microsoft side first. The reverse is also true — re-enabling a disabled Microsoft account flips the Talarity row back to Active on the next sync. Disabling and re-enabling are mirror operations.
Step 4 — Login users who haven’t been added to the roster yet
Talarity has three identity surfaces — the workforce roster (joiners, leavers, contractors), the org_users table (people who can log in to the application), and the Microsoft directory (everyone in your tenant). Most rows in the roster also exist as login users — but some logins exist only as logins, not yet attached to a workforce row. A new admin you invited last week. An auditor with a guest account. A contractor who got an app login before HR got around to adding them to the roster.
Those orphaned logins surface as candidates in the Talarity workforce picker. When you assign an asset to someone who has a login but no employee row, you’ll see them in the picker with an “Account only” badge — selecting one (clicking the candidate row) writes a new employee row with source_system = 'login' and the green ORG LOGIN badge, pointing back at the original org_users record. The login and the employee row are linked from then on; any subsequent Microsoft sync or manual edit operates on the same canonical employee.
This is the path the article walkthrough used for Riley Carter, Morgan Lee, and Priya Shah — they had Talarity logins from earlier articles, but no workforce row. One materialize call each, and they’re in.
Step 5 — CSV bulk import (on the roadmap)
The fourth ingestion path is a CSV upload — “here’s our HRIS extract, load it”. It’s the right answer for orgs whose HRIS doesn’t expose a directory connector, and for one-time migrations from a previous tool. CSV bulk import isn’t shipped yet; it’s on the workforce roadmap. The three sources above cover every active path today.
Step 6 — Filtering the noise out: views, presets, and include/exclude lists
Knowing where each row came from is half the answer; the other half is not having to look at the rows you don’t care about. Talarity’s roster carries a saved-view system that lets every coordinator pick the slice that fits their work, save the slice as a named view, share it with the org, and pin one as the default everyone sees by default.
The view selector sits between the inline status / type filters and the + Employee button. Open it and the dropdown is a single flat list — presets first, then your saved views — covering:
- All employees (no view) — the unfiltered roster, every row from every source.
- System presets (3) — Active humans only, Hide external (#EXT#) accounts, Hide service accounts (heuristic). These ship in code, can’t be deleted, and update with each Talarity release.
- Saved views — anything your org has built, marked (mine) for the ones you authored.
Picking a preset applies it to the current view immediately — no save, no commit. The roster header shows chips for the active filter — the rule count (e.g. “2 rules”), plus any +N always-include / −N never-exclude overrides and a Clear filter button — so it’s never ambiguous that a filter is in force.
The three system presets are the answer to 80% of “make the roster less noisy” questions. Most orgs don’t need anything else for day-one usability — Active humans only hides terminated and externals; Hide externals hides Entra B2B guests; Hide service accounts hides veeam / alerts@ / wordpress / noreply by email-substring match. Reach for a custom view when the preset gets you 80% of the way and you need one more rule.
Step 7 — Build a custom view with the filter modal
Click the ⚙ Filter button to open the full rule builder. The modal exposes three things the preset dropdown doesn’t:
- A custom rule tree — AND/OR groups of field/operator/value rules over the roster’s typed columns (employment_status, employment_type, email, title, source_system, location, hire_date, …).
- Always include — a list of specific employees who should always show in this view regardless of what the rules above say. This is how you whitelist “the system account that’s actually a real person.”
- Always exclude — the mirror, for the “yes, the heuristic flagged this as a service account but Sandra in Finance owns this mailbox and I never want to see her here” case.
The override semantics are load-bearing. Rules are patterns; the include/exclude lists are exceptions. A coordinator who wants “Active humans only, but always include ops@talarity.com (who’s a real human despite the platform-y email) and never include the contractor-mailbox account” can express exactly that without rewriting the rule tree.
Always include overrides Always exclude overrides Rules. Order matters: a row that matches the always-include list shows, even if the rules would have hidden it. A row that matches the always-exclude list hides, even if the rules would have shown it. Reach for include when the heuristic under-classifies a real person; reach for exclude when the heuristic over-classifies a noise account.
Step 8 — Save the view, pin a default, share with the team
The footer’s Save as new view opens an inline panel — no second modal, no separate page — with the three knobs that turn a one-off filter into a durable team view:
- View name — what shows in the dropdown afterwards.
- Share with everyone in my org — makes the view appear in every coordinator’s dropdown, not just yours.
- Set as my default view — Talarity loads this view automatically every time you open
/app/workforce. - Set as the default for everyone in my org — the same, but for every user who hasn’t picked their own. Org-default is shared automatically (the option implies the share toggle).
Two defaults coexist by design:
- My default is per-user. Each coordinator picks their own. The compliance lead defaults to Active humans only; the HR director defaults to a custom Joiners this quarter view; the IT admin defaults to the unfiltered roster.
- Org default is the floor. If a user hasn’t picked their own My default, the org default loads. The compliance officer with admin rights pins Active humans only as the org default, and from then on every new coordinator opens the roster not seeing terminated employees by default — without having to remember to apply a filter every time.
The compounding effect is the load-bearing detail: a coordinator joins the team, opens the roster for the first time, sees the org-default view, and doesn’t even know they’re looking at a slice — they’re just looking at “the roster.” Which is the right thing — the noise is filtered out before the noise was a problem.
What the Source column unlocks
The column itself looks small. The patterns it surfaces are not.
- “Why is this person here?” is one second of scanning. Manual = HR added them. Intune = Microsoft has them. Org login = they had a Talarity account before HR finished the paperwork.
- “Why is this person still here?” is the same question, inverted. An Intune-source row with status Active means Microsoft still considers the account live; the fix is in your Microsoft admin centre. A manual-source row with status Active means HR hasn’t off-boarded them; the fix is in Talarity.
- “Where do my contractors actually live?” A manual row pattern tells you the population HR is tracking directly. An Intune-source row for someone in Customer Success means their account is in Microsoft. Mixed-source rosters are normal; knowing the mix is what lets you split tooling responsibilities cleanly.
- Termination drift is visible. An Intune-source row carrying status Active when the person has been gone for months means a Microsoft account that was never disabled. The roster’s Status × Source slice surfaces that gap before an auditor finds it.
What you walk away with
- One roster that aggregates every ingestion path — manual, Microsoft Graph, login-only materialization — into a single view.
- A per-row Source badge that names which path put the row there, in colour, with the same query semantics every other roster field has.
- Status that mirrors Microsoft for Intune/Entra rows — disabling an account upstream terminates the Talarity row on the next sync; re-enabling re-activates it.
- A way to explain unfamiliar names in one second instead of half an hour, and the right place to fix each kind of stale row (your Microsoft tenant vs. Talarity vs. the candidates picker).
- Three system presets that hide the obvious noise on day one — terminated + external + service-account accounts — plus a custom-rule modal with Always include and Always exclude override lists for the edge cases the heuristic doesn’t catch.
- A personal default view for each coordinator and an org-default view for everyone who hasn’t picked their own, so the right slice loads automatically instead of needing to be applied every time.
Open /app/workforce and scan the Source column. Look for any row whose source surprises you. Then open the view selector, pick Active humans only, and notice how much of the surprise was just noise the org-default would have already hidden.