Make every workspace recognisable the moment it's created.
nBold writes one naming standard onto every Teams and SharePoint workspace at provisioning — so every workspace is searchable, traceable, and governed from day one.
Inconsistent names are a tax you pay every day.
A naming standard sounds like housekeeping. In practice it decides whether people can find the workspace they need, whether IT can tell what each team is for, and whether the estate can be governed at all. Without enforcement, the standard lives in a policy document that everyone ignores.
Duplicates multiply
Three teams for the same project, named differently, because no one could find the first one.
Search stops working
Generic names like "New team" surface nothing useful when people search the directory.
Ownership is opaque
A name with no department or owner gives IT nothing to reason about during reviews.
Cleanup never ends
Renaming thousands of workspaces by hand is a project no one ever finishes.
Build the pattern once, apply it to every workspace.
A naming pattern combines fixed text with dynamic tokens that nBold interpolates at provisioning — drawing values from the template, the request form and the requester’s Microsoft 365 profile.
Prefix
A fixed marker that groups related workspaces — for example a project code, a business line or a region — so they cluster together in search and directory listings.
Team type
The category of workspace being provisioned — project, deal room, customer account, crisis cell — drawn from the template so the name signals purpose at a glance.
Department
The requester’s department, resolved from their Microsoft 365 profile, so ownership and provenance are legible without opening the workspace.
Requester
The name of the person who requested the workspace, captured at provisioning — useful for audit, accountability and follow-up.
One pattern, Teams and SharePoint together
nBold provisions the Team and its connected SharePoint site — or a standalone SharePoint site — from a single template. The naming convention applies consistently across both, so a workspace and its document estate carry the same recognisable identity wherever people encounter them.
From ad-hoc to predictable.
The same pattern, resolved at provisioning, turns whatever a requester would have typed into a name your whole organisation can read.
| What people type without guardrails | What nBold provisions |
|---|---|
| Project Alpha | PRJ-Sales-Alpha-2026 |
| New team (3) | DEAL-Acme-Renewal-jdupont |
| Test final FINAL | OPS-Finance-Q2-Close |
Resolved names are written before the Team and SharePoint site are created — the standard is enforced from the first second, not corrected later. Pair it with rename guardrails so the convention holds across the workspace’s full lifecycle.
How enforcement works.
No manual review queue, no after-the-fact corrections — the pattern resolves itself the moment a workspace is requested.
Define the pattern on the template
Set the naming pattern once on each workspace template — fixed text plus the dynamic tokens that matter for that type of workspace.
A user requests a workspace
Through the request form, the requester provides the inputs the pattern needs; their department and identity come from their Microsoft 365 profile automatically.
nBold resolves the tokens
Every token is interpolated against the template, the form and the profile, producing the final, compliant name.
The workspace is provisioned, correctly named
The Team and SharePoint site are created under the resolved name — searchable and organised from the start, with no cleanup needed.
Part of the wider governance layer.
A naming convention is one guardrail among several. nBold applies it alongside audience targeting, membership rules, sensitivity labels and lifecycle — all per template, so governance travels with every workspace you provision.
Governance
Naming, labels, membership, approvals and lifecycle — applied per template across the estate.
Explore GovernanceAudience targeting
Publish each template to the right people, so the right naming standard is applied to the right workspaces.
Explore Audience targetingMembership policy
Control who joins, who owns and who can rename — keeping the convention intact over the full lifecycle.
Explore Membership policyFrequently asked questions
When is the naming convention applied?
At provisioning time. When a workspace is requested from a template, nBold resolves each token in your naming pattern and writes the final name before the Team and SharePoint site are created — so the standard is enforced from the first second, not corrected after the fact.
What tokens can I use in a naming pattern?
Patterns combine fixed text with dynamic tokens interpolated at provisioning — for example a fixed prefix, the team type, the requester’s department, the requester’s name, and a date. The resolved values come from the template, the request form and the requester’s Microsoft 365 profile.
Can users override or rename the workspace afterwards?
You control that with guardrails. The naming pattern is enforced at creation, and you can restrict who is allowed to rename a workspace so the convention holds across its full lifecycle rather than drifting after creation.
Does the naming convention cover SharePoint as well as Teams?
Yes. nBold provisions Teams and SharePoint from a single template, so the naming standard applies consistently across the Team, its connected SharePoint site and standalone SharePoint sites — one convention across the estate.
Can I apply a naming standard to workspaces created before nBold?
New workspaces are named at provisioning. For an existing estate, bulk operations let you attach an nBold governance template — including the naming convention — to workspaces created before your policies were in place.
Make every workspace findable again.
See how nBold enforces a single naming standard across every Teams and SharePoint workspace in your tenant — without a cleanup project.