Process Template Configuration

Overview

A process template defines the stages a candidate moves through during your hiring pipeline. Templates are written in YAML and consist of an ordered list of stages, each with a type, name, and optional configuration.

When you create a job posting and select a template, the stages are instantiated in order. Candidates progress through each stage sequentially — from application to offer.

Basic Structure

name: My Hiring Process
description: |
  A short description of this template.
  Supports **Markdown** formatting.

tags:
  - engineering
  - remote

stages:
  - type: application_form
    name: "Application"
    config:
      candidate_description: "Tell us about yourself."

  - type: live_interview
    name: "Interview"
    config:
      candidate_description: "A conversation about your background."

  - type: offer
    name: "Offer"

Templates are validated when you save them, and config keys are strictly checked — a misspelled or unsupported key fails validation with an error instead of being silently ignored, so typos surface immediately.

Top-Level Keys

Key	Required	Description
stages	Yes	Ordered list of stage definitions (at least one)
name	No	Template name (can also be set in the form field)
description	No	Markdown-formatted description of the process
tags	No	List of string tags for categorization
quick_fields	No	Quick fields for capturing candidate info (see Quick Fields below)

Stage Keys

Every stage requires name and type. The optional config hash and reviewers list vary by stage type.

Key	Required	Description
name	Yes	Display name for the stage
type	Yes	One of the 10 stage types listed below
config	No	Type-specific configuration options
reviewers	No	List of reviewer assignments

Compensating Candidates

Any stage can pay candidates for their time — most commonly a take-home assignment, but a paid design exercise or interview works the same way. Add a nested payout block to the stage’s config; when a candidate completes the stage, a payout is created for the configured amount. See Candidate Payouts for how payouts are reviewed and sent.

Key	Type	Default	Description
enabled	boolean	false	Turn on compensation for this stage
amount	integer	—	Amount to pay, in the given currency (e.g. 250)
currency	string	USD	Three-letter currency code

- type: code_assignment
  name: "Take-Home Assignment"
  config:
    candidate_description: "Complete a practical coding exercise."
    payout:
      enabled: true
      amount: 250
      currency: USD

Private Task Briefs

candidate_description is published: it renders on the job page, on the template gallery, and in candidate email. A take-home task and the links that come with it belong in the nested brief block instead, which only a candidate who reached the stage and started the task can read. The block is read on portfolio_upload stages, where it becomes the take-home task the candidate starts; on other stage types it is ignored. See Stage Description vs Brief.

Key	Type	Default	Description
body	string	—	The task itself, as plain text. Pasted URLs are linked when the candidate reads it
estimated_hours	integer	—	Effort shown to the candidate before they start (min: 1)
due_days	integer	5	Days from the moment the candidate starts to the deadline (min: 1)
grace_hours	integer	24	Hours uploads stay open past the deadline, flagged late
allow_extension	boolean	false	Offer one self-serve extension before the deadline passes
extension_hours	integer	72	Length of that extension (min: 1)

- type: portfolio_upload
  name: "Paid Test Project"
  config:
    candidate_description: "A short paid exercise, roughly half a day of work."
    brief:
      body: |
        Retouch the five raw files in https://drive.google.com/drive/folders/example
        and hand back web-ready JPEGs plus your layered file.
      estimated_hours: 4
      due_days: 5
      grace_hours: 24
      allow_extension: true
    payout:
      enabled: true
      amount: 150
      currency: PLN

There is no flat spelling of these keys — brief is always nested, so its estimated_hours and allow_extension never collide with the code_assignment keys of the same name.

Stage Types Reference

application_form

The entry point for candidates. Collects structured information via custom form fields. Optionally holds candidates in a screening state before advancing.

Config Key	Type	Default	Description
candidate_description	string	—	Instructions shown to the candidate
screening_enabled	boolean	true	Hold submissions for manual review before advancing. Enabled by default — set to false explicitly to disable screening
screening_message	string	—	Message shown to candidates while screening is active
resume_required	boolean	false	Require a CV or résumé — candidates cannot submit without attaching a PDF or Word document (max 10 MB)
fields	array	—	List of form field definitions (see below)

Form field options:

