Candidate portals versus email-only applications

A candidate portal is a structured apply form tied to a job. Email-only apply is a CV in an inbox that someone must file. The operating difference is the record: complete fields and a stable identity versus attachments that may never become an application. This page compares those intake paths. It does not define applicant-tracking software — that stays on what an ATS is. It does not retell spreadsheet-versus-ATS tracking. Commercial context is Dayzen recruitment, which includes public application portals and an internal job board. That is not a claim that Dayzen posts every opening to every job marketplace. How internal and public audiences share one job object is a sibling: internal versus public job openings.

Email is faster to start. A portal is harder to lose. Most teams that “just take CVs on hr@” eventually rebuild a portal in a spreadsheet. The question is whether the apply step writes a first-class application or creates a filing chore.

What each path actually captures

On a portal apply, the candidate submits against a specific job. You can require name, email, phone, and the questions you care about (notice, location, eligibility you actually ask). The system can reject an incomplete submit. You get an application ID, a timestamp, and a person key you can search. Duplicates are still possible (two emails), but you have fields to match on.

On email apply, you capture whatever they attached and whatever the subject line says. You may not get a job ID if they mailed a generic inbox. You may get a scan of a CV with a different spelling of the name than the From: header. Someone in talent acquisition must create the application by hand, or the CV sits in a folder named “April.” Completeness is optional from the candidate’s point of view. Your process pays the cost later, at screen.

Neither path is “more ATS.” An ATS is the category of system that holds jobs, people, and applications. The guide already owns that definition. A portal is an intake surface that writes into that system. Email is an intake surface that usually does not, until a human copies it.

Completeness and required fields

Portals shine when missing data is expensive. If you always need a phone number, a work-authorisation answer you are allowed to ask, or a yes/no on relocation, a required field beats a follow-up mail that 40 percent of people ignore. Keep the form short. Every extra question drops completion and invites junk. Ask for what screeners will use in the first pass. Do not rebuild the entire employee-information checklist on a public apply form. That checklist owns ongoing master data after hire, not this intake.

Email shines when the audience will not fill forms: senior referrals, a founder forwarding a PDF, a campus coordinator sending a zip of CVs. Forcing those through a portal can lose the hire. The operational move is not to pretend email is a portal. It is to file promptly: create the application against the correct job the same day, copy identity fields from the CV, and attach the original mail. Until that happens, you do not have an applicant in the pipeline. You have a message.

Write a rule for mixed intake. Example: public ads point only at the portal; employee referrals may start as mail but must be entered as applications before anyone schedules. If you allow both and file neither, you will interview people who do not exist in the board, then wonder why rejected-state hygiene fails.

Duplicates and identity

Email duplicates are classic: the same human sends two CVs a week apart, or applies to two subject lines that look like two jobs. Without search, you create two cards. Portal duplicates happen when they use a second email or a typo. The portal at least gives you a structured email and phone to match. Process:

• Search by email, then phone, then name plus a second key, before creating a person.
• Allow multiple applications per person across jobs. That is not a duplicate identity.
• Treat two people records with the same personal email as a merge candidate, not as “fresh talent.”

Do not merge applications across jobs just because the CV looks similar. Do not refuse a second apply to a new opening because they were rejected last year without reading the new JD. Identity hygiene is not a lifetime ban. After hire, duplicate employee rows are a different failure — see the duplicate employee records article when you convert. At apply time, the goal is one candidate identity and many applications if they applied many times.

Who owns the record

On a portal, the candidate creates the first draft of the record. Recruiters still own whether it is complete enough to screen, whether it is spam, and whether it is the right job. On email, the recruiter (or a coordinator) is the author of the record. If they do not file, nobody owns it. That is the hidden cost of “easy apply”: ownership is delayed until someone feels like uploading.

Name the owner of the inbox. A shared hr@ with no rotation is a black hole. If you keep email intake, publish: who reads, SLA to file or reply, and what happens to mails that are not applications (vendor pitches, employee issues). Do not use the same inbox for payroll queries and CVs. Mixing those is how offers get buried under PF forwards.

Dayzen recruitment’s public application portals write structured applies against jobs you create. The internal job board is for employees applying as insiders, which is still a structured apply, not a slack DM. Neither surface is marketplace syndication. If you still post on an external board, point the apply button back at the portal that creates your application object. Multiple inboxes plus multiple boards with slightly different titles is how you get slightly different candidate sets you cannot reconcile.

Candidate experience versus recruiter experience

Candidates like email because they already have a CV and they distrust long forms. They like portals when the form is short, mobile-usable, and confirms that the apply landed. They hate portals that demand a new account, a second CV parse, and twenty fields before submit. They hate email when they never receive an acknowledgement and cannot see status.

Recruiters like email when volume is tiny and every CV is a known referral. They like portals when volume is real and they refuse to be a copy desk. Hybrid reality: portal as default, email as exception with a filing rule. Status visibility — “we received this” — is easier when the apply created a row. Acknowledgement mails from a raw inbox are easy to forget; a portal can send a receipt when the application exists.

Do not promise a public status tracker you will not run. A receipt plus honest later communication beats a fake login where everything stays “In review” for months. Closing rejected applications is a sibling topic; intake should still produce a row you can later close.

Operational tradeoffs in one view

	Public / internal portal	Email-only
Unit created at apply	Application against a job	Message; application optional
Required fields	Enforceable	Hope and follow-up
Duplicates	Matchable keys	Easy to miss
Time to first record	Immediate	Whenever someone files
Setup cost	Job + form + link	An address you already have
Failure mode	Over-long form, drop-off	Lost attachments, ghost process
Dayzen surface	Public portals; internal board	Not the system of record until filed

Choose by volume and by whether you will honour the filing step. Ten applies a month can survive email if you file the same day. Fifty applies a week will not. Do not pick email because the portal “felt like software we do not need,” then run a Kanban of people who only exist in Gmail.

Spam, completeness theatre, and privacy hygiene

Portals attract bots and scattershot applies. Use the minimum friction that still keeps the form human (a simple check you actually maintain), and screen. Do not add a dozen essay questions as a bot filter; serious people leave. Email attracts forwards, password-protected CVs, and 8 MB scans. Neither path eliminates junk. Junk on a portal is at least a row you can reject with a reason. Junk in an inbox is often silently ignored, which is still a communication failure if they thought they applied.

Collect only what you will use at this stage. A public form that asks for bank details or identity numbers you do not need to screen is a bad habit. This page is not DPDP legal advice. It is intake design: if screeners will not read it, do not require it. Store attachments with the application, not in a desktop folder named after the recruiter who happened to be on shift.

A working agreement for mixed channels

1. Every live job has one official public apply link (the portal) and, if you use it, one internal board posting — not five subject lines.
2. Email applies are allowed only on named exceptions (referral, executive search) and must become applications within your published filing window.
3. We search identity before creating a second person.
4. We do not treat marketplace posting as a Dayzen feature; copies of ads still point home to the portal.
5. We do not debate what an ATS is on this page; we debate whether apply created a record.

Use Dayzen public application portals and the internal job board as the surfaces that write jobs and applications you can later screen, interview, and close. Use email as a pipe into that record, not as a substitute for it. Keep the ATS guide as the category definition. Keep internal-versus-public as the audience question. This article is only whether the first click produced a file you can run hiring on, or a message you might remember to upload.