ATS User Roles and Permissions: Control Who Sees What

What does role-based access control mean in a hiring system?

It means access is granted to a role, and people are granted the role. You do not tick boxes for each individual. You define what a recruiter can reach, what an administrator can reach, and then anyone assigned to that role inherits it everywhere in the application. In Pitch N Hire this lives in Settings under user roles, with three tabs: the users themselves, roles and permissions, and panellists. The middle tab is where roles are created or edited and where you toggle the permissions each role grants. Opening that area is itself gated, since managing people is not something every account should be able to do. The design guidance the product gives is the right one to follow: assign the narrowest role that lets somebody do their job. Recruiters rarely need billing access or the ability to edit company settings. That single sentence prevents most of the sprawl.

Why does everybody end up as an administrator?

Because granting more access is always the fastest way to unblock somebody. A hiring manager cannot see a candidate, it is Friday, and making them an admin takes four seconds while working out the correct role takes twenty minutes. Nobody revisits it. Two years later, eleven people can edit company settings, four of them have changed teams, and one left in March. The consequences are not dramatic until they are. Compensation on offers, salary ranges on requisitions, interview feedback about people who are still employed elsewhere, and the contact details of everybody who ever applied are all sitting behind a role that was expedient once. Nobody did anything wrong at any single step. That is precisely why access needs a scheduled review rather than good intentions, and why the initial role design is worth the twenty minutes. Do it once, properly, on a quiet afternoon.

Which roles does a hiring team actually need?

Fewer than most teams create, and more than one. An owner exists for the account itself, including billing and company-level settings, and should be one or two people. An administrator manages users, roles and configuration without necessarily needing billing. A recruiter works roles end to end: candidates, pipelines, communication and offers for the jobs they own. A hiring manager needs their own requisitions and their own candidates, and usually nothing else. An approver, often in finance, needs to read a requisition and decide on it rather than edit anything. An interviewer needs one candidate at a time and no browsing rights at all. Build those, resist the urge to create a role per person, and remember that a role which exists for exactly one individual is usually a sign the permission model needs adjusting rather than extending. Map them onto how your applicant tracking system is genuinely used.

Which data deserves the tightest permissions?

Compensation first, always. Salary ranges on requisitions and total figures on offers are the fields most likely to cause internal damage if they circulate, and they are frequently the least protected because they arrived alongside operational data nobody thinks twice about. Interview feedback is second: candid notes about a person who is currently employed somewhere else, and who may reapply, belong to the hiring decision rather than to general readership. Candidate contact details are third, since they are personal data you hold on people who are not your employees. Then billing and company settings, which are simply not a recruiting function. Nobody in talent needs a payment method on file. Applicable data protection duties vary by jurisdiction and change over time, so confirm your obligations with your own legal or compliance advisor. Our handling of the underlying platform is described on security.

How do you give access to people outside the hiring team?

Scope it and time-limit it instead of issuing a full account. There are three patterns worth knowing. An interviewer who is not on your team becomes a panellist: they do not consume a normal team seat, hold no workspace role, and see only the interviews assigned to them, with the invitation link carrying a validity measured in hours. An approver on a requisition workflow is added per step with a name, an email and either read access, meaning view only, or write access, meaning they can edit. And somebody who just needs to supply information can be sent a secure request link, with whatever they change coming back as proposed changes for review rather than as a silent edit. Each pattern keeps a person useful without making them a permanent account nobody remembers to remove. Neither should outlive the reason it was created.

What breaks when access is never reviewed?

Leavers keep their accounts, which is the failure with the shortest path to real harm, because a departing recruiter's login reaches every candidate relationship your company owns. Role sprawl follows, where enough one-off roles accumulate that nobody can say what any of them grants without opening each one. Shared logins appear next, usually invented to avoid a licence, and they destroy the audit trail entirely, because every action is attributed to a role rather than a person. Then there is the quieter one: everyone can read everyone's interview feedback, so the third interviewer sees two positive scores before writing their own and the panel converges instead of assessing independently. The first three are security problems and the fourth is a hiring quality problem, and all four come from the same cause, which is that access was set once and never looked at again.

How do you review access without turning it into a project?

Attach it to things that already happen. Make removing system access a line item on your offboarding checklist so it happens the day somebody leaves, not the month after. Add a permission check to your internal transfer process, because a person moving from recruiting to operations keeps their old access by default. Then run one calendar review a quarter: export the user list, confirm every person still works here, confirm every role still matches the job they do now, and delete any role nobody is assigned to. That is a thirty-minute task if you do it four times a year and a genuine project if you do it once every three. Treat panellist and external reviewer lists the same way, since those accumulate quietly. The same discipline applies across your HR software generally. Access hygiene is boring and it is the cheapest security you own.

A starting role map for a hiring team