Adding Posting Specific Questions to Your Application Form

Fields are defined per posting, not company wide. You add them from the Custom Application Fields section at the bottom of the posting form, and the moment you save they appear on the application form of that posting. If the posting is deleted, the field definitions go with it.

Every field has a label, a type, a position in the order and two checkboxes: Required and Show on form. The order is set with up and down arrows in the panel; what the candidate sees is the order you see. A help text of up to 240 characters can be written under a field.

If you define no fields at all, the form keeps looking exactly as it does today. That default is deliberate: embedded forms already live on customer sites, and a new field should never change them.

• Five field types: Short text, Long text, Dropdown, Multiple choice, Date
• Up to 20 fields per posting, up to 50 options per field
• A second field cannot use the same label; the comparison runs with Turkish lowercasing, so a label typed in capitals and the same label in lower case count as one
• A field with "Show on form" switched off never reaches the candidate, while the definition and the answers already given stay in place
• Dropdown and multiple choice fields need at least one option, and the same option cannot be listed twice

When the form is submitted, the server revalidates the incoming answers against the field definitions currently shown on that posting. Nothing is accepted just because the browser sent it: a submission that breaks a rule is rejected and the application is not saved.

The rule is written into one shared definition rather than into individual screens. Had it been buried inside a screen, the next write path would have skipped it; that is why both the panel and the public form pass through the same definition. The panel runs the definition the server uses before saving, so an empty label or an option free dropdown comes back as a warning in the form rather than an error from the server.

A required field errors not only on an empty submission but also when the answer is not sent at all. An optional field left blank is not stored as an empty string, it is not stored at all; the application detail shows only answers that were genuinely filled in.

Answers are stored on the application record itself. In the panel they sit on the application detail under the Position Specific Questions heading as label and answer pairs; a multiple choice answer is joined with commas.

An answer is never written on its own, it is written with a snapshot: the field id, label, type and value are stored together. That is why renaming a field later leaves old applications reading with the old label while new ones read with the new one.

This is a record keeping choice rather than retroactive correction: an application detail is the record of what the form asked that day. When you remove a field from the editor the definition is soft deleted, and the answers keep reading because each one carries its own snapshot.

Answers enter the evidence pool of the position fit evaluation in "Label: answer" form. The rule based scorer and the model therefore see the same form facts. Before this was fixed, answers were handed only to the caller and the model was scoring a criterion whose answer it had never seen.

What a form answer buys you is the information a CV usually does not carry: a driving license, shift availability, a work permit, the date of a specific certificate. When the CV cannot show these, the form is the only source.

An answer is a declaration, not evidence, and it is marked as such inside the system; a candidate saying "yes" does not count as verified in the CV. HR makes the decision: neither AI nor a form answer changes the status of an application on its own.

There is no conditional question logic. You cannot define a rule saying "show this question to whoever answered that"; the fields you define appear to every applicant in the same order.

Custom fields work on job postings. Internship postings stay in their own flow and take applications with their core fields.

Saving a field set requires posting update rights and the edit is written to the activity log. A save that only changes the status never touches the field set; sending an empty set from the posting form, on the other hand, removes every defined field.

• Switching a field type from choice to text drops the options entered, and they do not come back
• 20 fields and 50 options are hard limits; at the limit the "Add field" button closes in the panel and the API rejects as well
• The only way an answer gets in is the public application form; there is no retroactive entry or bulk fill from the panel
• Defining fields is not tied to a plan, but moving a posting to Active spends one of the active posting slots on your plan
• The same questions appear identically on the career page form and in the embedded form