Navigating the facepile within a risk register

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 below demonstrates the facepile on a program. However, the concept is the same. The difference is that to access the facepile, you'll navigate to the risk tab and click into a risk register.

The tutorial below is shown in the administrator role with organizational permission as a manager in Hyperproof. If you are in another role in Hyperproof, or have a different permission you may not have access to some of these areas shown or they may be greyed out.

Click the arrow below to learn more:

Navigating the facepile

First, select the object you want to access the Facepile for. i.e. within the risk register.
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.

To participate in an object, members of an organization, except administrators, must be explicitly added to it and given a specific level of access.

Important: whether a Manager, Contributor or Viewer, users must be added to an object before they can interact with it.

Click the arrows below to learn more:

Manager

Can manage and share content, manage object members, and manage object settings.

Contributor

Can share, add, and remove files from certain objects they are a member of.

Viewer

Can view files and inform for certain objects they are a member of.

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.

Inherited access verse 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.

Click the arrows below to learn more:

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

Users inherit access to work items via 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.