Key Concepts: Role-based Access
ChartHop’s Role-based Access Controls enable you to define who (the user) can do what (the action) for which part of the platform (the entity).
- For example, you might say that the CEO (the user) is allowed to read (the action) the data for all employees (the entity) in the system.
- Or you might say the Head of Recruiting (the user) is allowed to create (the action) new hires (the entity) in the system.
To do this, users are assigned a specific role, and those roles contain an explicit set of permissions, which define what that role has access to see and do.
Permissions enable you to either Allow or Deny access to a specific entity, data point, page, or process inside Charthop. You can read more about Permissions in Defining a custom permission.
Roles are a collection of Permissions that dictate what a user can and can not see or do inside Charthop. You can read more about Roles in Defining a custom role.
💡An analogy to help you visualize
You can think of Permissions as keys that unlock areas of the ChartHop platform. You can think of a Role as the keychain that holds the keys. A Role (keychain) holds many Permissions (keys) that grant or deny access to parts of ChartHop.
If a role contains two conflicting permissions, the DENY permission will always win.
For a very simple example, consider a role with the following two permissions:
A user with this role would not have access to see any Person data, because the DENY permission “beats” the ALLOW permission.
Let’s consider a more nuanced example, such as a role with the following two permissions:
In this example, the ALLOW gives the user access to see – read – all fields on job. But the DENY means that this user is not allowed to see – read – the field baseComp on jobs. Even though the ALLOW permission technically gives the user access to read all job fields, the DENY in this case wins, so this user can see all job fields except base compensation.
