Assign specific HR access

Scoped HR access lets you give an HR team member permissions that only apply to a specific part of your organization, such as one entity, one department, or a combination of the two. It's built for multi-entity organizations that want to delegate day-to-day HR work to local admins without giving them visibility into every employee on the account. Scoped access sits on top of your existing preset HR roles (Admin, Standard, and Restricted) rather than replacing them, so you keep a single, consistent permission model while narrowing where each admin can act.

Setting up a scoped HR access rule

Scoped HR access is configured from the Account Members page. Each member with a Standard or Restricted preset HR role can have one scoped access rule assigned to them. Members with the Admin preset are always full admins and can't be scoped.

A scoped access rule has two parts:

• Scope: at least one entity, location, or site (any level of your hierarchy) or "Any entity", combined with at least one department or "Any department"
• Access: what the member can do within that scope, defined either by a preset role (Admin or Standard) or by one or more HR-only custom permission sets

To add a scoped access rule to a member:

1. Go to Account Members and open the member you want to configure.
2. Under their HR access, define the scope by selecting one or more entities, locations, or sites, and one or more departments (or leave either as "Any").
3. Choose the access the member should have within that scope: a preset role, or one or more HR-only permission sets.
4. Save your changes. An access preview summarizes the member's effective permissions, including anything granted by the scoped rule.

A few rules apply when choosing the access side of the rule:

• A member with the Standard preset role can only select Admin as their scoped role
• A member with the Restricted preset role can select Admin or Standard as their scoped role
• Only permission sets made up entirely of HR permissions can be selected in a scoped rule; permission sets that also include Company or Recruiting permissions can't be scoped, and you'll be notified that those permissions can't be applied this way

Workable calculates a member's effective HR access as the union of their preset HR role and their scoped rule, applied within the defined scope:

• For employees within scope: the member has the permissions of their preset HR role plus anything additional granted by the scoped rule
• For employees outside scope: the member retains only the permissions of their preset HR role

How scoping works for settings

HRIS settings — entities, profile templates, document templates, onboarding workflows, work schedules, time tracking policies, time-off policies, and holiday calendars — are evaluated against a scoped admin's access using entity and department dimensions. If a dimension is left unset on a resource (for example, a policy with no department restriction), it's treated as "Any" and matches every value on that dimension.

• Fully within scope: the resource's entity and department values are fully contained by the admin's scope. The admin can view, create, edit, and delete it.
• Partially within scope: the resource and the admin's scope overlap, but the resource extends beyond the scope on at least one dimension. The admin can view it but can't create, edit, or delete it.
• Out of scope: there's no overlap between the resource and the admin's scope. The resource isn't visible to the admin.

A few behaviors apply consistently across scoped settings:

• When creating a resource, the entity and/or department fields are required and limited to values within the admin's scope. If the scope contains a single value for a dimension, that field is pre-filled and locked.
• When editing a resource, its entity or department assignment can't be changed to a value outside the admin's scope.

The table below shows which dimensions each setting type uses, and any exceptions to the general logic above:

How scoping works for employees

Employee scoping works differently from settings scoping, because an employee can only have one value (or no value) for each dimension. This makes employee scoping binary — an employee is either in scope or out of scope, with no partial state:

• In scope: the employee's entity and department both match or fall within the admin's scope. Every permission or action granted by the scoped rule is available for this employee.
• Out of scope: the admin retains only the permissions of their preset HR role for this employee. No scoped permissions or actions apply.

Empty fields on an employee's profile are handled as follows:

• An employee with no entity set is out of scope for any entity-scoped admin, but is considered in scope on the entity dimension for an admin whose scope includes "Any entity"
• An employee with no department set is out of scope for any department-scoped admin, but is considered in scope on the department dimension for an admin whose scope includes "Any department"

This in/out model applies consistently across the people directory, employee profiles, org chart, profile history, employee actions, notifications, approvals, and report filtering.

People directory

Scoped admins see employees across the organization according to their preset HR role — Standard sees all active profiles, and Restricted follows its own visibility rules. A scoped rule doesn't hide employees from the people directory; it elevates what the admin can do with the employees who fall within their scope.

Employee profiles

For employees within scope, the admin has the view and edit permissions defined by their scoped rule. For employees outside scope, they retain only the permissions of their preset HR role.

