Talview Proctor Portal
All chapters
Documentation · Chapter 4 of 4

Admin & Configuration

The screens that shape everything else — who can log in and as what, which vendors the workforce is organized under, what the legal documents actually say, and the permanent, unfalsifiable record of who did what and when.

Staffing partners

Vendors

Admin

Every proctor in the system belongs to exactly one vendor — the staffing partner responsible for them. This page is where that roster of partners is managed: a short code (used directly inside Proctor IDs, e.g. SAI-0001), an active/inactive flag, and one or more named points of contact.

Add Vendor dialog with name, code, active flag and points of contact
Adding a vendor — the code becomes part of every one of their proctors' IDs
Who can sign in, and as what

Users

Admin

Three roles exist — Admin (full access), Coordinator (the operational day-to-day, without the admin-only pages), and Vendor (restricted to their own proctors, with the one special power of marking Demo/Assessment readiness). A new account can be provisioned two ways: an email invite the person accepts themselves, or a temporary password set directly by the admin — either way, a vendor account is tied to exactly one vendor organization at creation time.

Create User dialog with name, email, role, vendor and invite/password mode
Creating an account — role and vendor are set once, at creation
These boundaries are real, not just hidden buttons: a Vendor account genuinely cannot see or change another vendor's proctors, and cannot perform an admin-only action, no matter how someone might try to access it.
The document itself

NDA Template

Admin

Behind every candidate's signing link is a real, versioned PDF — today's active document bundles the AUP, Disciplinary Action policy, Code of Ethics, Code of Conduct and the NDA proper into one multi-page file, with every signature box, date field and name field mapped to an exact page and position. Publishing a new version here is what every future "Send Onboarding Docs" click will use — sessions already in flight keep the version and deadline they were sent with.

NDA Template admin page showing the active onboarding document and its 37 mapped fields
The active template — 37 fields mapped across 5 policies, one signing-link expiry setting
The permanent record

Audit Log

Admin

Every meaningful action in the system writes one row here — logins and logouts, every stage transition a proctor goes through, every scheduling and evaluation decision, every bulk send and its outcome. Nothing routes around this log: the same disposable test candidate used throughout this documentation shows up here exactly as any real one would, timestamped to the second and attributed to the exact account that acted.

It's filterable by action type (over 20 distinct kinds are tracked, from Eval Result to Bulk Send Completed), searchable, and exportable by date range — this is the record a compliance review or a customer audit would actually be handed.

Audit Log showing timestamped actions for a test candidate, from form link shared through NDA docs triggered
One candidate's full trail, start to finish — exactly what a real audit would show
Small touches that add up

Utilities

A command palette (⌘K) jumps to any page or searches proctors directly from anywhere, and the notification bell surfaces time-sensitive items — like an NDA link about to expire — before they become a real problem, each linking straight to the affected proctor's record.

Command palette with jump-to-page and proctor search
⌘K from anywhere in the app
Notifications dropdown listing NDA links expiring soon
Proactive nudges, not just a log to check