Key	Required	Type	Description
name	Yes	string	Field identifier
type	Yes	string	text, textarea, file, url, select, checkbox, email, phone
required	No	boolean	Whether the field must be filled — enforced when the candidate submits, on every apply surface including the public API
label	No	string	Display label (defaults to name)
placeholder	No	string	Placeholder text
max_length	No	integer	Maximum character count (min: 1)
options	No	array	Choices for select fields

Important: To require a CV, set resume_required: true on the stage config. A form field named resume is ignored — the resume has its own upload on the application form and attaches separately from custom fields, so declaring - name: resume with type: file and required: true has no effect.

- type: application_form
  name: "Application"
  config:
    candidate_description: "Tell us about yourself."
    screening_enabled: true
    screening_message: "We'll review your application shortly."
    resume_required: true
    fields:
      - name: experience_level
        type: select
        required: true
        options:
          - "Junior (0-2 years)"
          - "Mid (2-5 years)"
          - "Senior (5+ years)"
      - name: cover_letter
        type: textarea
        required: false
        max_length: 500

code_assignment

A take-home coding exercise. When GitHub is connected, a private repo is created from a template for each candidate. Includes deadline management.

Important: The repository specified in github_template must be marked as a template on GitHub. See GitHub Template Repository Setup for requirements and setup instructions.

Config Key	Type	Default	Description
candidate_description	string	—	Instructions shown to the candidate
github_template	string	—	GitHub template repo (e.g. org/hiring-assignment)
duration_days	integer	7	Days allowed to complete (min: 1)
estimated_hours	integer	—	Estimated effort in hours (e.g. 5)
instructions	string	—	Instructions committed into the candidate’s repository
grace_period_hours	integer	24	Hours accepted past the deadline before it becomes final
allow_extension	boolean	true	Candidates may request a deadline extension

To pay candidates for the assignment, add a payout block — see Compensating Candidates above. The legacy paid, payment_amount, and payment_currency keys are still accepted on code_assignment and are converted into an equivalent payout, but prefer payout in new templates.

- type: code_assignment
  name: "Take-Home Assignment"
  config:
    candidate_description: "Complete a practical coding exercise."
    github_template: "mycompany/hiring-challenge"
    duration_days: 7
    estimated_hours: 5
    payout:
      enabled: true
      amount: 250
      currency: USD

portfolio_upload

Candidates upload work samples (design files, writing samples, etc.). Supports file type restrictions, upload limits, and external links. Add a brief block to turn the stage into a take-home task with a deadline — see Private Task Briefs.

Config Key	Type	Default	Description
candidate_description	string	—	Instructions shown to the candidate
accept	array	pdf, png, jpg, jpeg, gif, webp	Accepted file extensions, without a leading dot. Name them explicitly to take task deliverables — zip, mp4, mov, webm, tiff, tif and psd are also recognized. An extension Kit does not recognize is ignored rather than accepted
max_files	integer	10	Maximum number of files (min: 1)
max_file_size_mb	integer	25	Maximum size per file in MB
allow_links	boolean	true	Candidates may also submit external links (e.g. Figma, Behance)

- type: portfolio_upload
  name: "Portfolio Review"
  config:
    candidate_description: "Share 3-5 examples of your best work."
    accept:
      - pdf
      - png
      - jpg
    max_files: 5
    max_file_size_mb: 50
    allow_links: true

questionnaire

Written questions for candidates to respond to asynchronously. Useful for scenario-based screening in support, sales, or writing roles.

Config Key	Type	Default	Description
candidate_description	string	—	Instructions shown to the candidate
questions	array	—	List of question definitions
duration_days	integer	—	Suggested days to respond — shown on the template preview only, not enforced

Question options:

Key	Required	Type	Description
type	Yes	string	Question category (e.g. scenario)
prompt	Yes	string	The question text

- type: questionnaire
  name: "Written Scenarios"
  config:
    candidate_description: "Respond to these real-world scenarios."
    questions:
      - type: scenario
        prompt: "A customer reports a billing error. Walk us through your response."
      - type: scenario
        prompt: "You discover a bug affecting 10% of users. What do you do?"

video

Presents a video to candidates. Supports uploaded videos (via Mux) or embedded videos from external platforms.

Video settings are grouped under a nested video key inside config.

