More results...

Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
Search in posts
Search in pages
docs
betterdocs_faq

User Account Name Format Type

Updated on July 2, 2026

8 min to read

Overview

The User Account Name Format Type is a configuration setting that controls which form of a person’s name Classter writes to their user account profile whenever that person’s first name or last name is updated in the system.

In Classter, each user (Student, Teacher, or Partner) has two layers of name information:

  • Their personal record — which stores the official name entered by the institution.
  • Their user account profile — which holds the name visible in the portal and sent to connected external platforms.

This setting defines the exact name format that is copied from the personal record into the account profile at the moment a name change is saved.

The setting is particularly relevant in the following situations:

  • Names are stored in non-Latin characters (such as Greek, Arabic, or Cyrillic) but external platforms require Latin-only text.
  • The institution uses grammatically declined name forms (Inclinations) for official documents and also wants those declined forms reflected in user accounts.
  • User accounts are synchronised with third-party platforms such as Microsoft 365, Moodle, or other integrated systems, and name consistency across all systems is required.

The default behaviour is to use the name exactly as entered — no conversion or transformation is applied.

 

 

Where It Is Used

Navigation Path

Core Settings  >  Security Settings  >  Accounts & Roles

 

Scope

  • The setting is configured at the institution level (per Company). In a multi-site organisation, each branch or campus can be configured independently.
  • Applies equally to all three entity types: Students, Teachers, and Partners.

 

When It Is Triggered

  • Automatically when a person’s first name or last name is changed and saved in Classter.
  • The resulting formatted name is written to the user’s account profile (first name and last name fields).
  • If the institution has active integrations with external platforms, the same formatted name is sent to those systems during user synchronisation.

 

When It Does NOT Apply

  • When only other fields are updated (address, phone, email, etc.) — this setting is only triggered by first-name or last-name changes.
  • Changing this setting does not retroactively update existing user account names. The new format applies only from the next name-change event onward.

 

Configuration / Fields Analysis

This is a single-select dropdown field. Only one option can be active at a time. The selected option takes effect on the next name-change event for any user.

#

Option

Behaviour

1

Entity’s Name (Default)

Uses the standard first and last name exactly as stored in the person’s record. No transformation is applied. No additional configuration is required. This is the system default.

2

Entity’s Name to Latin

Automatically converts the name from non-Latin characters to their closest Latin equivalents using phonetic transliteration. The conversion is based on phonetics — it does not translate the name but renders it in the Latin alphabet. Useful when integrated external systems do not support non-Latin characters. No additional configuration is required beyond selecting this option.

3

Other Name 1

Uses the first pre-configured alternative name form (Inclination 1) for the person, in the institution’s default language, without capital-case formatting. Requires the Inclinations feature to be populated for each person. Falls back to the original name if no inclination is found.

4

Other Name 2

Uses the second pre-configured alternative name form (Inclination 2). Same language and casing rules as Other Name 1.

5

Other Name 3

Uses the third pre-configured alternative name form (Inclination 3). Same rules apply.

6

Other Name 4

Uses the fourth pre-configured alternative name form (Inclination 4). Same rules apply.

7

Other Name 5

Uses the fifth pre-configured alternative name form (Inclination 5). Same rules apply.

 

Understanding the Inclinations Feature (Other Name 1–5)

Classter includes a feature called Inclinations (also referred to as Name Cases or Name Forms in some contexts). This feature allows an institution to store up to five alternative name forms for each person.

This is relevant in languages where names are grammatically declined — meaning the name changes its ending or form depending on its grammatical role in a sentence. Greek is the most common example: a person’s name in the nominative case (e.g. as a subject) differs from the genitive case (e.g. in a “of” context) or the vocative case (when addressing the person directly). These different forms are the five Inclination slots.

Each set of inclinations is associated with a specific language. When an “Other Name” option is selected in this setting, Classter:

  1. Looks up the inclination number selected (1 through 5) for that person.
  2. Selects the version that matches the institution’s configured Default Language.
  3. Uses the non-capital-case version of the name.
  4. If no inclination is found, falls back to the original name.

Note: Inclinations must be entered individually for each person in their profile. If inclinations have not been configured for a person and an “Other Name” option is active, the system gracefully falls back to the original name stored in their record.

 

Business Logic / Behaviour

