--- title: "Permission inheritance" url: "https://docs.4hse.com/users-and-permissions/permission-inheritance" description: "How a role on a project or an office propagates to the entities linked to it, and why it saves you from configuring each one." --- # Permission inheritance Permissions set on an entity are not isolated: they cascade to what is linked to it. Once a user’s role on a project is defined, there is no need to configure each office, supplier or person separately. ## From the project down [Section titled “From the project down”](#from-the-project-down) Project role Office role Person role Supplier role **Admin** Manager Manager Admin **Manager** Manager Manager Admin **User** User User User **NA** NA NA NA ## From the office down [Section titled “From the office down”](#from-the-office-down) Office role Action role Person role **Manager** Manager Manager **User** User User **Guest** User User **NA** NA NA And from a functional area of an office: Action role Person role **Manager** Manager **User** User **NA** NA ## Combining levels [Section titled “Combining levels”](#combining-levels) Permissions from different levels add up: a user can hold one role on the project and a different role on a single office. A user with the **User** role on the project sees everything but changes nothing. Adding them to the **Training manager** group of one office gives them write access in the training area of that office alone: they see all company data and write only in their own area. ## From the office–supplier association [Section titled “From the office–supplier association”](#from-the-officesupplier-association) Office role Role on the supplier **Office manager** Supplier admin **Office guest** Supplier user And in the opposite direction: Supplier role Role on the office **Supplier user** Office guest **Supplier user** Office procedures user 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.