Skip to main content
Nederlands
Nederlands

Restrict access for groups: populations and hierarchy

What this feature does

Epowerhr lets you limit what members of a group can see by combining two independent restrictions:

  • Populations — rule-based filters that scope which persons' records the group can see (for example: "everyone in the Sales department" or "all employees in Region X").
  • Exclude hierarchy above — hides records of people who sit higher than the user in the organisational hierarchy.

You configure these restrictions per object type — for example, you can apply a population to Documents but not to Trainings, or hide Performance Reviews of upline managers without restricting any other object.

Before you start

You will need:

  • The permissions Administer general security and View groups to view the Access Control tab.
  • The additional permission Update group to make changes.
  • The populations you want to use must already exist (populations are managed elsewhere in the admin area). Populations are rule-based and evaluate dynamically as employee data changes — you do not need to refresh or rebuild them manually.

Key concepts

  • Group — a collection of users that grants permissions. Access-control settings sit on top of those permissions: they cannot grant new abilities, only narrow what each member sees.
  • Population — a person filter defined by rules (for example Job = "HR Officer" or Cost Centre IN ("CC100", "CC200")). One important structural detail: populations attach to the group as a whole, not to individual object settings. The per-object checkbox is only an on/off switch — it does not let you choose which populations apply to which object. This drives several practical patterns covered later.
  • Hierarchy above — the user's manager, their manager's manager, and so on.

Instructions

Step 1 — Open the Access Control tab

Navigate to Admin → Groups → [group] → Access Control.

Step 2 — Enable restrict access

The tab opens with a status banner. If it reads "Restrict access is currently disabled.", click Enable restrict access. The banner switches to "Restrict access is currently enabled." No settings below take effect until restrict access is enabled.

Step 3 — Add one or more populations (optional)

Once restrict access is enabled, a Populations table appears. Click Add populations, choose a population from the dialog, and confirm. Repeat for each population you want to add.

If you leave the populations list empty, the per-object Population active checkbox has no filter to apply — members of the group will see records of everyone for that object. The system makes this explicit: the empty-state message reads "No populations are defined. The settings below apply to everyone."

Step 4 — Configure per-object restrictions

The settings section lists every object type that supports access control, grouped by component (PA, Documents, Training, Talent, …). For each object you can toggle two checkboxes:

  • Population active — "When enabled, '[object]' records shown to members of this group are limited to those of [scope]." The scope is the populations you added in step 3, or "everyone" when no populations are present.
  • Exclude hierarchy above — "When enabled, '[object]' records of people higher in the hierarchy are hidden from members of this group."

The two checkboxes stack: enabling both means "records of people in the population AND not above me in the hierarchy".

Click Save to persist your settings. A confirmation toast appears.

Step 5 — Verify

Log in as a user that belongs to the group and check that the records you expect to be visible (or hidden) match what you configured.

Worked examples

Example A — single restriction across one object type

"Regional HR officers should see absences for employees in their region, but not for employees who are higher in the hierarchy than themselves."

  1. Open the Regional HR — Region X group → Access Control tab.
  2. Click Enable restrict access.
  3. Add populations → pick the Region X employees population.
  4. In the settings table, find the Absence object. Tick Population active and Exclude hierarchy above.
  5. Click Save.

Members of this group will now see only absences for employees in Region X who sit at the same level or below them in the org chart.

Note: if the members of this group are also member of another group with restrict access enabled, this might impact the outcome.

Example B — different populations per object (requires multiple groups)

"For Training, members must see all employees of a given employee type. For Talent Reviews, they must not see anyone with an HR function."

Because populations attach to the group as a whole and not to individual object settings, a single group cannot mix population scopes across objects. Configure two groups and add the user to both.

Group A — Training scope

  1. Create a group called e.g. "Access — Training: EmployeeType X".
  2. Enable restrict access.
  3. Add the population EmployeeType X (a population whose rule selects employees of that type).
  4. In the settings: Population active ON for Training, OFF for Talent Reviews.
  5. Save.

