---
title: "Project Permissions"
url: "https://docs.4hse.com/guides/permissions/project-permissions"
description: "Guide to managing permissions at the project level in 4HSE and their impact on related entities."
---

# Project Permissions

## The Core of Management: Project Permissions

[Section titled “The Core of Management: Project Permissions”](#the-core-of-management-project-permissions)

In 4HSE, the **project** is the heart of your company’s safety management. This is where overall user access is defined, ensuring that everyone has the right responsibilities and visibility. Managing permissions at this level is essential for maintaining order and security across the system.

* * *

## Permission Groups for the Project

[Section titled “Permission Groups for the Project”](#permission-groups-for-the-project)

To simplify management, 4HSE provides four predefined permission groups for each project:

-   **Admin**: Full control, for those who need to manage every aspect of the project.
-   **Manager**: For supervisors who need to actively operate but without the ability to manage advanced permissions and configurations.
-   **User**: For users who need to view data without modifying it.
-   **NA (No Access)**: For users who require extremely limited or no access to the project.

Assigning a user to one of these groups impacts not only the project itself but also their permissions on related entities like offices and suppliers, thanks to an inheritance system that saves time and effort.

## Permission Overview by Role

[Section titled “Permission Overview by Role”](#permission-overview-by-role)

The following table provides a clear overview of what each group can do at the project level.

Group

Project Permissions

**Admin**

Full project management  
Read and write permissions  
Role assignment  
Access to configuration and contract menus

**Manager**

Partial project management  
Read and write permissions  
Cannot view the Permissions, User Logs, Contract, and Configuration sections

**User**

Read-only permissions

**NA**

Very limited access, without the ability to manage or view data

## Inheritance: A Cascade of Permissions

[Section titled “Inheritance: A Cascade of Permissions”](#inheritance-a-cascade-of-permissions)

Permissions set at the project level are not isolated—they cascade to related entities. Once a user’s role on a project is defined, there is no need to configure each individual office or supplier.

The following table summarizes how project roles automatically propagate to other entities.

Project Role

Office Role

Person Role

Supplier Role

**Admin**

Manager

Manager

Admin

**Manager**

Manager

Manager

Admin

**User**

User

User

User

**NA**

NA

NA

NA

## How to Set Project Permissions

[Section titled “How to Set Project Permissions”](#how-to-set-project-permissions)

Assigning permissions at the project level is done via the **Permissions** menu.

1.  Open the **Project** detail page;
    
2.  Select **Administration** from the menu, then the **Permissions** submenu;
    
3.  The section has two tabs: **Groups** and **Users**;
    
4.  Selecting **Groups** shows the predefined roles for the project (**Admin**, **Manager**, **User**, **NA**);
    
5.  In the **Details → Users** section, you can see the users in each group;
    
6.  To add a user, select **New** and enter their email address;
    
    ![Project Permissions Section](/_astro/project-permissions-1.DJSXWXTI_1xtfXv.webp)
    
7.  Selecting **Users** shows an overview of all users who have direct access to the project.
    

![Project Users Section](/_astro/project-permissions-2.CZsjdNyl_Z1r4UMT.webp)

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.