Staff Roster & Account Classification

One authoritative answer to "who counts as staff?" - so all-staff audiences stop needing a quarterly manual pass. Last updated 2026-07-25

What problem this solves

Several TATER features need to resolve the phrase "everyone on staff" into a concrete list of people: the all-staff signer audience on Document Reviews, training campaigns, survey distribution, and the independence attester roster.

A directory alone answers that badly. A typical M365 tenant contains far more enabled, licensed mailboxes than it has employees:

• Admin variants - a second privileged account for the same human (jsmith-a@, jsmith+admin@)
• Service and system accounts - backup agents, integration principals, msadmin@
• Outside parties on the internal domain - a contractor or vendor issued a company mailbox
• Owner, family, and board accounts - real mailboxes belonging to people who are not employees
• Departed staff - accounts still present because deletion would destroy historical records

Send a mandatory handbook acknowledgement to that raw list and you get a compliance report full of rows that will never be completed, and a real chance of missing the people who genuinely needed to sign. The Staff Roster is the single place where that judgement is made once and then reused everywhere.

Where to find it

Open TATER Ops → Independence → Staff Roster. Admin role is required. Reading the roster and changing it are separate permissions, so a coordinator can be given visibility later without gaining the ability to change who counts as staff.

The five account classes

Class	Counts as staff?	Meaning
internal-staff	Yes	An employee. This is the default when nothing indicates otherwise.
non-staff	No	A real person with a real mailbox who is not an employee - owner, family member, board member. Manual only (see below).
external	No	Consultant, vendor, contractor, or directory guest.
service	No	A service, system, or integration principal rather than a person.
admin-variant	No	A second, privileged account belonging to someone who already has a primary account.

How a verdict is reached

Every account gets a verdict from one of two sources, and the roster always shows which:

1. Manual - a human decision, recorded and stored. Always wins.
2. Automatic - computed from the account's attributes at read time.

Only manual decisions are stored. Automatic verdicts are recomputed every time the roster resolves, which means that when you correct your internal-domain list or turn a heuristic on, every affected account re-resolves immediately. A cached automatic verdict would quietly go stale and recreate the very drift this feature exists to remove.

What the automatic heuristics look at

In precedence order:

• A per-membership external / guest flag
• An explicit always-external email list
• An internal-domains allow-list miss - an address outside your own domains
• Address shape - admin suffixes (-a, -adm, -svc), plus-addressed variants (name+admin@), service prefixes (svc-, msadmin), and outside-party suffixes (-ext, -vendor, -contractor)
• Display name - tokens such as [Admin], SVC -, Vendor, Consultant, (External)

Display name matters more than it sounds. A contractor issued rbogue@yourcompany.com has an address indistinguishable from an employee's - the only automatic signal that they are an outside party is a display name reading "Robert Bogue (Thor Projects Consultant)".

What no rule can detect

Owner, family, and board accounts are typically enabled, licensed, on the internal domain, and named exactly like everyone else. No heuristic can identify them - there is genuinely no signal to read. This is why manual classification exists and why non-staff is a manual-only class. Expect a small one-time pass to mark these accounts; the decisions persist, so it is not recurring work.

Recording a manual decision

On the roster, choose a class for the account and give a short reason. The reason is shown to anyone reviewing the roster later and is the difference between an auditable decision and an unexplained exclusion - "owner, not an employee" is worth typing.

To undo, set the class back to Auto. That clears the override and returns the account to whatever the heuristics compute, rather than pinning it to a guess.

Departure tombstones

When someone leaves, their roster entry is tombstoned, never deleted. A tombstoned account is excluded from all future audiences but remains resolvable, so historical attestations still show who signed and when. Deleting the record would silently damage completed compliance evidence.

Tombstones are keyed by organization and email, so if someone is rehired - or a directory sync briefly loses sight of them - the reappearance clears the tombstone instead of creating a duplicate identity.

Entra directory sync

Sync reconciles the roster against your Entra directory in both directions: it enrols staff who exist in the directory but not in TATER, and tombstones accounts that have left the directory.

Dry run first

Sync is a dry run by default. It reports exactly what it would enrol, tombstone, and skip - and writes nothing. Read that report before applying it. The delta is the interesting part, and you want to see it before it happens.

What sync will not do

These limits are deliberate. The dangerous direction is tombstoning, because a partial or failed directory read makes every employee look departed:

• It refuses to tombstone anyone unless the directory read was provably complete. An incomplete or empty read disables departures entirely rather than acting on partial data. Enrolment is unaffected - adding a member from a partial read is easy to undo; mass-departing an organization is not.
• It matches every address an account answers to, not just the primary. Someone whose directory primary is @yourcompany.com but whose TATER membership uses a @vanity-domain.com alias is the same human, and matching only the primary would mark an active employee departed.
• It will not tombstone an address on a domain your directory does not contain. External signers invited into TATER live there by invitation, not by directory membership - their absence from your internal directory says nothing about whether they departed.
• It never enrols guests, and it will not enrol accounts that classify as service, admin-variant, or labelled-external. Granting a backup service account a seat in a compliance platform is not a reasonable side effect of a roster sync. These appear in the report as skipped, with the reason, so you can override any of them by hand.
• It only enrols when your organization has opted in to automatic provisioning (the same setting that governs what role a first-time visitor receives). With that setting unset, sync reports the delta and writes nothing.

What role synced accounts receive

Exactly the role a first-time visitor to your organization would get - your configured auto-provision role, defaulting to Viewer. Sync is not a privilege-granting path.

Permissions required

The tenant credential app used for scanning needs Microsoft Graph User.Read.All (or Directory.Read.All) granted as an application permission with admin consent. Sync checks this before it calls Graph, so a missing grant is reported as a named permission rather than an opaque failure.

API and MCP

Surface	Purpose
GET /staff-roster	Every member with its resolved verdict, source, reason, and counts
POST /staff-roster/classify	Record or clear a manual classification
POST /staff-roster/directory-sync	Reconcile against Entra. Dry run unless {"dryRun": false}

All three are Admin-only and audit-logged. See API Reference and MCP Setup.

Troubleshooting

Symptom	Cause
Roster says "not configured" and everyone counts as staff	No Signer Audience configuration saved. The heuristics are dormant until internal domains are set.
Sync reports enrolments but zero tombstones, with a blocked reason	Working as designed - the directory read was not provably complete, so departures were refused. Resolve the read problem, then re-run.
Sync wants to enrol accounts that are obviously not people	Their address and display name carry no recognisable marker. Classify them manually once; the decision persists.
A real employee appears in the tombstone list	Their TATER membership email is probably an alias absent from the directory. Confirm the address exists as a proxy address in Entra.
Sync reports a missing permission	User.Read.All has not been admin-consented on the tenant credential app.

Related

• Document Reviews & Acknowledgements - the main consumer of the all-staff audience
• Independence Management - attester roster and departed-staff handling
• Settings Reference - Signer Audience configuration