Roles - Article

Overview

The Roles setting provides a centralized place to manage how user roles are named and presented across the platform.

While roles themselves are tied to system functionality and permissions, this configuration allows administrators to align role naming with their own organizational structure and terminology. This is particularly useful in environments where standard system roles (e.g. “Participant” or “Instructor”) do not match internal naming conventions.

In addition, roles can be translated into multiple languages, ensuring that users see familiar and localized terminology based on their language preferences.

The list of roles shown in this section reflects the roles that are enabled and available on your platform. Some roles—such as Global Administrator—may only appear if the corresponding feature set or configuration is active.

Role Naming and Localization

Administrators can rename each role and define translations across supported languages.

This allows you to:

• Align role names with internal terminology (e.g. “Participant” → “Learner”, “Student”, or “Employee”)
• Adapt naming to different audiences (e.g. partner vs internal users)
• Ensure consistent terminology across multilingual platforms

Translations can be configured per language, meaning each role can have a localized name depending on the user’s selected language.

Example:

• English → Participant
• Danish → Deltager
• Spanish → Partícipe
• Swedish → Deltagare

This setting operates as a presentation and terminology layer rather than a permission or security configuration. While roles continue to define system behavior and access behind the scenes, this configuration determines how those roles are labeled and understood by users across the platform.

Where Role Names Are Used

Renamed roles are reflected consistently across the platform wherever roles are used in configuration, filtering, or user segmentation. This includes key areas such as target audience criteria, enrollment and onboarding rules, access and visibility settings, as well as reporting and segmentation.

In practice, this means that once a role is renamed, the updated terminology is applied throughout administrative workflows and user-facing contexts where roles are referenced. This helps ensure that both administrators and users interact with terminology that aligns with the organization’s structure, improving clarity and reducing ambiguity across the platform.

Important Considerations

Renaming a role affects how it is presented across the platform, but it does not change the underlying permissions, access rights, or system behavior associated with that role. The role continues to function exactly as defined by the platform—it is only the label that is adjusted to better fit your organizational context.

It is also important to understand that role renaming is applied primarily within structured system contexts, such as configuration, filtering, and segmentation. It does not automatically update all textual references across the platform. This means that areas such as email notifications, system messages, free-text descriptions, and instructional content may still use the default terminology (e.g. “Instructor” or “Participant”). These must be reviewed and updated separately through Settings → Translations if consistent terminology is required.

In practice, this creates a clear distinction between system-driven labeling and content-driven communication. Administrators should therefore consider role renaming as part of a broader terminology strategy, especially in environments where consistency across user communication is important.

Example:

An organization prefers the term “Learner” instead of “Participant” and operates across multiple languages. The administrator renames the role accordingly and configures translations for each supported language. As a result, all system configurations and filters reflect the updated terminology, and users see role names in their preferred language. However, existing email templates and system messages may still reference “Participant” and would need to be updated separately to ensure full consistency.