Participant Profile

Define what your task knows about each candidate: structured classification parameters (tags, stages, programs) and free-form custom properties — the data that powers filtering, audiences, prerequisites, and reports.

Updated 2026/07/13

The participant profile defines what the task knows about each candidate beyond their name and email. Two kinds of data are configured here — structured classification parameters and free-form custom properties — and both flow through the entire platform: candidate filters, Exam Monitor audiences, step prerequisites, analytics segments, email templates, and report rendering.

Data can enter the profile from any side: assigned by admins on the candidate list, collected from the candidate via the access form, imported in bulk, or set through the API. Define the model here first; every collection channel then shares the same fields.

Decide the profile before inviting anyone: the questions you'll want to answer later (“how did site B do?”, “only the finance cohort takes Part 2”) are only answerable if the classification existed when candidates entered.
Plan ahead

Classification parameters are the structured ways candidates are categorized within the task:

Tags — key–value classifications you define (e.g. department: Finance, site: Istanbul). Each tag key becomes a filterable dimension across candidate lists, sessions, analytics, and email templates.
Stages — the phases of your assessment process (Screening, Interview, Final…). Each candidate sits in one stage (or none) and moves as they progress; steps can be gated to specific stages (see Steps → Pre-Start → Prerequisites).
Programs — named tracks within one task (e.g. Developer track vs Designer track). Candidates belong to one or more programs, and steps can require program membership — so different audiences see different steps inside the same task.

Values can be assigned by admins, chosen by candidates on the access form, or imported. Because prerequisites, monitor audiences, and analytics all read these structures, they are the backbone of any multi-track or multi-phase assessment.

Custom properties are additional per-candidate fields you define for this task — anything your process needs that isn't a built-in field or a classification: employee ID, phone number, preferred exam city, years of experience, an agreement checkbox.

Each property is defined once and then exists on every candidate of the task.
Values can be filled by candidates on the access form, entered by admins, or imported alongside candidates.
Properties appear as columns in the candidate list, are available to email templates and document generation, and travel with exports.

Custom properties vs tags: use a tag when the values come from a controlled set you'll filter and segment by; use a custom property for candidate-specific data (identifiers, free text, contact details) that doesn't define groups.