Inbound
A careers page is a consent problem wearing a marketing hat.
Everybody can host a job list. The part that matters eighteen months later is whether you can show what each applicant agreed to, in the words they were shown, at the moment they agreed to it.
What arrives with an application
The consent, the circumstances, and the reason if it failed a rule.
Consent is recorded as part of the submission — when it was given, the regulation it was given under, the exact wording that was on screen, and the circumstances it came from. It is not a tick stored somewhere else and matched up later.
That is the difference between answering a data request and rebuilding one.
The consent record
- Granted at23 Sep 2026 · 14:07 IST
- ScopeDPDP
- Wordingthe exact sentence they agreed to
- FromIP and browser, recorded
Captured with the submission, not reconstructed from a policy page afterwards.
And the one that failed a rule
They are still recorded. A rule that silently discards applicants leaves you unable to answer what happened to them — so the rule marks the row and gives its reason, and the row survives.
- Knock-out rules run on submission —
A rule that a role cannot wait past sixty days' notice is evaluated as the application arrives, with the reason attached to the row.
- A knocked-out applicant is still recorded —
Flagged, not discarded. A rule that silently drops people leaves you unable to answer what happened to them — which is the wrong answer to give a regulator, and a worse one to give a candidate.
- Nothing reaches your database automatically —
Applications wait in the recruiter inbox. Resolving one creates the candidate; discarding one creates nothing at all.
- Bot traffic is filtered before it counts —
A challenge on the form and a spam score on the row, so a posting that gets scraped does not become a morning of triage.
Being straight about this one
The parts that are not finished.
This is the least finished surface in the hiring module, and we would rather you heard it here.
The application form is a fixed set of fields today. There is a form builder in the product and the page will accept whatever you design, but the public form does not yet render it — so custom questions exist in the settings and not on the page an applicant sees. There is no resume upload. Your own domain and your own branding are settings that nothing reads yet.
What works is the part underneath: the posting, the consent, the rules, the filtering, and the inbox. If your evaluation turns on the applicant-facing polish, this is the page to be sceptical about, and we will show you exactly where it stands rather than demo around it.
What people ask
Answers, including four noes.
›Can candidates attach a CV?
No. Not today. This is the first thing most teams ask and the honest answer is that the public form does not take a file.
›Can we design our own application form?
You can build one, and the page will accept the answers. The public form does not render your design yet, so in practice applicants see the standard set of fields.
›Can we run it on our own domain, with our branding?
Not yet. The settings are there; nothing reads them. It runs on a CogniYukti address today.
›Will our jobs show up in Google's job results?
Not yet — the pages do not emit job structured data. Worth knowing before you plan any inbound around it.
›What happens to somebody a knock-out rule catches?
The application is recorded and flagged with the reason the rule gave. They are not deleted and they are not hidden from you, which means a recruiter can override it.
›Does an application become a candidate record straight away?
No. It waits in the recruiter inbox. That is deliberate — a careers page that works is also the fastest way to fill a database with noise.
Book a demo
Send a real application through it.
Then open the consent record on the row. That is the part worth judging, and it is the part that is finished.