Status

Owner

Eric TRIFFAUX

Stakeholders

Avanade, TDA, 


Decision:

  • Site Name
    • Option A (English translation using SyGPT to keep the meaning and with limitation to 30 characters)
    • to be avoided : Option B (transliteration)
    • Migration-only fallback: Option C (Prefix + drive ID)
    • Adopt proposed naming convention for new site
    • Adopt proposed naming convention for migrated content
  • URL :
    • Option 1 : URL reflects name (normalized version via SyGPT)

Decision made by: Infra TDA

Date:  

Online Meeting: TDA

Decision Context

As part of adopting SharePoint Online, two urgent needs arise:

What should be the strategy for SharePoint site names and URLs?

How to handle unsupported characters or non‑Unicode languages in URLs?

The Technical Advisory Board must validate the long‑term naming & URL strategy because it affects:

Problem Statement

SharePoint Online URLs do not support non‑ASCII characters, such as:

These characters cause:

Therefore, the organization must formally decide:

Architectural Requirements

URL technical constraints (SharePoint Online)

Information architecture constraints

Business & UX constraints

SharePoint Naming convention

Golden rules

New Sites

* Ext and int removed. Only EXT if the site is completely for external vendor or party
*1 : better to create dedicated hub

Workspace Type

Best Use Case

Name

Teams Team

Daily collaboration + chat + files

TEAM-[INT/EXT]-[Dept]-[Team]-[Region]

Teams Standard Channel

Organizing work by topics

[TopicName]

Teams Private Channel

Sensitive sub-team collaboration

PRIV-[Team]-[TopicName]

SP Team Site (Group)

Document collaboration without Teams

SITE-[Dept]-[Team]-[Region]

SP Team Site (No Group)

Highly controlled teams, external collab

SITE-[Dept]-[Purpose]-[Region]

Communication Site

HR/IT/Finance portals

COM-[Domain]-[Region]

Hub Site

Organizing the intranet

HUB-[Dep/Domain/Function] *1

Project/PWA Site

Formal project management

PROJ-[ProjectName]-[YYYY]

Wiki / KB

SOPs, knowledge articles

KB-[Topic]
WIKI-[Dep/Domain/Function]

Home Site

Main corporate intranet homepage

HOME

External Sharing Site

Supplier, customer, partner workspaces

SITE-EXT-[Dept]-[Partner]

Archive Site

Preservation of closed projects or teams

ARCH-[Dept/Project]-[YYYY]

Migrated content

 Follows the standard naming convention when possible with adjustments

In case of library name too long , possibility to contact the owner to rename it using SyGPT totranslate into english to keep the meaning and keep it short

Type

Convention

AODOcs

AO_

SharedDrive

SHD_

Gsites

GS_

Application Sharepoints

APP-

URLs

URL will benefits naming convention

For migration :

Recommended Decision

Options Considered

New Sites

Option A: Reflect the site name in the URL using English translations.

Option B: Where translation is not appropriate use Transliteration

Option C: Migration Strategy (Legacy Shared Drives / AODocs only)

  • Clean syntax
  • Short and consistent
  • Easy to govern
  • Fully compliant with Microsoft’s URL restrictions
  • Enhances user experience, searchability, and automation
Use transliteration to convert unsupported characters into ASCII equivalents.

For migrated content, add the prefix (SHD_ or AOD_) and optionally if Option A not applicable → append the Google Shared Drive ID when the name is ambiguous or unsafe.

Example:
SHD_Finance-A1B2C3D4


Should the Name Be Reflected in the URL?

Option 1 — YES: URL reflects name (normalized version – recommended)

Option 2 — NO: URL uses a generated technical ID

Example:
Site Name: Finance – Contrôle de Gestion
URL: /sites/FIN-Controlling

✔ Advantages

  • Improves findability (people can guess URLs)
  • Consistent with Microsoft 365 naming governance
  • Works well with automation & provisioning
  • Easier audit & support
  • Matches industry best practices
  • Helps avoid orphan or duplicated sites
  • Short, stable naming helps avoid the 400‑char limit

✘ Drawbacks

  • Names must be translated or transliterated
  • Some business units may resist non-native naming
  • Requires an authoritative naming dictionary

Example:
Site Name: Finance – Contrôle de Gestion
URL: /sites/123abcXYZ

✔ Advantages

  • Fully avoids unsupported characters
  • Guaranteed uniqueness
  • Stable even if site name changes

✘ Drawbacks

  • Impossible for users to guess what a URL is
  • Poor user experience
  • Not suitable for enterprise intranet architecture
  • Makes governance and audits harder
  • Not aligned with M365 best practices

How Should We Handle Unsupported Languages?

(Below are the clear options for dealing with non‑ASCII names in URLs.)

Option A — Translate the name to English (using SyGPT for consistency)

Option B — Transliterate the name (convert characters to ASCII)

Option C — Use the Google Shared Drive ID as URL suffix

Example: “Équipe de Gestion” → “ManagementTeam”

✔ Pros

  • Aligns with international corporate standards
  • Guarantees URL compatibility
  • Clean, short URLs
  • Matches most global enterprises’ practices
  • Only requires one corporate dictionary (SyGPT can generate it)

✘ Cons

  • Teams in non‑English regions may feel less represented
  • Requires validation of translations

Example: “Société Générale” → “SocieteGenerale”

✔ Pros

  • Preserves local identity
  • Predictable and intuitive result
  • No need to translate terms
  • Works well with automated rules

✘ Cons

  • Some languages (Arabic, Chinese) transliterate poorly
  • Still requires a dictionary for consistency
  • Risk of ambiguous results

Example: Shared Drive ID = A1B2C3D4/sites/FIN-A1B2C3D4

✔ Pros

  • Perfectly unique
  • Great traceability from migration source
  • No naming conflicts
  • No translation needed

✘ Cons

  • Very poor readability
  • URL becomes meaningless for users
  • Not scalable for future (non-migration) sites
  • Only relevant for migrated content
  • Inconsistent with new SharePoint sites created post‑migration

6. Evaluation Matrix

CriteriaOption A: English Translation ✅Option B: TransliterationOption C: Google Drive ID☑️
User-friendly URLs
Technical compatibility
Works for future sites
Predictability
Readability
Consistency across organization⚠️ depends on language
Migration suitability
Long-term governance fit

See also

The following section describes relevant documentation:

Description

Repository

Naming Convention PPTX