TalentVare BRD — Design Mocks

How to read these. Every page carries an amber ribbon at the top naming its BRD section and whose view it is drawn from. Dialogs, steppers and segmented controls work — click them. Dimmed sidebar items are existing shipped screens or not-yet-drafted sections; they are inert by design so nothing links nowhere. A dashed switcher appears on candidate-portal pages so you can see states a real candidate would only reach one of.

Anything marked Proposed is an addition to the BRD, not a requirement from it. Anything marked Decision is a design call that needs confirming — they are listed at the bottom of this page. Updated 24 Sep marks what changed after the recruitment-flow review.

Recruitment process agreed 24 Sep 2026 10 steps

The flow end to end, in one place. Everything from interviews onwards is as the BRD had it; the changes are in how a request becomes a job and how candidates get to an interview.

1 Raises a hiring request · Department Head From the Requests tab, like any other request. Names a responsible person for the job and can mark must-have skills. Hiring Request

2 The request goes through its approval cycle · Approvers ED, then MD where configured. Rejection needs a reason and ends the request. Hiring Request Approvals

3 On approval it becomes a job and HR is emailed · System The email links straight to the job’s page. HR’s Jobs list shows open jobs by default, with other statuses one filter away. Jobs

4 Each job has its own page · HR Tabs for Details, Applied Candidates, Interviews and Offers. The public job link is generated here. Job Detail

5 Applies through a candidate account · Candidate One way in for everyone: the public link and HR’s email invite are the same link. Create an account (email verified) or sign in, build the profile once (a CV upload fills it in), then apply. The profile is kept for future jobs. Public posting HR invite Sign-up Profile builder Candidate home

6 Can also add people from the pool · HR Resume Search → Add to Job. They appear on the job alongside those who applied. Resume Search

7 Shortlists who moves forward · Responsible person From the job’s Applied Candidates. A proposed match threshold sets weak matches aside. Anyone not shortlisted stays in the pool but is not interviewed for this job. Applied Candidates

8 Screens each shortlisted candidate, once · HR A short call with standard questions, saved on the candidate. Someone screened for an earlier job skips straight to interview. Screening form On the profile

9 Interviews and feedback · HR · panel Unchanged from the BRD: cycles, hierarchy or ad hoc panel, Yes/No feedback. Interviews Feedback

10 Finalise, offer, accept · HR · MD · candidate Unchanged: Selected / Hold / Rejected, generated offer (HR can now also attach the firm’s own letter), MD signs, candidate accepts. When all positions are filled the job is Fulfilled. Finalise Offer Offer response

Start here 1 screen

Home Existing app All employees home.html The current TalentVare home screen, rebuilt as a mock to establish the baseline the new modules sit inside. Navbar, hero banner, quick links and broadcast panel.

Pre-boarding BRD §3 10 screens

Hiring request through to a finalised candidate. The request lives in Requests, the approval inbox in Approvals, and everything after approval in the new Recruitment tab, organised around jobs.

Hiring Request §3.1 Department Head hiring-requests.html The raiser’s own requests plus the Raise Request form, which previews the full approval route before submit. Moved from Recruitment to the Requests tab; approved rows open their job. Updated 24 Sep Proposed Positions count · responsible person · must-have skills Hiring Request Approvals §3.1 Exec Director · MD approvals-hiring-request.html The approver inbox. A new inbox alongside the five shipped ones, so it reuses the Approvals module rather than inventing anything. Reject has its own dialog with a required reason. Jobs Not in BRD HR jobs-list.html Approved requests, as jobs. Open by default; pending, fulfilled and rejected are a filter away. Shows the responsible person, positions filled and whether the public link is live. New 24 Sep Decision 9 “Jobs” or “Positions” — client to name it Job Detail Not in BRD HR · Responsible person job-detail.html One page per job: Details, Applied Candidates, Interviews, Offers. Shortlisting by the responsible person and HR’s screening form live on Applied Candidates. New 24 Sep Proposed Decision 10–11 Match threshold · screening questions Public Job Posting Not in BRD Public · unauthenticated careers-job-posting.html A shareable page for one open job, for LinkedIn or a job board. Applying now means creating a candidate account or signing in, and HR invitations send this same link. Updated 24 Sep Its two open questions (unverified submissions, candidate state) are closed by the account model Candidates §3.2 HR candidates-list.html Every candidate across all jobs, plus the Invite Candidate form with a duplicate-account guard. The invite emails the job’s own link, and there is no separate expiry. Updated 24 Sep Resume Search §3.3 HR resume-search.html The pool. Faceted search where checking a skill reveals a minimum expertise-level picker. Add to Job puts someone on a job’s Applied Candidates. Updated 24 Sep Decision 1 Decision 2 Result list not a table · age facet Interviews §3.4 HR interviews-list.html Schedule with auto-numbered cycles, panel picked from the approval hierarchy or ad hoc, and physical/virtual branching to office room or Zoom/Teams. Only screened candidates can be scheduled. BRD ambiguity resolved §3.4’s panel-source sentence fuses two ideas; the form makes it an explicit choice Interview Feedback §3.5 Panel member interview-feedback.html Comments and a Yes/No, exactly as §3.5 specifies — no invented scorecards. Previous cycles are visible to the panel member, not just to HR. Decision 5 Feedback blind within a cycle Candidate Profile & Finalisation §3.5–3.6 HR candidate-detail.html Resume, the candidate’s one screening record, all cycles with feedback retained, and the Finalize dialog whose three outcome buttons switch the form. Updated 24 Sep Proposed Screening section · Hold-until exit path (§3.6 names Hold but defines no way out of it)