Org chart

Scoped admins can see active profiles, draft profiles on an active branch, and profiles with a custom status for employees within their scope in the org chart. Profiles outside scope follow the visibility rules of the admin's preset HR role.

Creating and editing employees

Scoped access applies to the following employee operations. Entity and department fields are required and pre-filled when the admin's scope contains exactly one value for that dimension; otherwise the admin selects a value from within their scope.

• Manual employee creation: entity and department fields are pre-filled or locked according to scope
• Manual employee editing: field values outside the admin's scope can't be set
• Bulk import: the employee CSV picker is limited to in-scope employees, and entity/department selections are limited to the admin's scope — see importing employees from CSV
• Bulk update: available only for in-scope employees, with entity/department options limited to scope
• Bulk update and unassign time-off balances: limited to in-scope employees

How scoping applies across other HR areas

Time off

Scoped admins can view and manage time off for employees within their scope. Time-off information for out-of-scope employees isn't accessible, even if those employees appear in the directory.

• Who's out: both the absence and holiday tabs show only employees within the admin's scope
• Assigning time-off policies: scoped admins can assign time-off policies to employees within their scope, and the policies available in the picker are limited to the admin's entity scope, since time-off policies only carry entity segmentation

Time tracking

Scoped admins can view and manage time tracking entries for employees within their scope. Time tracking information for out-of-scope employees isn't accessible. When assigning a time tracking policy, the available policies are limited to the admin's scope.

Company files

A scoped admin can see any folder in company files whose access configuration fully or partially overlaps with their scope, along with all files inside it. Folders that fall entirely outside the admin's scope are hidden.

• When creating a folder, the "All employees" access option isn't available to a scoped admin — only "Custom" can be selected, and the entity/department and individual employee selectors are limited to their scope
• A scoped admin can edit or archive folders that are fully within their scope, and upload or move files into any fully in-scope folder
• Editing or archiving a file is only possible when the file's parent folder is fully within the admin's scope

Work calendar

Visibility and editability of work schedule cells still follow the employee field permissions configured on the member — either "View/edit all employee fields" or field-level permissions set in the profile template. For a scoped admin, editable employees include those within their scope, plus any employees available through a reporting line or self-access if configured in the profile template.

• Scoped admins with a Standard preset role can see approved time-off entries for all employees
• Scoped admins with a Restricted preset role can only see approved entries for employees within their scope
• Pending time-off requests appear for any employee where the admin is the designated approver
• The "Time off only" toggle shows the union of employees with approved time off and employees with pending requests where the admin is the approver

Employee onboarding

Scoped admins can initiate and manage onboarding only for employees within their scope. This affects both the onboarding initiation flow and the onboarding dashboard.

When a scoped admin starts onboarding for an employee, the available options are filtered to their scope:

• Entity, location, or site is required if the admin is scoped to specific entities, and pre-filled if exactly one entity is in scope
• Only employee profile templates within the admin's scope are available for selection
• Only onboarding workflows within the admin's scope are available for selection

The onboarding dashboard shows only the records for employees within the admin's scope, and all onboarding management actions — completing tasks, managing steps, and so on — are limited to in-scope employees.

Performance reviews and surveys

Performance review cycles

A scoped admin can see a review cycle if it contains at least one employee within their scope, and can access and manage the participants who fall within that scope. Participants outside scope aren't visible or actionable.

• When creating a review cycle, "All employees" isn't available as a target — only "Individual employees" and "Custom" (entity/department-based) can be selected, and both are limited to the admin's scope
• A scoped admin can start, edit, duplicate, archive, or delete a review cycle only when every employee in the cycle is within their scope; if a cycle contains any out-of-scope employee, it stays visible but can't be modified

Surveys

The same visibility logic applies to surveys: a scoped admin sees a survey if it includes at least one in-scope employee, and for surveys with a mix of participants, only the in-scope employees are shown. Full results are available only for surveys where every participant is within scope; for mixed surveys, results are limited to in-scope employees, and anonymous survey rules still apply.

Onboarding workflow surveys can only be created by a Super Admin — a scoped admin can't create or manage one, and the option is disabled with an explanatory message. Scoped admins with onboarding permissions can still add an existing workflow survey to an onboarding workflow, and can see workflow surveys in the Survey Hub for their in-scope employees.