The following rules govern how this setting operates:

  • Trigger condition: The name format logic is only applied when a person’s first name or last name field is changed and saved. Saving any other field does not activate this logic.
  • Applies to all entity types: The setting is applied uniformly for Students, Teachers, and Partners. There is no entity-specific override.
  • Default option behaviour: If the setting is left at its default (“Entity’s Name”), no transformation occurs. The name as entered in the record is used directly.
  • Latin conversion: The “Entity’s Name to Latin” option applies a phonetic transliteration. The result is written to the user account profile and sent to any connected external systems. This option requires no prior setup.
  • Inclination-based options (Other Name 1–5): The system reads the matching inclination slot for the institution’s Default Language. The name is written without capital-case formatting. If the inclination slot is empty or not configured for that person, the system falls back to the original name.
  • Third-party synchronisation impact: The name resulting from this setting is also pushed to all connected external platforms during user synchronisation. The chosen format should therefore be compatible with the requirements of those platforms.
  • Not retroactive: Changing this setting has no effect on existing user accounts. The new format applies only from the next name-change event onward. If a bulk update is needed, names would need to be re-saved individually or via a bulk update process.
  • Per-institution configuration: In multi-branch organisations, each branch (Company) has its own configuration. Different branches may use different format types.
  • No difference between K-12 and Higher Education mode: This setting behaves identically in both K-12 and Higher Education (college) configurations. All seven options are available and work the same way in both modes.

 

Examples

 

Example 1 — Default: Entity’s Name

Configuration: User Account Name Format Type = Entity’s Name

Scenario: A Student named “Laura Bennett” is enrolled. Their first name “Laura” and last name “Bennett” are entered and saved.

Result: The user account profile stores “Laura” as the first name and “Bennett” as the last name — exactly as entered. No conversion is applied.

Best suited for: Institutions where all names are already in the format required by external systems, and no grammatical inflection is needed.

 

Example 2 — Entity’s Name to Latin

Configuration: User Account Name Format Type = Entity’s Name to Latin

Scenario: An institution operates primarily in Greek. A Teacher’s name is stored in Greek characters. The institution is integrated with Microsoft 365, whose user directory does not support Greek characters in display names.

Result: When the teacher’s name is changed and saved, Classter automatically transliterates it to Latin characters. The user account profile is updated with the Latin-character version. This transliterated name is also sent to Microsoft 365 during synchronisation, ensuring compatibility.

Important note: Only the name in the user account profile is affected. The original non-Latin name in the teacher’s personal record remains unchanged.

Consideration: Phonetic transliteration may not always match a person’s official passport spelling. If exact passport-spelling is required, consider pre-populating an Inclination slot with that version and using the corresponding “Other Name” option instead.

 

Example 3 — Other Name 2 (Inclination-based)

Configuration: User Account Name Format Type = Other Name 2

Prerequisites:

  • The institution’s Default Language is configured.
  • The Inclinations feature is active and Inclination slot 2 has been populated for the relevant persons.

Scenario: A Student named “Eleni Stavros” (nominative form) has their Inclination 2 slot configured with the genitive form: first name “Elenhs”, last name “Stavrou”.

Result: When the student’s name is saved after a change, Classter reads Inclination 2 for the default language and writes “Elenhs Stavrou” to the user account profile.

Fallback scenario: A second Student, “Tom Reeves”, has no Inclination 2 entry configured. Classter falls back to the original name and writes “Tom Reeves” to the account — no error occurs.

Best suited for: Institutions that need to use a specific grammatical case of a person’s name in user accounts, for example when the case used in certificates or system displays differs from the nominative (standard) form.

 

 

Notes

Prerequisites

  • For Other Name 1–5: The Inclinations feature must be enabled and the relevant inclination slots must be populated for each person (Students, Teachers, Partners) whose name change will be processed. Inclinations are entered in the person’s individual record.
  • For Other Name 1–5: The Default Language setting (Core Settings > Localisation Settings) must be configured. The system uses this language to select the correct inclination set for each person.
  • For Entity’s Name to Latin: No additional prerequisites. The transliteration capability is built into the system.

 

Important Considerations

  • Not retroactive: Changing this setting does not update user accounts that already exist. The new format applies only when a person’s name is next changed and saved. If the institution requires all accounts to be updated, names must be re-saved individually or via a bulk process.
  • External system compatibility: Because the formatted name is pushed to integrated external platforms, it is important to verify that the chosen format is compatible with those systems before applying a change.
  • Transliteration accuracy: The “Entity’s Name to Latin” option uses phonetic transliteration, not translation. The result may differ from the person’s official passport transliteration. If exact accuracy is required, the institution should pre-populate an Inclination slot with the correct form and use the corresponding “Other Name” option.
  • Incomplete inclination data: If “Other Name 1–5” is selected but inclinations have not been entered for all persons, some accounts will use the original name (fallback) and others will use the inclination. This inconsistency should be addressed by ensuring inclinations are fully populated before activating one of these options.
  • Multi-branch organisations: Each institution/branch has its own setting. Review each branch independently to ensure the correct format is applied everywhere.

 

K-12 vs Higher Education Mode

This setting behaves identically in both K-12 mode and Higher Education mode. All seven format options are available and work the same way regardless of which operational mode the institution is configured in. No separate configuration or behaviour difference exists between the two modes for this setting.

 

 

Was this article helpful?