Offer BRD §4.1 3 screens

Generation, MD signature, then sending. The gate chain is stricter than it looks — approval applies the signature but does not send the offer.

Offers §4.1 HR offers-list.html All offers by stage, including the “Signed — not sent” resting state HR most reliably forgets about. The Accepted row links through to its onboarding case. Offer Letter Generator §4.1 HR offer-generator.html Name, salary and joining date are read-only with their provenance — editing them here would detach the offer from the decision it must reflect. Merged values are tinted in the letter preview. HR can also attach the firm’s own formatted letter. Updated 24 Sep Offer Review §4.1 Managing Director approvals-offer-review.html The three fields §4.1 asks the MD to check, pulled out above the letter with variances flagged. Approve-and-Sign states plainly that it does not send. Decision 3 Send-back as versioned re-issue, not an approval-engine rewind

Candidate portal BRD §3.2, §4.2 4 screens

External, pre-employment. No module tabs, no sidebar, no employee identity — the one part of the BRD with no precedent in the existing app. It reuses the app's visual language deliberately, so a candidate's first contact still looks like Transvare. Since 24 Sep every candidate has an account, so the portal is somewhere a candidate comes back to, not a single-use form.

Sign-up & Sign-in §3.2 Candidate portal-invite.html The one entry point, from the public link or an HR invite: email, 6-digit code, password, or sign in to an existing account. Five states switchable at the top. Updated 24 Sep Invitation-expired and already-used states replaced by a single “job closed” state Profile Builder §3.2 Candidate portal-resume.html Six steps, all walkable, built once per account. Fill from your CV pre-fills them for the candidate to check. The expertise scale carries word labels, Basic through Expert. Updated 24 Sep My Applications & Open Roles Not in BRD Candidate portal-jobs.html Where a signed-in candidate lands: every application with a coarse status, other open roles to apply to in one click, and the saved profile. New 24 Sep Offer Response §4.2 Candidate portal-offer.html The signed letter with only Accept and Reject available, per the §4.2 criterion. Four states switchable. Rejection's reason is optional on purpose. Un-specified state drawn Offer expiry — the letter states a validity date, so the buttons must stop working

Onboarding BRD §4.3–4.6 5 screens

New Lifecycle tab. One case, one page: checklist items are grouped by owner and only actionable if you own them, so every role sees the whole picture without being able to tick someone else's box.

Onboarding Cases §4.3–4.6 HR onboarding-list.html All cases with per-owner progress. No Create action — cases are generated automatically on offer acceptance. Onboarding Case §4.3–4.6 HR · read-only for others onboarding-case.html The pattern-setting screen. Five owner-grouped sections, activation gated on mandatory items. Five more screens inherit this shape. My Onboarding §4.3 New employee onboarding-my-details.html Employee self-service: personal, contact, emergency contact, education, bank details, documents. All six sections walkable. IT Onboarding Tasks §4.4 IT Administrator it-checklist.html A queue across cases, not case-by-case — IT works a worklist. Mailbox creation and asset assignment. Application Provisioning §4.5 Administrator provisioning.html Per-app accounts and roles across TalentVare, TaskVare and SalesVare, with pre-flight checks that satisfy the “duplicate accounts are prevented” criterion.

Offboarding BRD §5 3 screens

Separation through to a deactivated, archived employee. Same case pattern as onboarding, pointed the other way.

