F1, F3 and the frontline licences nobody maps correctly

Every tenant with a warehouse, a shop floor or a shift rota has the same line in it: sixty people on the same enterprise seat as the finance team, because that was the seat the tenant was bought with and nobody has revisited it since. The fix is well known and rarely executed, and when it is executed it usually breaks something — because "frontline" got mapped from a department column instead of from what those users measurably do.

The numbers below are the ones that decide it. Two come from Microsoft's own limits tables and are fixed. Two come from report columns any tenant can produce this afternoon.

2 GB is the number that decides most of it

Microsoft's mailbox storage table is blunt about the F tier. Where Microsoft 365 Enterprise E3/E5 gets a 100 GB user mailbox and a 1.5 TB archive, Office 365 Enterprise F3 gets 2 GB and "Not available" in the archive row. The capacity alerts land at 1.96 GB (warning), 1.98 GB (prohibit send) and 2 GB (prohibit send and receive).

Read that as an operational fact rather than a spec line: a user whose mailbox is at 14 GB does not "get smaller" when you change their licence. They stop being able to send, then stop being able to receive, and the helpdesk ticket arrives with no obvious connection to the licence change three days earlier. Archiving your way out isn't included either — for the F tier the archive is a separate Exchange Online Archiving purchase, which eats the saving you just made.

So the first filter isn't a job title. It's one column of one report: Storage Used (Byte) from getMailboxUsageDetail, next to Has Archive. Anyone over roughly 1.5 GB is not a candidate today, whatever their badge says.

+0 GB — the tenant storage the swap quietly takes back

This is the one that surprises people twelve months later. SharePoint's limits table gives the enterprise plans "1 TB + 10 GB per license purchased". The column covering Microsoft 365 F1/F3 and Office 365 F3 reads, in full, "1 TB". No per-licence increment.

Move sixty seats from E3 to F3 and the tenant's SharePoint storage entitlement drops by 600 GB on the same day the invoice drops. Nothing fails immediately; the pool just got smaller while the content in it didn't. If the tenant is already at 80% of quota, the licensing project has become a storage project, and the warning that arrives is about sites going read-only rather than about licences.

The four measurements that name a frontline worker

Microsoft's own definition is behavioural, not organisational. Its frontline page describes these users as people who "often work on tablets or phones and work either directly with customers or the general public", and draws the line explicitly: frontline workers "have Microsoft 365 apps on phones or tablets", information workers "write, edit, and share documents and have Microsoft 365 apps on desktops or laptops".

That distinction is measurable, and the report that measures it is the one nobody runs. getOffice365ActivationsUserDetail returns, per user, columns named Windows, Mac, iOS, Android, Last Activated Date and — the interesting one — Activated On Shared Computer.

Both reports need one permission — Reports.Read.All — and both return a CSV via a 302 redirect to a short-lived download URL, which is why they tend to live in a script somebody wrote once rather than in anyone's monthly routine.

Where the mapping actually breaks

Mapping by department. "Warehouse" contains the warehouse manager, who lives in Excel on a laptop. Departments are a shortlist, not an answer; the activation columns are the answer.

Mapping by name. There are three products in play whose display names differ by one character — Microsoft 365 F1, Microsoft 365 F3 and Office 365 F3 — and the string your tenant reports is a part number, not a display name. The subscribedSku resource gives you skuPartNumber ("for example AAD_PREMIUM or RMSBASIC"), and the F-family part numbers are not derivable from the marketing names. Look the row up in Microsoft's product names and service plan identifiers table before you write the filter. A script that guesses this reports beautifully on the wrong SKU.

Mapping the seat pool instead of the people. /subscribedSkus tells you consumedUnits against prepaidUnits. It cannot tell you whether any of those consumers should be on a cheaper seat, which is why a licence waste audit and a frontline mapping are different exercises with different inputs.

Ignoring the term. The decision to downgrade and the opportunity to downgrade are not the same date. On an annual commitment those sixty E3 seats are yours until renewal whether anyone signs in or not — see annual versus monthly commitment. Do the mapping anyway, and hold it against the renewal date; a list that's ready when the window opens is worth more than one built in the week it closes.

Make it a fit test, not a job title

The useful artefact here is not a licensing spreadsheet. It is a per-user view with four columns on it — desktop activations, mobile activations, shared computer, mailbox size — sorted so the candidates float to the top, and recomputed every month because people change roles and mailboxes grow.

That is three Graph reports joined on userPrincipalName, and the reason it doesn't exist in most tenants is that each report is a CSV behind a redirect, and nobody wants to own the script that stitches them.

GraphPaaS collects the activation, mailbox and licence reports per tenant on a schedule and keeps them joined per user, so "who actually fits an F seat" is a sorted table rather than an afternoon.