Skip to main content
Harly uses workspace-scoped RBAC. A role combines permissions with an optional job scope. Role permissions are enforced on the server; hiding a navigation item does not grant or revoke access by itself.
Harly settings showing workspace roles, members, and permission levels.

Workspace roles and permission scopes for least-privilege access.

​
Built-in roles

​
Create a custom role

Only members with the roles:manage permission can create or edit roles. The role editor is in Settings → Members & roles → Roles → New role. The /settings/roles path redirects to this page.
1

Name the role

Enter a name between 2 and 40 characters, such as Sourcer. Harly creates a slug-like role key from the name. A role key that collides with a built-in key (owner, admin, recruiter, or hiring_manager) is rejected.
2

Set the access scope

Choose All matching jobs or Assigned jobs only. You can also enter comma-separated department and region values, for example:
Empty department and region fields mean no filter for that dimension.
3

Select permissions

Select permissions from the Jobs, Candidates, Privacy, Collaboration, Documents, Analytics, and Administration groups. Save the role when the permission set and scope are complete.
Harly applies a privilege ceiling: you cannot grant a role a permission you do not hold, or give it a broader job scope than your own. This prevents a scoped administrator from creating an escalation path.

​
Assign a role

Open Settings → Members & roles → Members. Select a role in a member’s Role dropdown, repeat any other changes, and choose Save changes. New invitations and direct member creation also include a Role selector; the Owner role is never available for invitations. Deleting a custom role moves its members to Recruiter inside the same transaction. Built-in roles cannot be deleted. Editing a built-in role stores a workspace-specific override; its display name stays fixed, and the Owner role remains locked.
Review role creation, updates, and deletion in the audit log after every organizational change. Deleting a custom role reassigns its members to Recruiter.

​
Permissions

Permissions follow the pattern resource:action. The available permissions are:

​
Who can export sensitive records

Exporting the consent report and the audit log requires dsar:manage, not settings:edit or a role name. Owners and admins hold dsar:manage by default. Recruiters also hold it by default, so they can review candidate requests and export these records. To keep exports away from a custom role, remove dsar:manage from it in Settings → Members & roles → Roles. To let a custom role export, add Review privacy requests to it there. A custom role keeps exactly the permissions stored on it, so one that could not export before still cannot until you grant dsar:manage. A role limited to certain jobs only exports consent records for candidates inside those jobs. The audit log is workspace-wide and is not filtered by job scope.

​
Job scopes

Layer scopes on top of a role’s permissions to restrict job-scoped resources:
  • All matching jobs: access every job that matches the department and region filters.
  • Assigned jobs only: access only jobs where the member is on the hiring team.
  • Departments: allow only matching job departments.
  • Regions: allow only matching job regions.
Use Assigned jobs only for recruiters who should work only on their requisitions. Add department or region constraints for geographic or functional divisions. A job with no department or region does not match a non-empty filter.

​
MFA and session controls

Owners can enforce MFA from Settings → Security. When MFA is enforced, members without a configured factor are blocked from the workspace until they enroll. Additional controls available in Settings → Security include passkeys, trusted email domains, IP allowlists, suspicious-session detection, and reauthentication windows for sensitive changes.
Self-hosted deployments behind an external reverse proxy must set TRUSTED_PROXY_IPS for IP allowlists (and per-IP rate limits) to evaluate the original client address instead of the proxy’s address. See proxy modes.

​
Audit review

Review security and administrative events periodically and after any incident. Export the audit log before deleting or anonymizing records that may be needed for an active investigation.
A candidate’s deletion request is not a security incident. Handle it through the privacy workflow, not the audit log.