Customize the Job Posting Form

Control which fields appear on your board's job posting form — visibility, required status, and allowed options — for every posting surface on your board.

Job form settings control which fields appear on your board's posting form, whether they are optional or required, and which options are available to employers. The configuration applies to every posting surface on your board — your own operator form, the public submission form, and the employer forms.

Before you begin

List the fields every job must include and the values your niche actually uses. Review at least one existing job before making a field required so you understand what an editor will need to add the next time that job changes.

Configure the job form

  1. Go to Settings in the sidebar
  2. Click Job form
  3. For each field, toggle visibility using the Off / On / Required control
  4. To restrict the allowed options for a field, open the dropdown and select the values you want
  5. Click outside the dropdown to save

Changes are saved instantly. The public board's filter facets update to match; a facet reduced to one allowed option is hidden automatically. To rename field labels, use the Website builder on the Post a job page.

Verify the form configuration

Open your operator job form and the public or employer posting form used on your board. Confirm hidden fields are absent, required fields block submission when empty, and restricted dropdowns contain only the allowed values. If employment type or work arrangement has one allowed value, confirm the form omits that field and a newly created job receives the implied value. Finally, open the public jobs page and confirm a facet with only one allowed value is hidden.

Troubleshoot the configuration

If a field does not appear, confirm it is set to On or Required and that its allowed-options list is not empty. If a filter facet is missing, check whether the field is hidden or reduced to one allowed value. If a custom-field answer is rejected through the API, retrieve the configuration and send the stored option key with the value type defined for that field.

Fields

Each field is a separate card on the settings page:

  • Employment type: Limit the types available on the form. Selecting one removes the field and implies that type for every job.
  • Seniority: Show or hide the seniority field, mark it required, and restrict which levels are available.
  • Work arrangement: Limit accepted arrangements. Selecting one removes the field and implies that arrangement for every job.
  • Location: Restrict office locations to specific countries.
  • Salary: Show or hide the salary field, mark it required, set minimum and maximum bounds, and restrict accepted currencies.
  • Visa sponsorship: Show or hide the sponsorship question.

Custom fields

Beyond the built-in fields, you can add your own. Open the Custom fields section at the bottom of the Job form settings page and click Add field.

Each field has a label, a type, and an optional required toggle. Pick from six types:

  • Short text: a single line, for answers such as a security clearance.
  • Long text: a paragraph, for a longer description.
  • Dropdown (single choice): one value from a list of options you define.
  • Checkboxes (multiple choice): any number of values from a list you define.
  • Yes / No toggle: a simple flag.
  • Number: a numeric value, with optional minimum and maximum.

Drag the handle to reorder fields; the order you set is the order they appear on the form and the public job page. You can rename a field label or an option label at any time without losing answers already submitted. The field's internal key is fixed once you save, so stored answers stay linked.

Custom fields are captured on every posting surface (your operator form, the public submission form, and the employer forms) and validated the same way. Answers are shown on the public job page in an Additional details section, below the job description. The section heading and the Yes / No wording can be translated per board in the Website builder. Custom fields are display only for now: they do not feed search filters or structured data.

Custom fields are board-wide and filled in by whoever posts the job; they apply to every job posted on your board. They are not applicant-facing screening questions: per-job screening questions that candidates answer when applying are not supported.

To remove a field, open its menu and choose Delete. You can keep submitted answers, which lets you re-adopt them later by re-creating a field with the same key, or delete them.

A board can have up to 20 custom fields, each select can have up to 50 options, and labels can be up to 60 characters.

Read the configuration via the API

Headless clients can read the board's job form configuration before rendering their own posting form.

text
GET /v1/settings/job-form

The endpoint returns the stored configuration object, or an empty object when no configuration has been saved. The object includes your custom field definitions (each with its key, label, type, and options), so a headless client can render them too. Authenticate with an API key, user session, or OAuth token. See the API reference for the full schema.

Write custom-field values via the API

Custom fields are display only on your board, but you can set their values through the Operator API. This is how an external enrichment workflow fills generated values onto jobs you have already imported.

Send a customFieldValues object, keyed by each field's key (from the configuration endpoint above), on either job endpoint:

text
POST /v1/jobs # set values when creating a job
PATCH /v1/jobs/{id} # add or change values on an existing job

On PATCH, writes are additive. A key you send is set or overwritten, and a key you do not send is left untouched, so you can enrich one field at a time without re-sending the whole bag. To clear a value, send it as null, an empty string, or an empty array. A false or 0 is kept as a real answer.

Values are validated against your definitions: the value must match the field's type, and a dropdown or checkbox value must be one of that field's option keys (not the option label). A wrong-typed value is rejected rather than silently dropped, and a required field cannot be cleared or left empty. Keys that are not defined on your board are ignored.

A typical enrichment round-trip, addressing the job by its id:

text
GET /v1/settings/job-form # learn the field keys, types, and options
GET /v1/jobs?externalId=REQ-123 # find the job, read its id from the result
PATCH /v1/jobs/{id} # write { "customFieldValues": { "clearance": "ts_sci" } }
GET /v1/jobs/{id} # read the values back

externalId is a lookup filter used to find the job; the value write is always addressed by the job's id. The same customFieldValues field is available through the CLI and the code-mode MCP, which inherit it from the API reference.

Next steps

  • Website builder: rename posting-page labels and custom-field display text
  • Jobs widget: see how enabled fields control advanced filter facets

Frequently asked questions