---
title: "The permission system"
url: "https://docs.4hse.com/users-and-permissions"
description: "How access control works in 4HSE: groups, entities, and the two ways a user obtains permissions."
---

# The permission system

Security is a priority in 4HSE, and access control is built to be precise: each user reaches only the information and the functions that concern them.

The system is designed for real situations, which are rarely simple. A **project user** can see every office, supplier and person linked to that project without anyone assigning permissions one by one. If the same user is later added to the office group **Health surveillance manager**, they gain write access in that functional area of that office — without losing or duplicating anything else.

## Groups, not individual permissions

[Section titled “Groups, not individual permissions”](#groups-not-individual-permissions)

You never assign a permission. You assign a user to a **group**, and the group carries a predefined set of permissions. This is the whole model, and it is why permissions in 4HSE stay manageable as the organisation grows.

Permissions are managed in the **Administration** section, under **[Permissions](/users-and-permissions/set-permissions)**, which has two sub-menus:

-   **Groups** — the predefined roles of that entity. Selecting one shows the users it contains, and you add or remove them by email address.
-   **Users** — everyone who has access to that entity through a direct assignment.

![The permissions section of a project](/_astro/permission-system-1.C9g0vnes_2lloTo.webp)

![The users section of a project](/_astro/permission-system-2.CoCCIrMb_Z2j70hS.webp)

## The entities that carry permissions

[Section titled “The entities that carry permissions”](#the-entities-that-carry-permissions)

Permissions are not global: they are set on an entity, and they follow the relations of that entity.

Entity

What it governs

Reference

**Project**

the main level; what is set here cascades down

[Project groups](/users-and-permissions/groups/project)

**Office**

a workplace, with permissions per functional area

[Office groups](/users-and-permissions/groups/office)

**Person**

access to an individual’s data

[Person groups](/users-and-permissions/groups/person)

**Supplier**

access for and to external suppliers

[Supplier groups](/users-and-permissions/groups/supplier)

**Multi-company panel**

users working across several projects

[Multi-company groups](/users-and-permissions/groups/multi-company)

## Two ways to obtain access

[Section titled “Two ways to obtain access”](#two-ways-to-obtain-access)

A user reaches an entity in two ways: by **direct assignment** to one of its groups, or **indirectly**, because they are assigned to a related entity. The distinction explains why a user can operate on a project without appearing in its user list — see [Direct and indirect access](/users-and-permissions/direct-and-indirect-access) and [Permission inheritance](/users-and-permissions/permission-inheritance).

This site is protected by reCAPTCHA and the Google [Privacy Policy](https://policies.google.com/privacy) and [Terms of Service](https://policies.google.com/terms) apply.