A client portal is useful when it gives a hiring team a clear, current view of the candidates you deliberately present — and gives your recruiters a reliable place to receive the decision. It is not a promise of faster hiring or a replacement for client conversations.
The practical question is simple: what should this client see for this mandate, what may they do with it, and how will your team record the next step? A good portal process answers those questions before the link is shared.
Choose the collaboration mode before sending a link
Yena documents two distinct modes. A hand-picked shortlist lets the recruiter add only selected pipeline candidates. A live pipeline lets the client follow candidates in the stages the recruiter allows. Existing portals remain hand-picked until the live option is deliberately enabled.
For a confidential executive-search presentation, start with the hand-picked mode and decide which candidates belong in the client view. For a retained search with regular status reviews, live sharing may be appropriate — but configure the allowed stages and visible fields first. The client portal is a view of the mandate, not a mirror of your internal ATS.
What Yena’s documented client workflow includes
- Create the portal from the job. One portal workspace can carry several projects for the same client while feedback remains project-specific.
- Select the presentation set. Add candidates manually, or configure presentation stages such as Longlist or Shortlist to add them automatically. Moving someone out of a configured stage does not remove them automatically; removal remains deliberate.
- Set presentation rules. Per-job controls cover career history, documents, criteria, match score, skills, notes and contact details. In live mode, stage and field controls determine what leaves the workspace.
- Choose the client’s decisions. The documented portal supports Approve, Decline, On hold and Waiting. Criteria can be answered Yes, No or Open, with a reason for the client’s view.
- Review AI suggestions before sharing. Yena’s criteria suggestions are drafts; a recruiter confirms the evidence before it reaches the client.
- Check branding and access. Client branding, Anonymize Names, Allow Downloads, Allow Feedback, Manage Access and the Live switch are separate decisions.
See the supporting product documentation for sharing a shortlist, live pipeline sharing, criteria and client decisions, portal settings and portal projects.
A recommended process around the product
The controls above are product features. Your operating process still needs an owner. Before sending a link, name the client decision-maker, record the shortlist or project label, agree the next review point, and confirm which candidate information is appropriate for the mandate. After a decision, record the reason and owner for the next action in your recruiting CRM.
This separation matters. Yena provides candidate presentation, feedback and visibility controls; the support documentation does not establish an automatic escalation or a native shortlist-version history. Keep those conventions explicit in your team’s workflow and confirm the current setup in a demo.
Fictional worked example: one mandate, two review batches
Fictional example, not a customer result: Northbank Search is running a Finance Director mandate. The consultant creates one client portal project, names it “Finance Director” for the client, adds three recruiter-approved candidates to Batch 1 and enables feedback. The client marks one candidate Approve, one On hold and one Decline with a reason. The consultant records the decision and next owner in the CRM, then adds the next deliberate presentation as Batch 2 within the same project. Before sharing, the consultant reviews visible fields, notes and documents; they do not assume that an unrelated mandate is excluded without checking the portal configuration.
| Decision | Client view | Recommended team action |
|---|---|---|
| Approve | Candidate is ready for the agreed next conversation | Assign the scheduling or briefing owner |
| On hold | Candidate remains visible with a parked decision | Record what information or timing is missing |
| Decline | Candidate is not selected for this mandate | Record the client’s reason and handle candidate communication separately |
Access, downloads and anonymization need honest boundaries
Restrict the portal to the people and fields needed for the decision. Anonymize Names can hide identities in the portal, but it cannot prevent re-identification from visible CV details, screenshots, downloads or information a recipient already knows. Allow Downloads should be enabled only when the mandate requires a local copy, because revoking a portal link cannot remotely erase a file already saved by a recipient.
For a deeper buyer-side checklist, read Client Portal Access Review for Recruitment Agencies. It covers identity, mandate scope, expiry, downloads and review responsibilities; it should be read as operational guidance, not as a claim that every control is automatic in Yena.
When a portal is not the right fit
A portal adds little when a client wants a single occasional update, when the mandate has no shared review step, or when your team has not agreed what may be shown. Start with a clear presentation process and a small fictional test mandate. Expand the workflow only when the client and recruiter can use the shared view without ambiguity.
If your agency also accepts inbound applications, keep that candidate-facing flow separate from client collaboration; the CV-first career-site setup guide covers the public application and human review path.
Try the workflow with a fictional mandate
Explore the Yena client portal alongside the recruiting CRM, then test the candidate set, field visibility, feedback decisions and access changes with data that does not identify a real person. If the workflow fits your agency, you can start a 10-day free trial.