Group B — Talent Reviews scope

  1. Create a group called e.g. "Access — Talent Reviews: non-HR".
  2. Enable restrict access.
  3. Add a population whose rule excludes HR functions (for example Job NOT IN (HR Officer, HR Business Partner, …)). The exclusion lives inside the population's rule definition — populations are themselves rule-based filters.
  4. In the settings: Population active ON for Talent Reviews, OFF for Training.
  5. Save.

Add the user to both groups. They will then see employees of EmployeeType X in Training, and all employees except those with an HR function in Talent Reviews. The two scopes do not bleed into each other because each group only contributes to objects where its Population active toggle is on.

Tip: name access groups by their scope ("Access — [object]: [population]") so the membership intent stays obvious to whoever maintains the group later.

How restrictions combine when a user belongs to several groups

This is the section customers ask about most. The rules below describe exactly how eSuite resolves restrictions across multiple groups.

 
  • Group-type scope. Any group on which restrict access is enabled participates in the evaluation, regardless of whether the group is additionally marked as a Security group or Queue group. The group-type flags do not gate access-control evaluation.
  • Only groups with restrict access enabled count. Groups where the Restrict access toggle is off are ignored entirely. They neither restrict nor "open up" access — they simply do not participate in the evaluation.
  • Membership is binary. A user is either a member of a group or they are not; there is no pending or queued membership state.
  • Most permissive setting wins, per object. When the user belongs to several restricted groups:
    • Populations are unioned. If group A restricts Documents to Region X and group B restricts Documents to Region Y, the user sees both Region X and Region Y documents.
    • An empty population list acts as a wildcard. If any restricted group has Population active enabled for an object but no populations attached at all, that group cancels the population restriction for that object: the user sees every employee's records for that object, regardless of what other groups say.
    • Hierarchy exclusion only takes effect when every restricted group agrees. If at least one restricted group with settings for an object has Exclude hierarchy above turned off for that object, the exclusion does not apply.
  • Permissions and access control are two independent layers. Permissions (like View documents) are aggregated across all the user's groups regardless of whether restrict access is on. The access-control filter is then applied on top — it can narrow the records the user sees, but it cannot grant a permission the user does not have.
  • The behaviour that surprises people. Adding a user to an additional unrestricted group does not broaden what they can see. Once any of their groups restricts an object, the restriction binds them. To grant a user broader access, you must adjust the restriction itself — not add them to a non-restricted group.

Removing a population or disabling restrict access

  • Removing a population. Click the delete icon next to the row in the Populations table. Confirm with "Are you sure you want to delete this population?". The population is removed from this group only; it still exists in the system and other groups using it are unaffected.
  • Disabling restrict access. Click Disable restrict access. A warning reads: "Disabling this group will remove all linked populations and settings from the group. Are you sure you want to do this?" The cascade is immediate — populations and per-object settings are removed from this group, although the populations themselves still exist for use by other groups. To re-enable later, you will need to re-add populations and re-tick the per-object checkboxes.

Frequently asked questions

Does adding a user to another group widen their access? Only if that other group is restricted with broader populations (which then union with the existing scope) or has Exclude hierarchy above turned off for an object where another group has it on. Adding a user to a non-restricted group does not widen access — see the multi-group section above.

Can I use this feature without populations? Yes. Exclude hierarchy above works on its own. Population active with no populations attached means "everyone".

Do I need to refresh populations after employee data changes? No. Populations are rule-based and evaluated dynamically. As soon as an employee's data matches (or stops matching) a rule, the population reflects that on the next request.

What if an object does not show one of the checkboxes? Not every object supports both settings. The UI only displays the checkboxes that are available for that object.

Who can change these settings? Users with the Administer general security and Update group permissions. View groups alone is enough to view the tab.