Permission Definitions

Permissions are the smallest unit of access control in RadixHR. Each one represents a single capability — for example, “view team leave” or “approve all payroll” — and they’re combined into Roles, which are then assigned to employees.

This page lists every permission that exists in your workspace, lets you filter by module, and lets you create or edit custom permissions when the built-in ones don’t cover a specific need.

What you can do here:

• Browse the full catalogue of permissions, with the count of roles using each one
• Filter by module (Employees, Leave, Attendance, Payroll, etc.)
• Search by name, code, description, module, or action
• Create custom permissions for specialised access needs
• Edit a permission’s display name, description, and category
• Delete a custom permission (only when no roles use it)

Understanding the Permission Code

Every permission has a machine-readable code that follows a strict three-part pattern:

module:action:scope

For example, leave:approve:team reads as “approve leave requests for team members”. This pattern lets you predict what a permission does just from its code, and it makes audit logs and API responses self-explanatory.

Actions — what each one means

Actions describe the kind of operation the permission allows. RadixHR uses a consistent set of actions across modules:

Scopes — who the permission applies to

Scopes determine which records a user can act on. The same action can exist with different scopes (e.g., leave:view:team vs. leave:view:all), letting you grant the same capability at different levels of reach.

Scope hierarchy

Scopes broaden in this order — each one typically includes the narrower scopes that came before:

own → subordinates → team → department → all

So a user with employees:view:department can also see their team members and their own profile (because both are subsets of “department”). This is why you usually only need to grant the widest scope a user requires, not every narrower scope below it.

The Permissions List

The main page is a table of every permission in your workspace, with these columns:

A footer below the table shows a live count: “Showing N of M permissions”.

Filtering by Module

Above the table is a horizontal row of module tabs. Each tab shows the module name and the count of permissions in that module. Click a tab to filter the table to just that module’s permissions; click All to see everything. Use the ‹ › arrows on either side of the tab strip to scroll if your workspace has many modules.

The search box (top-left) lets you free-text search across name, code, description, module, and action — combine it with a module filter for fast lookups (e.g., select Leave, then type “approve” to see only the four “Approve … Leave” permissions).

The 11 modules

Default Permission Catalogue

These are the permissions that ship with every RadixHR workspace. Counts on the right show how many you’ll see on each module tab.

Employees (13)

Leave (20)

Attendance (9)

Payroll (7)

Documents (8)

Reports (5)

Approvals (4)

Visibility into the global approvals queue, scoped by who the requester is.

ATS — Hiring (7)

Applicant Tracking System: jobs, candidates, interviews.

Settings (4)

Feed (2)

Workspace (3)

How to Create a Custom Permission

Most workspaces don’t need custom permissions — the default catalogue covers nearly every typical access pattern. Create a custom permission only when none of the existing ones fit a real, recurring need.

1. Go to Settings > Security > Permission Definitions
2. Click + Create Permission (top-right)
3. Fill in the form
4. Click Create Permission

The new permission appears in the list immediately and can then be added to any custom role through Settings > Security > Roles & Permissions > ⋯ > Edit Permissions.

Create Permission Fields

How to Edit a Permission

You can update a permission’s display name, description, and category at any time. The Code, Module, Action, and Scope are read-only after creation because they form the permission’s identity in role assignments.

1. Find the permission in the list (use the search box or module tabs)
2. Click the ⋯ menu at the right of the row
3. Select Edit Permission
4. Update the editable fields
5. Click Save

The row’s ⋯ menu offers:

How to Delete a Custom Permission

To delete a permission, no role may currently include it. If any role does, the Delete Permission option is disabled and shows (in use).

1. First remove the permission from every role that uses it: go to Settings > Security > Roles & Permissions, open each role’s Edit Permissions dialog, untick the permission, and save. Use the Roles count column on the permissions list to see exactly how many roles you need to update.
2. Once the count drops to 0, return to Permission Definitions.
3. Click ⋯ > Delete Permission and confirm.

How Permissions Combine into Roles

This page is just the catalogue. To grant access, you assign permissions to roles, then assign roles to employees:

1. Pick or create a role in Roles & Permissions
2. Open the role’s Edit Permissions dialog
3. Tick the permissions the role should have
4. Save, then assign the role to the relevant employees

A typical mapping:

Best Practices

1. Default first. RadixHR ships with ~80 well-designed permissions covering the typical needs. Browse them before creating custom ones.

2. Use the search box. With dozens of permissions per workspace, scrolling is slow — type a few characters of the action or module to jump straight to the one you want.

3. Mind the scopes. Granting :all is rarely correct. If a manager only needs visibility over their team, give them :team and let them grow into wider scopes if their role expands.

4. Audit the Roles count. Permissions used by many roles are critical — be especially cautious editing or deactivating them, since changes ripple to every role that includes them.

5. Keep custom permissions documented. Always fill in Description and Category for custom permissions. Future admins (and future-you) will thank you.

6. Use manage actions sparingly. They’re powerful but coarse — :manage:all typically grants every CRUD operation in a module. Prefer narrower verb+scope combinations when you can.

Troubleshooting Access Issues

If a user is missing access they expect:

1. Open Settings > Security > Users, find the user, and list their roles.
2. For each of those roles, open Edit/View Permissions and confirm the relevant permission is ticked at a wide enough scope.
3. Permissions are additive — the user only lacks a permission if none of their roles grants it.
4. If the permission exists in a role but the user still can’t perform the action, check whether a delegation rule is rerouting their requests to a different approver.

Related Pages