Roles and Permissions: Who Can See What

Access runs along a single line. A user holds a role, the role carries permissions, and a permission is a module combined with an action. A user cannot be given a second role, because the role field on the user record is single valued. In practice that means widening someone access is not adding another role, it is changing their role or editing the permission list of the role they hold.

Roles belong to a company and a role name is unique inside it; two companies can use the same name, while the same company cannot hold two roles called Recruiter. The permission catalogue is shared: which action exists in which module is fixed in the product, companies pick from that list rather than extending it.

The action vocabulary is fixed as well, and its labels live in one central place. You see the same word on the role screen, in the audit trail and in an error message; no component keeps a second label table of its own.

• Actions: View, Create, Update, Delete, Update status, Update note, Export, Assign role, Manage permissions, Send, Bulk send, Manage
• Module headings follow the sections of the product: Job Applications, Internship Applications, Positions, Employees, Document Requests, Email Templates, User Management, Role Management, Activity Logs, Trash and others
• Different actions in the same module are granted one by one: someone who can see an application may not be able to change its status, someone who can add a note may not be able to delete
• Export is a permission of its own; being able to see a list does not mean being able to download it
• SuperAdmin short circuits the permission check and is never treated as masked

A new company arrives with four roles ready, and all four are marked as system roles. Being a system role means two things: it is closed to editing on the role screen, where the form warns that system roles cannot be changed and every checkbox and the save button go inactive; and it can be neither duplicated nor deleted.

Seeing personal data unmasked is missing from all four roles. That is a separate permission and, among the roles that ship with the setup, only CompanyAdmin carries it. On the other three, candidate names drop to initials and email addresses and phone numbers are shortened.

If you want your own permission layout you create a new role; that endpoint is open from the Professional plan onwards, as the last section explains.

The role editor opens with the role list on the left and the form of the selected role on the right. Permissions are not a flat list, they are grouped under module headings. Clicking a heading opens the group, the checkbox on the heading selects every action in that module at once, and it shows an indeterminate state when only some are selected. The count of selected permissions sits above, next to Select all and Clear all.

The screen itself is behind permissions too. Seeing roles, creating a role and deleting a role are separate permissions. One detail matters: changing the name and description of a role is not the same permission as changing its permission list. The two are checked separately inside a single request, so you can let someone fix a role name without opening the distribution of access to them.

Deleting a role has two limits. System roles cannot be deleted. A role with users on it cannot be deleted either; the error states how many users hold the role and asks you to move them first. Duplicating a role you created opens the new one with a copy suffix and without the system role flag.

One gap remains today: a heading in the permission list has no entry in the label dictionary, so it appears under its raw code, pii. The permission underneath it reads as viewing PII, and that checkbox is what grants seeing personal data unmasked.

• A role name takes up to 50 characters and a description up to 500 characters
• Two roles in the same company cannot share a name; on a clash the request says the name is already in use
• System roles cannot be duplicated or deleted and stay closed to editing on the form
• Roles are assigned from the user management screen; people join the team either through an account you create or through an invitation
• Nobody can delete or deactivate their own account, and the SuperAdmin account can never be deleted

Permissions do more than hide buttons, they close the screen. A user does not see a section they lack access to anywhere in the menu, and cannot reach it by typing the address. The order of the checks is fixed: first the company feature setting, then the development environment gate, then the SuperAdmin bypass, and the tab permission last. The practical consequence: a module that has been switched off is closed for SuperAdmin too, because the setting gate runs before the bypass. On sign in, the user lands on the first screen they can reach.

On the personal data side there is a second layer. A user without the unmasked permission receives data that is already masked from the server; the blur on screen sits on top of that and is never the only defence. The same user cannot delete a candidate, because the delete button is not drawn at all while masking is on, and cannot open the candidate file, because file access is closed in the service layer. Export is a separate permission, and when a masked user exports, the output is produced masked as well.

The full account of masking is not repeated on this page. For how it looks on the application screen see the applicant tracking page, and for the legal setup see the KVKK in recruitment guide.

AI does not change any of this. No application status ever changes by itself; the system produces suggestions and your team decides. The permission system only limits who is allowed to make that decision, because changing a status is a permission of its own.

This is where people are caught out most often. Permissions travel in the session token, and the old copy stays valid until the token is refreshed. When you change the permissions of a role, a user on that role may not see the change immediately; signing out and back in is the reliable path. A session lives for 24 hours. The session validator checks that the account is active and that the password version matches, it does not refresh permissions.

The change itself is never lost. The product keeps two separate ledgers: one is the stream of who did what and when, the other holds the old and the new value field by field per record. Creating, updating and deleting a role is written under the Role Management module; on an update the diff of the changed fields is recorded too, and a changed permission list appears as one of those fields.

The audit trail is subject to masking as well. For a user without the unmasked permission, a changed sensitive field comes back with an empty old value and a hidden new value, and the name of the person who wrote the entry is masked. So who changed something and when stays readable, what it said does not.

Every request carries the company identity alongside the permission. The server takes that identity from the return of the permission gate rather than from the request body; update and delete queries match the record id together with the company id, so each company data stays closed to everyone else.

The only capability tied to your plan is creating a role from scratch, and it is open from the Professional plan onwards. On a plan that does not cover it, the attempt stops with a message saying custom role creation is not included and pointing to the Professional plan. Viewing roles, editing an existing role, deleting one, adding users, the KVKK mask and the audit trail work on every plan.

The number of users is limited by your seats. Creating a user and accepting an invitation that has been sent are both checked against the seat limit; when it is full, the operation stops with a seat error. The limit is not hard coded, it is read from the company subscription record.

People join the team two ways: you create the account, or you send an invitation. An invitation link stays valid for 7 days. The database stores a digest of the link rather than the raw key, and an expired invitation shows as expired without anyone having to act.