Config Key	Type	Default	Description
candidate_description	string	—	Instructions shown to the candidate
video	hash	—	Video settings (see below)

video options:

Key	Type	Default	Description
source_type	string	mux	mux (uploaded) or oembed (external embed)
oembed_url	string	—	URL for embedded video (when source is oembed)
description	string	—	Description or context for the video
min_watch_percentage	integer	15	Minimum watch percentage required (1-100)

- type: video
  name: "Company Introduction"
  config:
    candidate_description: "Watch this video about our team and culture."
    video:
      source_type: oembed
      oembed_url: "https://www.youtube.com/watch?v=example"
      description: "A 5-minute overview of our engineering team."
      min_watch_percentage: 80

video_recording

Candidates record or upload a video response to a prompt. Useful for video introductions, video cover letters, or async video interviews. Requires Mux integration.

Recording settings are grouped under a nested video_recording key inside config.

Config Key	Type	Default	Description
candidate_description	string	—	Instructions shown to the candidate
video_recording	hash	—	Recording settings (see below)

video_recording options:

Key	Type	Default	Description
max_duration_seconds	integer	120	Maximum recording length in seconds
allow_upload	boolean	true	Allow candidates to upload a pre-recorded video file
max_retakes	integer	—	Number of re-recordings allowed (blank = unlimited)

- type: video_recording
  name: "Video Introduction"
  config:
    candidate_description: "Record a 2-minute video introducing yourself."
    video_recording:
      max_duration_seconds: 120
      allow_upload: true
      max_retakes: 3

team_review

An internal review stage where your team evaluates a candidate. Supports voting thresholds and veto rules.

Config Key	Type	Default	Description
candidate_description	string	—	Message shown to the candidate during this stage
voting	hash	—	Voting configuration (see below)

Voting options:

Key	Type	Default	Description
threshold	integer	2	Minimum yes votes to advance (1-10)
require_all_reviewers	boolean	false	All assigned reviewers must vote
veto_auto_rejects	boolean	false	A single veto automatically rejects the candidate

- type: team_review
  name: "Code Review"
  config:
    candidate_description: "Our team is reviewing your submission."
    voting:
      threshold: 2
      require_all_reviewers: true
      veto_auto_rejects: true

live_interview

A synchronous interview conducted over video call or in person. Integrates with calendar scheduling.

Config Key	Type	Default	Description
candidate_description	string	—	Instructions shown to the candidate
duration_minutes	integer	60	Interview length in minutes (min: 15)
interviewers_required	integer	1	Number of interviewers who must attend
includes_roleplay	boolean	false	Interview includes a role-play exercise

- type: live_interview
  name: "Technical Interview"
  config:
    candidate_description: "A conversation about your technical skills."
    duration_minutes: 90
    interviewers_required: 2

reference_check

Collect and verify candidate references. There is no reference-submission flow yet — candidates see the stage description, and references_required appears on the template preview but is not enforced.

Config Key	Type	Default	Description
candidate_description	string	—	Instructions shown to the candidate
references_required	integer	—	Number of references needed (min: 1)

- type: reference_check
  name: "References"
  config:
    candidate_description: "Provide contact details for your references."
    references_required: 2

offer

The final stage where you extend an offer to the candidate. Typically has minimal configuration.

Config Key	Type	Default	Description
candidate_description	string	—	Message shown to the candidate

- type: offer
  name: "Offer"
  config:
    candidate_description: "We'd love to have you join the team."

Reviewers

You can assign reviewers to any stage. Each reviewer needs an email address and a role.

Key	Required	Description
email	Yes	Email address of the reviewer (must match a team member)
role	Yes	reviewer (standard) or lead (primary decision-maker)

- type: team_review
  name: "Code Review"
  config:
    voting:
      threshold: 2
  reviewers:
    - email: [email protected]
      role: lead
    - email: [email protected]
      role: reviewer
    - email: [email protected]
      role: reviewer

Quick Fields

Quick fields define structured metadata that your team captures for each applicant — things like salary expectations, availability, location preference, or any custom signal relevant to your role. Fields appear in the candidate sidebar.

For managing field definitions directly in the UI, see Candidate Data Fields.

Schema

