Access & Entry

The access form is what candidates fill in to enter the task — the registration form for self-registration, or the entry form pre-registered candidates complete on first login. You compose it from the task's data model, so everything collected lands as structured candidate data:

• Identity fields — name, email, and credentials used to recognize the candidate.
• Classification parameters — the structured selectors defined in Participant Profile (department, location, cohort…), so candidates classify themselves at entry.
• Custom properties — any additional per-candidate fields the task defines.
• Program selection — where the task uses programs, the form can let candidates pick (or be assigned) theirs.

Everything the form collects is available afterwards for filtering candidates, scoping the Exam Monitor audience, segmenting analytics, and rendering into reports — collect at the door what you'll want to slice by later. The access form is a plan-gated feature (Registration Form). It does not apply to internal-users tasks, whose participants already have profiles.

Task availability is the assessment's overall schedule — the window in which candidates can access the task at all:

• Schedule window — an optional start and end date (with explicit time zones). Outside the window, candidates can't enter; use it to open registration before the exam or close the campaign automatically.
• Check-in restriction — an optional deadline for starting: candidates must check in before the configured moment, so latecomers are excluded from a scheduled sitting without shortening anyone else's time.

Task availability nests with step availability: the task window governs the whole assessment, and each step can carry its own narrower window inside it (see Steps → Availability). A candidate must satisfy both to take a given step.

Monetization puts a price on the task: candidates must complete a payment before they can access the assessment. Enable it, set the price, and the payment step appears in the candidate's entry flow — payments are processed through your organization's connected Stripe account and deposited directly to you.

• Typical uses: paid certification exams, priced practice tests, and course-entry assessments.
• Works naturally with self-registration — the public link becomes a self-serve storefront: register, pay, take the exam.
• Each candidate's payment status is tracked on their record; unpaid candidates are held at the payment step.

Monetization is a plan-gated feature and requires the one-time Stripe connection under Organization → Integration → Monetization Setup before prices can be charged.

Network restrictions control where the task can be accessed from. When enabled, each access attempt is evaluated against an ordered list of rules, each of which matches a network and applies an action:

• IP rule — matches an IP address or CIDR range (e.g. 203.0.113.0/24), with an allow or deny action. Use it to pin an exam to your campus or office network.
• Country rule — matches the candidate's country, likewise with allow or deny. Use it to restrict a national certification to its jurisdiction or block regions you cannot serve.

Rules are evaluated in order — arrange them from most specific to most general (allow the exam-hall range, then deny everything else). Candidates arriving from a non-permitted network are blocked at entry with a clear message, before consuming a session.

Keep in mind that VPNs and mobile networks change a candidate's apparent IP and country — for remote candidates, prefer country rules over narrow IP ranges, and tell candidates in advance to disable VPNs.