Roles and terminology

Two different settings, easy to confuse

A program has two separate controls that both touch “roles,” and it’s easy to mix them up:

Program Roles — decides which roles exist in a program. This is a structural choice: does this program have a Mentor role? A Coach role? Does it also involve Managers or HRBP as side participants?
Terminology & Labels — decides what those roles are called on screen, in each supported language. This never adds or removes a role; it only changes the display name participants see.

If a program admin wants to add a new kind of participant to a program, that’s a Program Roles change. If they just want the existing roles to read differently — for example, calling the coaching side “Mentor” instead of the platform’s default “Coach” — that’s a Terminology & Labels change.

The role model: two required sides, plus optional side roles

Every program is built around two core sides of a relationship, plus optional supporting participants:

Support Receiver — the person being developed (e.g. a Mentee, Coachee, or Leader Candidate). A program has exactly one Support Receiver role, so it’s always unambiguous who “the participant” is.
Support Giver — the person providing the development support (e.g. a Mentor, Coach, or Peer). A program needs at least one Support Giver role selected so that matching between the two sides can actually work.
Side Roles (optional) — people connected to the program but not part of the core matched pair, such as a Manager or HRBP. A program can select none, one, or several side roles.

An admin doesn’t type free-form role names here. They choose from a library of pre-defined named roles (for example “Mentor,” “Coach,” or “Peer” under Support Giver; “Mentee” or “Coachee” under Support Receiver; “Manager” or “HRBP” under Side Roles), and simply turn on the ones this program uses. A program can have multiple Support Giver roles active at once if its design calls for it, but exactly one Support Receiver role — a program that needs a second kind of receiver is designed as a separate program.

Because matching depends on having both a receiving side and a giving side configured, a program cannot be saved with zero Support Receiver roles or zero Support Giver roles selected — the admin will be asked to pick a Support Receiver role and at least one Support Giver role before continuing.

Terminology & Labels: renaming what people see

Once the roles are chosen, the Terminology & Labels settings let an admin control the actual words participants see throughout the program — without touching which roles exist underneath. This covers:

Singular and plural display names for the Support Giver and Support Receiver roles (e.g. “Mentor” / “Mentors”, or “Koç” / “Koçlar” for a Turkish-language program).
Short descriptions of what each role is responsible for, shown to help participants understand the relationship.
Other program-wide labels, such as what to call a coaching session, a training activity, or the goals area of the program — so a program can say “Coaching Session” instead of the platform default, for instance.

If an admin leaves a field blank, the program falls back to a sensible default: first the program’s own overall default, then the platform’s built-in wording (for example “Mentor” and “Mentee” if nothing else is set).

Per-language overrides

Terminology is set per language, not just once. An admin fills in a Default set of labels that applies program-wide, and then can add overrides for specific languages the program supports. A language override only needs to be filled in where it should differ from the Default — anything left blank simply inherits from the Default tab, and the Default tab in turn falls back to the platform’s built-in wording if it’s empty too.

This layered fallback (language-specific override → program default → platform built-in) means an admin doesn’t have to fill in every field for every language; they only need to override what’s actually different in that language.

Grammatical forms for inflecting languages

Some languages change the ending of a word depending on how it’s used in a sentence — Turkish is the example the platform explicitly supports. Beyond the plain display name, an admin can optionally provide two additional grammatical forms for the Support Giver and Support Receiver names:

A dative form (roughly, “to the [role]” — e.g. “Koça”).
A genitive form (roughly, “the [role]‘s” — e.g. “Koçun”).

These are optional. If a program’s language doesn’t need them (English, for example), they can be left blank, and the system uses the plain name wherever the grammatical form would otherwise be needed. They only need to be filled in for languages where getting the sentence grammatically right matters — most commonly Turkish.