Separation §5.1 HR separation-list.html Cases plus the Initiate Separation form, which warns up front if the leaver manages people or owes approvals — discovering that at the deactivation gate is what causes deadlock. Exit Clearance §5.2–5.3 HR · read-only for others exit-clearance.html Four department clearances plus the pending-transaction gate, styled as a hard block rather than another checklist because it is what actually stops deactivation. Proposed ×2 Approver reassignment · audited override — without both, §5.3 can deadlock permanently Deactivate & Archive §5.4 HR · IT deactivate-archive.html The terminal screen. Automated versus manual revocation, the Active→Inactive transition, and what is retained for audit versus what stops immediately. Decision 6 Retention split — 7 years for documents, indefinite for transactional history

Decisions needed 11 open

Design calls made to keep the mocks coherent. Each is reversible, but each should be confirmed or overruled before build.

1 Resume Search results are a list, not an AppTable Every other screen is a table because it is a worklist. This is browse-and-compare: skills, levels, institute and location need to be visible at once, which a fixed-width row cannot carry. The one deliberate break from the app's convention. resume-search.html

2 Keep the Age search facet? §3.3 lists age as a filter, so it is built — but filtering candidates by age is a discrimination exposure in several jurisdictions. Needs a call from whoever owns compliance, not a UI decision. resume-search.html — hint sits on the facet itself

3 Offer send-back as a versioned re-issue, not an engine rewind Sending back closes v1 as Returned and HR issues v2. Every other TalentVare flow terminates on rejection, so adding rewind for offers alone would be new approval-engine behaviour. This way costs nothing and yields a version history the audit trail wants. approvals-offer-review.html

4 Recruitment and Lifecycle placed after Employee Directory in the navbar The commented-out stubs in the app sit at the end of the tab list. Placing them early makes the nav read in lifecycle order; moving them back is a one-line change. shell.js — visible on every mock's navbar

5 Interview feedback is blind within a cycle A panel member sees earlier cycles but not a colleague's feedback for the current one until they have submitted. Not in the BRD — but a panel where the second member reads the first's verdict is not collecting two independent opinions. interview-feedback.html

6 Retention splits by data type Identity documents and bank details get a 7-year statutory default; timesheets, leave and approval history are kept indefinitely so historical reports keep resolving names. §5.4 says only “historical records remain available for audit” — this is an interpretation a compliance reviewer should confirm. deactivate-archive.html

7 Proposed Approver reassignment and an audited override on §5.3 A departing approver's pending approvals belong to other people's requests, so waiting can never clear them — they must be reassigned. And a termination sometimes must complete despite an unresolved expense claim; security should not wait on bookkeeping. Without both, §5.3 as written can block a deactivation permanently. exit-clearance.html — both tagged Proposed on screen

8 Proposed A way out of the Hold outcome §3.6 names Hold as an outcome but defines no exit, so a held candidate would sit in the pipeline indefinitely. Hold-until plus a reason turns it into a dated reminder while the resume stays searchable. candidate-detail.html — Finalize dialog, Hold branch

9 Name for approved requests: “Jobs” or “Positions” Raised in the 24 Sep review. HR’s list is drawn as Jobs for now, and the client picks the final word. Renaming is a label change only. jobs-list.html — and the Recruitment sidebar

10 Proposed A match threshold (ATS) on each job Applicants are scored against the job’s skills and experience. Below the threshold (70% drawn), or missing a must-have skill, they are set aside rather than shown first. Nobody is auto-rejected. Raised in the review as a small feature that still needs scoping: how the score is computed, and whether the threshold is per job or global. job-detail.html — Details tab and the Applied Candidates filter; must-have stars on hiring-requests.html

11 Screening questions and fields Screening is agreed (once per candidate, before the first interview). The question set drawn is a placeholder based on what HR typically asks. The client’s HR needs to confirm theirs, along with the hiring request’s final field list. job-detail.html — Conduct Screening dialog

Gaps in the BRD itself

Not drawn, because the document has no screen for them. Raised here so they are decided rather than discovered during build.

No employee-initiated resignation. §2 names “Separation / Resignation”, but §5.1 is HR-initiated only — there is no screen for an employee submitting their own notice.

No notification matrix and no non-functional requirements. Roughly fifteen email templates are implied across these flows — invitations, interview invites, offer delivery, clearance nudges, reminders — and none are specified.

Planned next, not drawn. Two flows for active employees, agreed to follow once this recruitment cycle is built: appraisals, and the probation evaluation every 30 days over a minimum three-month probation, ending in a confirm or extend decision.

Reports and master data are out of scope here. Recruitment funnel, onboarding status and exit status reports, plus a Manage Data asset register, offer templates and checklist templates, were recommended during the architecture review but are not BRD requirements. Not drawn.

Employee Lifecycle Management — design mocks