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.
A
JJob 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
- Go to Settings in the sidebar
- Click Job form
- For each field, tick Shown and Required as needed, and drag rows into the order you want
- To restrict the allowed options for a built-in field, click its row, choose the values you want, and click Save
Checkbox and order 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.
Order, show and require fields
The Job form settings page lists every field on the form in one table: the built-in fields, your custom fields and your collection fields. The order of the table is the order of the form.
- Reorder: drag a row by its handle. On a touch screen, use the row menu's Move up and Move down.
- Show or hide: untick Shown to remove a field from the form. Answers already stored on existing jobs are kept. Unticking Shown also unticks Required.
- Require: tick Required to make posters fill the field. A hidden field cannot be required, and a field that can never be required (such as employment type, which always has a value) shows a disabled box.
Some built-in fields are locked: both boxes stay ticked and a lock tooltip names the reason. A locked field can still move. The locks follow what Google for Jobs needs to accept a posting:
- Job title and Description are required properties of a Google job posting.
- Company supplies the hiring organization.
- Work arrangement drives the location rules below.
- Location is locked while on-site or hybrid jobs are allowed. Once work arrangement allows remote only, you can hide it.
- Candidate locations is locked while remote jobs are allowed, because a remote posting must state where candidates can be.
- Apply method is locked because a job without one cannot be applied to.
Employment type and salary can be hidden, but Settings warns that hiding them can reduce your visibility in Google for Jobs. Publish and expiry dates are set from publishing and are not form fields.
The same order, visibility and required state apply to the dashboard job form and the employer forms. Boards built with the AI builder or the Board SDK read the resolved form from the public board context (forms.job on GET /v1/boards/{identifier}), so a change here reaches those boards without code changes. Cavuno-hosted posting forms keep their fixed order.
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 its Shown box is ticked 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
Built-in fields with options open a drawer when you click their row:
- Employment type: Tick the types posters can pick, put them in order and add your own custom types. When only one option is left, the field is removed and that type is implied 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.
- Candidate locations: Choose where remote candidates can be, and show or hide the visa sponsorship question with Ask about visa sponsorship.
Custom employment types
Some markets use employment types the built-in list does not have, such as Casual in Australia. Open Employment type in the field list. The drawer lists every type, built-in and custom, in the order posters see them. Tick Offered for each type posters can pick; every built-in is ticked until you change it, and at least one type must stay ticked. Drag a row by its handle to reorder, or use Move up and Move down in its menu.
Click Add type, enter a name and choose its Google equivalent: one of the built-in types, used for Google for Jobs and job feeds. On your board the job always shows your type's name. Common names are filled in for you (Casual as Part-time, Seasonal as Temporary, FIFO as Full-time). You can have up to 20 custom types, ticked or not. Names must be unique and cannot repeat a built-in name.
- Posters choose a custom type like any other employment type. The job stores its Google equivalent too, so Google for Jobs, job feeds and filters keep working.
- A custom type's Google equivalent does not have to be offered. For example, offer Casual (Google sees Part-time) without offering Part-time itself.
- Untick a type to stop offering it. Jobs that already use an unticked custom type keep its name, and filters still find them.
- Custom types cannot be deleted, only unticked, and a custom type's key is never reused.
- Renaming a custom type updates every job that uses it. Its Google equivalent is locked once saved.
- On Cavuno-hosted boards, the public and employer posting forms offer built-in types only. Keep at least one built-in type ticked if posters use those forms. Your operator form, the API and boards built with the AI website builder or the Board SDK offer custom types too.
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. On Cavuno-hosted boards, custom fields are display only: they do not feed search filters or structured data. Boards built with the AI website builder or the Board SDK can also filter jobs by them and show them as badges; see Custom fields in the AI website builder.
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.
Used as a filter?
On boards built from the latest starter, a Dropdown (single choice), Checkboxes (multiple choice) or Yes / No toggle field is added to the jobs page's All filters sheet automatically. A Yes / No field shows as one checkbox: ticked shows only jobs set to Yes, unticked applies no filter. Number, text and collection reference fields are not added. To place a filter somewhere else, such as a dropdown in the main search bar, ask the AI website builder or build it with the Board SDK. See Custom fields in the AI website builder.
Collection fields
Use a collection field when jobs should choose from a reusable list, such as Technologies or Accreditations. Create and populate the list under Settings → Collections, then add a Collection reference in Job form settings. Give the field a label, choose its collection, and choose whether one or multiple entries can be selected and whether an answer is required.
The same collection can be used by jobs, company profiles and talent profiles. Editing an entry updates its shared details wherever it is displayed. Archived entries are unavailable for new selections. When multiple entries are allowed, Maximum selections sets how many a job can choose, up to 100. Turn on per-job wording in the field's settings when a job should be able to replace a selected entry's title or description. Details per selection and repeatable details are profile-only.
Read the configuration via the API
Headless clients can read the board's job form configuration before rendering their own posting 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.
To read or change the field order, visibility and required state of the job, company and talent forms, use:
PUT accepts one or more of job, company and talent, each the full ordered list, and runs the same checks as Settings, including the Google for Jobs locks. A rejected list returns 400 with each offending field in error.details.issues, and nothing is saved. Reading needs settings.read; writing needs settings.manage.
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:
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:
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