Key	Required	Type	Description
key	Yes	string	Unique identifier (lowercase, underscores only, e.g. salary_expectation)
label	Yes	string	Display label shown to your team
field_type	No	string	One of the 4 field types below (default: text)
placeholder	No	string	Placeholder text for the input
options	No	array	Choices for select fields

Note: Richer field types and options — such as numbers, ratings, AI extraction, and visibility rules — are configured under metafield_definitions, a separate top-level key. See Candidate Data Fields.

Field Types

Type	Description
text	Single-line text input
textarea	Multi-line text input
select	Dropdown from a fixed list of choices
date	Date picker

Examples

quick_fields:
  - key: salary_expectation
    label: "Salary Expectation"
    field_type: text
    placeholder: "$80,000 - $100,000"
  - key: start_date
    label: "Earliest Start Date"
    field_type: date
  - key: work_authorization
    label: "Work Authorization"
    field_type: select
    options:
      - "US Citizen"
      - "Permanent Resident"
      - "Requires Sponsorship"
  - key: source
    label: "Source / Referral"
    field_type: text
    placeholder: "e.g. LinkedIn, referral from..."

Complete Example

A full template for hiring a software engineer, including screening, a paid code assignment, team review, two interview rounds, references, and an offer.

name: Software Engineer - Standard
description: |
  Comprehensive process for mid-to-senior software engineers.
  Includes a take-home assignment with team code review.

tags:
  - engineering
  - technical
  - assignment

quick_fields:
  - key: salary_expectation
    label: "Salary Expectation"
    field_type: text
    placeholder: "e.g. $120k - $150k"
  - key: notice_period
    label: "Notice Period"
    field_type: text
  - key: location_preference
    label: "Location Preference"
    field_type: text

stages:
  - type: application_form
    name: "Application"
    config:
      candidate_description: "Tell us about yourself and your experience."
      screening_enabled: true
      screening_message: "We're reviewing your application."
      resume_required: true
      fields:
        - name: github_url
          type: url
          required: false
        - name: motivation
          type: textarea
          required: true
          max_length: 500

  - type: code_assignment
    name: "Take-Home Assignment"
    config:
      candidate_description: "Complete a practical coding exercise at your own pace."
      github_template: "mycompany/hiring-assignment"
      duration_days: 8
      estimated_hours: 6
      payout:
        enabled: true
        amount: 250
        currency: USD
    reviewers:
      - email: [email protected]
        role: lead

  - type: team_review
    name: "Code Review"
    config:
      candidate_description: "Our team reviews your code submission."
      voting:
        threshold: 2
        require_all_reviewers: true
        veto_auto_rejects: true
    reviewers:
      - email: [email protected]
        role: lead
      - email: [email protected]
        role: reviewer

  - type: live_interview
    name: "Technical Interview"
    config:
      candidate_description: "A conversation about your technical skills."
      duration_minutes: 90
      interviewers_required: 2

  - type: live_interview
    name: "Culture & Values"
    config:
      candidate_description: "Get to know the team and learn about our culture."
      duration_minutes: 45

  - type: reference_check
    name: "References"
    config:
      references_required: 2

  - type: offer
    name: "Offer"
    config:
      candidate_description: "We'll present you with an offer to join the team."

Tips

• Start with application_form — it’s the natural entry point and lets you collect resumes and basic info.
• End with offer — keeps the pipeline clean and gives you a final stage for tracking.
• Use screening on the application form to manually review candidates before they advance. This prevents unqualified candidates from receiving assignments.
• Pay for take-home assignments — add a payout block to the stage config to compensate candidates for their time (it works on any stage type). See Candidate Payouts.
• Keep processes under 7 stages — long pipelines lead to candidate drop-off.
• Assign reviewers to team_review and code_assignment stages so the right people are notified automatically.
• Use candidate_description on every stage — it’s the public summary candidates read on the job page, so clear communication reduces confusion and support requests.
• Put the actual task in brief — instructions, file links, and anything you don’t want on the public job page. See Private Task Briefs.
• Capture common signals with quick_fields — add fields like salary expectation, availability, and location so your team records them consistently in the candidate sidebar.
• Need richer types or AI extraction? — numbers, ratings, AI auto-population, and visibility rules live under metafield_definitions. See Candidate Data Fields.