Approvals and notifications

Profile updates approval

Scoped admins are notified about, and can view and approve, profile field change requests only for employees within their scope.

HR admin as a group

Several features route tasks, notifications, or approval requests to "HR admin" as a group. With scoped access, this resolution now takes into account whether the relevant employee falls within each scoped admin's scope. Global HR admins with no scope restriction are always included, regardless of which employee is involved.

• Onboarding custom task assignees: a task assigned to the "HR admin" group goes to all global HR admins plus any scoped admins who have that onboarding employee within their scope
• Onboarding send email tasks: an email step targeting the "HR admin" group is sent to all global HR admins plus any scoped admins who have that employee within their scope
• Time-off approver: when a time-off policy uses "HR admin" as the approver, requests route to the appropriate admins based on scope. The "approve on behalf" action is also scoped — a scoped admin can approve on behalf of another approver only for employees within their own scope.

Notifications

• Draft employee profile created: sent to all global HR admins and to scoped admins for whom the draft employee falls within scope. Entity information isn't available yet at this point (the trigger is the hire event in the ATS, before the employee's entity is set), so admins with an entity-only restriction are excluded from this notification — only department scope is evaluated.
• Onboarding completed: sent to all global HR admins and to scoped admins who have that employee within their scope
• Auto publish outcome: when Workable attempts to automatically publish a draft profile on the employee's start date, the success or failure notification goes to all global HR admins and to scoped admins who have the employee within their scope

Reports

All standard HR reports are automatically filtered to show only employees and data within the scoped admin's scope.

• Employee details: shows all employees the admin has access to based on their preset HR role. For in-scope employees, the admin sees the full set of profile fields their HR permissions allow; for out-of-scope employees, only the fields available through their preset role are visible.
• Profile updates: shows only profile change records for in-scope employees. For a Restricted member with a Standard scope rule, only self profile updates appear, since viewing other employees' updates requires the view field history permission.
• Attendance, time-off balances, and time-off requests: show data for employees within the admin's scope, including any direct reports
• Payroll: shows payroll data for employees within the admin's scope

Restricted members with a Standard scope rule

A member with the Restricted preset HR role can be assigned a scoped rule that grants Standard-level permissions. Within their scope, they gain those additional Standard permissions; outside their scope, they keep the full Restricted experience.

• With View company people directory in their scope rule, the member sees in-scope employees in the directory, plus their own profile
• With View company organizational chart in their scope rule, the member can access the org chart, and only in-scope employees appear
• With View company files and folders in their scope rule, the Files nav item becomes visible, and access to specific folders continues to follow existing account-level folder permissions
• With View HR reports (standard access) in their scope rule, the member can access the Employee details and Profile updates reports, filtered to their scope

Each nav item (Employees, Files, Reports, and so on) is only visible when the corresponding permission is included in the scope rule; otherwise it's hidden.

FAQs

How many scoped access rules can a member have?

Just one. Each member with a Standard or Restricted preset HR role can have at most one scoped access rule, combining an entity/department scope with either a preset role or one or more HR-only permission sets.

Can I scope an Admin member's HR access?

No. Only members with the Standard or Restricted preset HR role can have a scoped access rule. Admin is always a full admin across the entire account.

Why can't I select a permission set when setting up a scope rule?

Only permission sets made up entirely of HR permissions can be used in a scoped rule. If a permission set also includes Company or Recruiting permissions, it can't be scoped, and you'll see a message explaining that those permissions can't be applied within a scope.

What happens to an employee with no entity or department set?

An employee with no entity value is out of scope for any entity-scoped admin, but in scope on that dimension for an admin scoped to "Any entity." The same logic applies to department: an employee with no department value is out of scope for department-scoped admins, but in scope for admins scoped to "Any department."

Does scoped HR access affect Recruiting permissions?

No. Scoped HR access only applies to HR permissions. Any additional permission sets that include Company or Recruiting permissions continue to apply account-wide and aren't affected by HR scoping.

What happens if my plan is downgraded?

If an account downgrades to a plan that doesn't include scoped HR access, existing scope rules remain active and enforced but become read-only — admins can delete a scope rule but can't edit it or add a new one.