A recruiter opens a candidate profile and finds three versions of the same fact. The application says one location, a note says another, and an AI summary picked a third. Adding more custom fields will not resolve that disagreement. Your team needs to decide what each field means, where its value comes from and who can correct it before an agent starts writing.
Greenhouse custom candidate fields provide a structured place for information beyond the default profile fields. This guide covers how to configure that structure and design a reviewed AI update process around it. The evidence queue and write controls below are engineering recommendations, not claims that Greenhouse supplies a complete AI approval system.
Start with an inventory of existing fields
Greenhouse already has default candidate fields including Current Company, Current Title, Timezone, phone number, email address, websites and Education. Check what your organization uses before creating another field with a similar name. Two fields called Current company and Employer create a reconciliation problem if different tools own them.
Ask the recruiting operations owner to list every proposed field with its business purpose. Who reads it? Which task changes because it exists? Which system supplies it? If nobody can answer those questions, leave it out of the first release. Keep the initial workflow small enough that recruiters can inspect every proposed update.
Separate candidate facts from job-specific judgments
A candidate-level fact should remain meaningful when the person is considered for another role. A conclusion such as Strong fit for the platform vacancy depends on a particular job and its requirements. Do not turn that conclusion into a permanent profile label that follows the person into unrelated hiring processes.
Write definitions that distinguish stated information from inferred information. Available from a date is different from an agent guessing availability from an employment history. Unknown should remain unknown until there is an appropriate source. A completed field is not automatically a correct field.
| Proposed information | Definition to agree | Automation boundary |
|---|---|---|
| Preferred work location | Location explicitly stated by the candidate | Do not infer from a phone prefix |
| Availability date | Date supplied for the current recruiting conversation | Keep the evidence date and recheck stale values |
| Research review status | Internal status of an evidence review | Do not present it as candidate qualification |
| Fit for a particular job | Assessment against that job's requirements | Keep it in the appropriate job-specific workflow |
Configure a field only after testing the definition
Creating a custom candidate field requires a Site Admin or a Job Admin who can manage custom fields. In Configure, open Custom Options. Under Company Custom Fields, select Candidates and choose Add Field. Enter the name and description, select the Type, set the relevant options and save.
The important constraint is that the Type cannot be changed after the field is created. Test realistic values before committing to a type. Include missing answers, multiple possible answers, corrections and information that arrives in a different format. Decide whether the workflow needs one approved value or a description that a recruiter must interpret.
Use the field description to state the meaning, source and owner. Avoid a description such as Filled by AI. That says how a value arrives but not what it means. A better description states that the value reflects the candidate's latest explicit response, with uncertain responses left for review.
Check privacy, exports and template use together
Custom candidate fields appear on the Details tab by default. Mark Private restricts profile access to users with access to the Private tab. Test the actual recruiting roles that will read and edit the information. Separately inspect what the integration account can access rather than assuming its permissions match a recruiter viewing the profile.
Greenhouse includes custom fields when candidate details are exported to Excel from the Candidates page. Include that export route in your access review. A field that looks restricted in one screen still needs a clear policy for exported files, AI processing storage and logs. Our candidate retention guide covers the separate problem of external copies.
You can optionally create an email token from a custom candidate field. Keep unreviewed model output out of candidate-facing templates. If an existing email token changes, Greenhouse says the references also need updating in email templates and relevant campaign pools. Add that dependency to the change checklist.
Build a proposal queue before enabling writes
For each suggested update, show the recruiter the candidate identifier, current value, proposed value, supporting source and reason for the change. Store only the evidence needed for review and apply your retention policy. The reviewer should be able to accept, reject or correct a suggestion without editing a prompt.
Begin with read-only proposals. Compare accepted suggestions with rejected ones and inspect the reasons. A model may extract a date correctly but attach it to the wrong event. It may also confuse the candidate's preference with a location mentioned in an employer description. Those are data interpretation failures, not formatting errors.
For the first writable workflow, use an explicit list of approved fields. Reject any attempted change outside that list. Re-read the current value immediately before saving. If a recruiter has changed it since the proposal was generated, stop and ask for a fresh review instead of overwriting newer information.
Test corrections and failures, not just clean examples
- Submit a source with no answer and verify that the existing value is preserved.
- Submit conflicting sources and verify that the proposal goes to review.
- Change a field manually after the proposal is created and check that the write stops.
- Retry an accepted proposal and verify that it does not create repeated side effects.
- Test a private field with the actual user and integration identities.
- Export candidate details and inspect the handling of sensitive values.
Record the reviewer, source reference, before value, after value and outcome for each approved change. Keep rejected proposals distinguishable from failed writes. A rejected suggestion should not be retried as though a network problem prevented completion. Give an operator a clear switch to pause writes while leaving the proposal queue available.
Common mistakes to avoid
Do not copy a current title into a new custom field without checking the default field. Do not treat a missing answer as a negative answer. Do not silently reuse a field for a new meaning because its name is convenient. And do not allow a candidate-wide label to substitute for a recruiter assessing evidence against a specific vacancy.
When replacing a badly typed field, treat it as a migration. Inventory readers, exports, templates and integrations before moving values. Keep an explicit old-to-new mapping and verify consumers before retiring the old path. Review your recruiting tool connections as part of that change.
How Remqa helps
Remqa builds AI agents for recruiting teams around the data and decisions operators actually use. A useful starting scope is one candidate field, one evidence source and a reviewed update queue. Bring a sample profile and the task your recruiters repeat. We can discuss the field definitions, integration boundaries and tests needed before writing into your live ATS.