Navigating the facepile on a control
All objects in Hyperproof have a facepile that can be found in the upper-right-hand corner when clicked into an area or object. From here, you can control who has access to the object and what type of permissions they have. You'll use the Facepile any time you want to add a user to an object or adjust a user's permissions on a particular object.
In this video, we'll go over the user Facepile, where it is located, how to add users via the Facepile, and how to adjust permissions via the Facepile.
Note, the video tutorial below shows the facepile on a program. However, the concept for a control is the same. The difference is that you'll click on that specific control you want to add members to or review members on.
The tutorial below is from the perspective of the administrator role with object permission as a manager. If you are in a different Hyperproof role or have a different permission, you may not have access to some of the areas shown, or they may be grayed out.
Click the arrow below to learn more:
Navigating the facepile
Navigating the facepile
First, select the object you want to access the Facepile for. i.e. the control.
Click on the images of the members to open the member access dialog or click the + icon to add a user.
Designate the object level permission, or change the object level permission in the member access dialog.
Object roles and permissions
Compliance programs often contain sensitive information that must be restricted to specific teams or individuals. For example, a manager of a security program may not be allowed to view a privacy program.
Object roles and permissions define how users can interact with specific objects, such as compliance programs, controls, audits, and related data. Roles determine whether users can manage, contribute to, or view an object.
Object roles and permissions are assigned when a user is added to an object or when their role needs to be updated to reflect their responsibilities. These assignments should be reviewed and adjusted as necessary to align with changing roles or organizational needs.
To participate in an object—such as programs, controls, labels, proof, audits, risks, or vendors—members of an organization (with the exception of Administrators) must be explicitly added to it and granted a specific level of access.
Click the arrows below to learn more:
Manager
Manager
Can manage and share content, manage object members, and manage object settings.
Contributor
Contributor
Can share, add, and remove files from certain objects they are a member of.
Viewer
Viewer
Can view files and information for certain objects they are a member of.
Important: whether a Manager, Contributor or Viewer, users must be added to an object before they can interact with it.
Combination of object roles
If a user has a combination of object roles, such as a viewer role for one object and a manager role for another, note the following:
If a viewer selects objects in a grid view where they have different object roles, such as viewer and manager, they may not have sufficient permissions to perform bulk edits. For example, if the user is a viewer on one selected control and a manager on a second control, attempting to bulk edit both generates a message indicating the number of selected items that can and cannot be updated.
When users are members of related objects, the highest object role is used. Suppose a user is a viewer on an object and a manager on a parent of that object. In that case, they inherit the highest permission of the two objects, allowing edit access.
As shown in the following image, the user is a contributor on a program ABC and its associated requirements, but is a direct viewer on control 1.2.3.4 linked to those requirements; the user inherits contributor access to the control. Click the inherited parent link to see the inherited role and the object that provides that inherited role.
We recommend taking a moment below to navigate to the help center document and bookmark it for future reference. This section in the help center provides detailed information on the actions within Hyperproof that each role can take based on their object-level permissions.
Inherited access versus direct access
It’s important to note that some users may inherit permissions or direct access within an object.
All Hyperproof work items have a Facepile that allows for both inherited access and direct access to an object.
Facepile is Hyperproof's term for the area where users can view who has access to a particular object, e.g. a control. Depending on their permissions, users can add, remove, or change user roles. Work items can also be made private via the facepile.
The difference between inherited access and direct access is:
Inherited access means that a user becomes a member of a work item through a parent object.
Direct access means that a user has been explicitly added to a work item, e.g., a user is specifically added to a request, but not the audit. Inherited access users inherit access to work items through a parent object.
Click the arrow below to learn more:
Direct access
Direct access
A user who has been specifically added to a work item is considered to have direct access to the object. When added, they receive the role of contributor. A user with sufficient permissions can change the new user's role to manager via the facepile.
Inherited access
Inherited access
Users inherit access to work items through a parent object. An example scenario might look like:
User X is a manager of control ID 1234.
An issue is created by another user and linked to control ID 1234.
Because User X is a member of the parent object—in this case the control—they gain contributor access to the issue.
To see how a user obtained inherited access, click the link next to the user’s email address.
