TL;DR

Custom fields are user-defined data fields added to candidate, job, or contact records in an ATS or CRM to capture information the standard system schema does not include. They allow recruitment teams to track client-specific requirements, sourcing data, compliance flags, or any other structured information that matters to their specific process without modifying the underlying database.

How Custom Fields Work

Custom fields extend the data model of a platform by adding new attributes to existing record types. In Bullhorn, an administrator can add a custom field to the Candidate entity called "Security Clearance Level" with a dropdown of values: None, Confidential, Secret, Top Secret. Every candidate record now has that field, and it can be searched, filtered, and reported on like any native field.

Field types matter significantly. Most platforms support text fields, number fields, date fields, dropdown/select lists, multi-select lists, checkboxes, and URL fields. Choosing the wrong type creates data quality problems - a free-text field for clearance level means some records say "TS", others say "Top Secret", others say "TS/SCI", making the field unsearchable. A properly configured dropdown enforces consistent values.

Custom fields in modern ATS platforms appear in the API alongside native fields. A candidate record retrieved from Bullhorn's API returns both standard fields (firstName, lastName, email) and custom fields (customText1, customText2, or named fields if the platform supports field aliases). This means integrations can read and write custom field data without special handling - they behave identically to built-in fields from an API perspective.

The scope of custom fields varies by platform. Greenhouse supports custom fields on jobs, candidates, applications, and offers. Lever supports custom fields on opportunities and contacts. Bullhorn supports custom fields on virtually every entity type and allows up to 100 custom text fields, 20 date fields, 10 integer fields, and so on per entity - a generous limit that few agencies exhaust.

Why It Matters in Recruitment

Every recruitment operation has data requirements that no off-the-shelf ATS anticipated. A healthcare staffing agency needs to track nurse license expiration dates, certifications, and clinical specializations. A government contractor needs security clearance levels and last investigation dates. A technology staffing firm needs to capture preferred tech stacks, remote work preferences, and visa status details beyond the standard fields.

Without custom fields, teams work around the system - putting critical information in notes fields, maintaining parallel spreadsheets, or using a naming convention in the resume upload field. These workarounds fail at scale. A 50,000-candidate database with security clearance data buried in unstructured notes is functionally the same as not having that data at all.

Custom fields also power advanced automation. An ATS workflow can be configured to trigger only when a specific custom field has a specific value. A sourcing automation rule can filter candidates whose "Available to Start" custom date field falls within the next 30 days. The structured data in custom fields is what makes rule-based automation possible.

Custom Fields in Practice

A staffing agency serving defense contractors in Virginia built a custom field schema in Bullhorn over their first year of operation: 12 custom fields on the Candidate entity covering clearance level, investigation type, last reinvestigation date, polygraph status, SCI access, and citizenship. These fields are mandatory for every candidate record.

When a cleared role opens, their Bullhorn search takes 30 seconds: filter for candidates with Top Secret clearance who have an active SCI and are available within 60 days. Without the structured custom fields, the same search would require manually reviewing hundreds of notes fields or maintaining a separate spreadsheet. With them, recruiters find pre-vetted shortlists instantly.

Platforms like Candidately can read these custom fields through the Bullhorn API and incorporate them into AI matching logic, surfacing candidates whose custom field values align with job requirements rather than treating those fields as invisible data.

Key Considerations

Data governance for custom fields is frequently neglected until it becomes a problem. Field proliferation - creating new fields without deprecating old ones - leads to records with 40 partially populated custom fields and no clear ownership. Establish a custom field review process: document every field, its owner, its purpose, and the last date it was meaningfully populated. Fields that have been empty for 12 months should be retired.