Governance reference · Role-based workflows
Role-based hiring workflows that scope candidate data to the work
Candidate data is sensitive and incidental exposure is a real workflow risk. Role-based hiring workflows scope visibility to the recruiter, hiring manager, or administrator who needs it for the work in front of them.
Role-based hiring workflows use role-based access controls and tenant isolation to scope candidate data to the recruiter, hiring manager, or administrator who needs it.
Why scoped access is a workflow property
Open access produces incidental exposure that nobody intended. Scoped access keeps candidate visibility tied to the work each role is actually responsible for.
What each role sees
- Recruiters: the roles they own, end to end.
- Hiring managers: the requisitions they sponsor and shortlists prepared for them.
- Administrators: workspace-level configuration and access history.
Tenant isolation as the workspace boundary
Tenant isolation keeps each customer's hiring data inside their own workspace. Role-based access then scopes visibility inside that boundary. The two together define the data perimeter for every workflow.
Access events as workflow record
Access at the role and workspace level is part of the same workflow record that holds criteria, ranking, and shortlist decisions. Reviewers see who accessed what, when, and why.
Workspace-scoped role definitions
Role definitions can be customised per workspace so customers can match their internal hiring model — without affecting the underlying governance properties.
Operational outcomes
- Candidate data exposure stays scoped to the work.
- Procurement and policy reviews have direct evidence on access posture.
- DPDP and GDPR alignment is supported by default.
- Workspace governance scales with the team.
Frequently asked questions
- What is a role-based hiring workflow?
- A workflow where recruiters, hiring managers, and administrators see only the candidate data their role requires. Access is scoped to the work, not to the workspace.
- Why does role-based access matter in hiring?
- Candidate data is sensitive. Scoped access removes incidental exposure, supports policy and procurement expectations, and aligns with DPDP and GDPR-aligned governance.
- What does each role see?
- Recruiters see the roles they own. Hiring managers see the requisitions they sponsor and the shortlists prepared for them. Administrators see workspace-level configuration and access history.
- How does tenant isolation interact with role-based access?
- Tenant isolation is the workspace boundary; role-based access is the per-role scoping inside that boundary. Together they keep candidate data scoped to the people who need it and inside the customer's workspace.
- Are access events recorded?
- Yes. Access at the role and workspace level is part of the workflow record, alongside criteria, ranking, and shortlist decisions.
- Can access roles be customised per workspace?
- Yes. Role definitions are workspace-scoped so customers can match their internal hiring model without affecting the underlying governance properties.
Related workflows
- Hiring governance — The governance frame role-based access sits inside.
- Audit-ready hiring — How access events become part of the audit record.
- Compliant hiring workflows — How role-based access supports compliance posture.
- Recruitment audit trail — Where access events are recorded alongside evaluation history.