Username policies — build a custom username format for a school or trust

Username policies is where Realsmart builds a custom username format for a specific school or trust — a safe copy of the shared format ADAdmin normally uses, changed without affecting any other school. Schools and trusts can't build their own policies yet — this page is currently a Realsmart-only tool.

Who can see this {#step-1}

Same gate as Platform apps, Beacon access, Vibe access and SmartLogin SPs: it only appears in the sidebar (under Platform) when you're a full-access admin actively working within the Realsmart platform school — not MAT overview, and not any other school. Schools and trusts never see it.

What a username policy controls {#step-2}

Every student and staff account gets its ADAdmin username worked out automatically during sync — built from a fixed formula (a username policy) rather than typed in by hand. Most schools share one of around 200 standard formats that Realsmart maintains centrally; editing one of those directly would change usernames for every other school using it too.

A custom username policy is a school- or trust-specific copy of that formula, built with the segment builder instead of hand-written. It doesn't touch the shared standard formats other schools use — only the school (or trust) it's built for, and only once you assign it.

Two tabs: Schools and Custom policies {#step-3}

The username policies page opens on the Schools tab: every school you're authorised for, listed with whichever policy is actually in effect for its student and staff usernames right now — labelled Central (one of the ~200 shared formats) or Custom (a policy built here). This is "what's really happening" for a school, not just a list of the custom policies that happen to exist.

A school still on its central policy shows a Create policy shortcut in that row — it opens the builder with that school already picked, ready to test against. A school already using a custom policy shows Preview and Edit instead, taking you straight to that policy.

The Custom policies tab is the management view of the pool itself: every custom policy you've built, its status (draft, active, or archived), how many schools currently use it, and actions to duplicate, archive, or assign/unassign it from a school. Use this tab when you're managing an existing policy rather than starting from a school.

The segments a username is built from {#step-4}

A policy is a stack of segments, placed left to right to build one username. The available segments are:

First name — the person's first name, in full or just its first few letters.
Surname — their surname, in full or just its first few letters.
Year of entry — a short number for the academic year they joined (see below) — two digits ("09"), four ("2009"), or one ("9").
Year of exit — a short number for the academic year they're due to leave, using the same digit options as year of entry; you tell it the final year group students leave in (see below).
MIS ID — the reference number held in your school's management information system, in full or just its last few digits.
Staff code — a staff member's own identifying code (sometimes called a UPN).
Text — a fixed bit of text you choose, such as a "." separator or a short prefix.
Number — added automatically, and only when it's needed, to keep two people from ending up with the exact same username (jbrown, then jbrown2, jbrown3, and so on for the next person it happens to).

Everything is lowercased automatically. You can also switch on cleanup, which strips spaces, apostrophes, and hyphens out of names before they go into the username — so "O'Brien" becomes "obrien" and "Mary-Jane" becomes "maryjane" — and set an optional overall maximum length.

When the academic year switches {#step-5}

A student's year-of-entry number (the "09" in a username like jbrown09) is based on which academic year they joined in — not the calendar year. Any format using year of entry or year of exit therefore has to know when one academic year ends and the next begins.

That boundary comes from the school's own provisioning window, not from a fixed date in the calendar. The year the window's closing date falls in is the academic year the school's data belongs to, and the automatic roll-forward that runs when a school resumes moves that closing date on by a year. So the switch to new-year digits happens in the same breath as the school's new-year MIS data starting to arrive — whenever that actually is for that school. This applies to every school's username formula, standard or custom.

What that means in practice:

A school that rolls its MIS early and resumes in June or July gets new-year digits from its resume date, so its September intake is provisioned as next year's students. This is the case a fixed 1 August rule gets wrong.
A school still frozen past 1 August keeps the old year's digits until it resumes — which is right, because while frozen no new MIS data has been pulled in, so its year groups are still last year's.
Everywhere else nothing changes. Inside a normal window, the school's window and the calendar agree, so the digits come out the same either way.

Accounts released early during a freeze. A frozen school can create accounts for new staff and accepted pre-admission students ahead of resume, using Release early accounts on its End of year page. Those usernames are built the same way as any other, from the school's own window — and for an accepted applicant the result already carries the year they are joining in, not the year that is ending. Two things follow: the school's year group they are in now setting has to be right before anyone is released, and a username created that way is permanent like any other, so correcting one afterwards is a rename, not something the next sync fixes. See Release early accounts during the freeze.

Each year of entry and year of exit segment still carries an Academic year switches in month, set to August. That is now the fallback: it decides the boundary only for a school whose provisioning window can't be trusted — no closing date set, or one so far out of date it was clearly never rolled forward. Leave it on August unless the school works to a different administrative calendar.

Students join in Year 7 {#step-6}

The builder needs to know which year group your newest arrivals join in, so it can count backwards from a student's current year group to work out the academic year they actually joined. Most secondary schools set this to Year 7; a primary school would typically use Reception, and a sixth-form-only setting would use Year 12. Get this right for your school and the year-of-entry number will be accurate for every student, not just this year's newest intake.

The year of exit segment works the same way but from the other end: instead of the intake year group, you set the final year group — the year group students leave in. Use 11 for a GCSE-only secondary, 13 for a secondary with a sixth form, and 6 for a primary school. The builder counts forward from a student's current year group to work out the academic year they're due to leave, so getting the final year group right makes the year-of-exit number accurate for every student.

Start from the school's current policy {#step-7}

Rather than building a format from nothing, you can import the one a school already uses today as your starting point — pick the school, then choose Import current student policy or Import current staff policy. This reads the school's existing format and turns it into segments you can then adjust.

This works automatically for most of the formats already in use. A minority of older, more bespoke formats use special-case rules the builder can't translate automatically — for those, importing just starts you with an empty builder and a plain on-screen note explaining that the current policy couldn't be imported, so you build the equivalent from scratch using the segments above.

Preview before you save {#step-8}

While you build, the Live example panel shows what the format would produce for a handful of real, active people at the chosen school — students, staff, or a few of each when the policy is for both. It answers "what would this look like?", so it deliberately ignores the fact that most existing usernames are locked after their first sync: it always shows the name the formula would build, next to the one the person has today.

Run full school preview (under the live example) scales that up to every active student or staff member at the school — including the automatic numbering when two people would collide — without saving anything first. Filter it to just the accounts that would change, the ones that wouldn't, or the ones with warnings. Like the live example, it ignores username locks, so it shows the full effect of the format rather than what the next sync would really rename.

Before any changes reach a school's real usernames, use Preview to see exactly what would happen — it's read-only and never changes anything itself. Unlike the live example, this respects username locks and protected accounts, so it is the accurate prediction of the next sync. It also works out year-of-entry and year-of-exit digits from the school's provisioning window exactly the way the sync will (see above), so a preview run over the summer shows the year the next run would really use, not a calendar guess. Preview compares every account's current username with what the new format would produce, and sorts every account into one of four groups:

Unchanged — the new format produces the exact same username the account already has, so nothing would happen to it.
Changed — the username would be different. This is what actually gets renamed if you go ahead and assign the policy.
Unaffected — the account is never touched, whatever the format produces. This covers protected accounts, accounts whose username is already locked, accounts that aren't active (left, suspended, or deleted), and accounts of the other member type (a student policy never touches staff accounts, and the other way round).
Warnings — something worth a second look before you rely on the preview: for example, two people who'd otherwise end up with the exact same username (an automatic number was added to tell them apart), a name field that's blank so no username could be built, or a new username that would clash with an existing group name.

Use the school picker and the student/staff tabs at the top to check every combination a policy will actually be used for.

Assigning a policy {#step-9}

A custom policy only affects real accounts once it is both active and assigned to a school — saving a draft never changes anything on its own.

Assigning sets a school to use the policy for student usernames, staff usernames, or both, from the provisioning service's next run — not immediately. When that run happens, every account whose username would change is renamed, and — this is the important part — that rename carries through to every platform the account is connected to, not just ADAdmin: Google Workspace, Microsoft Entra, Apple School Manager, and Active Directory. Anyone who signs in with the old username or email address will need to switch to the new one. Assigning and removing a policy are both confirmation-gated for exactly this reason — read the warning before you continue.

Removing a custom policy from a school reverts it to the standard shared policy it used before, on the same next-run timing, with the same rename warning in the other direction.