Your shape, not ours
Every tracker lets you add a field. Nobody fills it in.
Six months after go-live the custom fields are empty, the team has gone back to the notes box, and the reporting you bought them for cannot be run. The feature was never the field. It was who was expected to type in it.
The part that changes the outcome
The reader fills them, and shows you the line it used.
When a CV is read, your own fields are filled from it — not just the standard ones. And each value carries the sentence it came from, so a field you did not type is still a field you can check.
That is the difference between a schema and a habit. A recruiter will not maintain twelve fields by hand. They will correct two that were filled wrong.
- Team size managed9“Managed a team of nine across two locations.”
- Regulated-industry exposureYes · banking“Four years at a scheduled commercial bank.”
- PAN— not readCredential · never sent to the reader
- Current CTC on file— not readFinancial · never sent to the reader
- Date of birth— not readPersonal · never sent to the reader
And the ones it refuses
A field can be classified, and classification is enforced.
Mark a field personal, financial or a credential and it is never sent to the reader. Not redacted afterwards, not filtered from the output — not sent.
This matters more than it sounds. The moment a product can auto-fill your fields, every field you hold becomes something that might be handed to a model. A date of birth, a PAN, a salary on file. The classification is how you decide that in advance rather than discovering it in a security review.
- Typed, not free text —
Validated when written and merged on edit, so a field means the same thing in a report as it did on the record.
- Corrections stick —
Fix a filled value and the correction is captured against that record; the corrected value is what the next round treats as true.
- Eight ready-made packs —
Diversity, regulated industries, executive search, contract staffing, bench, campus and more — installed in one click so a new workspace starts with a usable shape instead of an empty one.
- On more than the candidate —
Roles and client accounts carry them too, which is where most of the reporting questions actually live.
The limit, said plainly
They are not searchable in the query language yet.
You can filter and report on them, and they are on the record wherever the record is. What you cannot do today is use one inside a boolean search string alongside skills and titles — the search parser works from a fixed set of fields and does not yet know about yours.
If your sourcing runs on long boolean strings and you were planning to put a custom field inside one, that is the thing to raise on the call.
Asked by anyone who has done this before
Four answers, two of them no.
›Who fills them in?
The reader does, from the document, with the source line attached. Your team corrects rather than types, which is the only version of this that survives contact with a busy desk.
›Can we stop the AI seeing a sensitive field?
Yes — classify it personal, financial or a credential and it is never sent. That is a property of the field, not a setting somebody has to remember per run.
›Can we search on a custom field in a boolean string?
Not today. The parser has a fixed field list. Filtering and reporting work; the query language does not know your fields yet.
›Can we expose a custom field to a client in their portal?
No. Custom fields do not reach the portals, and there is no per-client visibility setting for them. What a client sees is governed by the submission's own masking.
›Do we have to design our own from scratch?
No — start from one of the packs and delete what you do not want. Most teams find that faster than an empty screen and a workshop.
Book a demo
Bring the twelve fields you keep in a spreadsheet.
We will install a pack, run one CV through it, and you can see how many filled themselves — and which ones we refused to read.