Who is this article for?

Administrators configuring user access and troubleshooting visibility issues.

Administrative access to authorisation and system settings.

This article explains how visibility, access, and permissions work, covering the key concepts that determine what users can see and do within the platform.

Visibility model

A user's access to records on the platform depends on ownership, roles, groups, location, and permissions. The core question is: "Can this user view and interact with this item?"

Below is a summary of key concepts, detailed further in this article.

Determining visibility

For an item to be visible to a non-admin user, at least one of the following tests must be true:

If any one of these conditions is met, the user can see the item.

Important

For the group-based access test, both conditions must be satisfied - the group must be linked to the record's Location and to the record's Process. Being linked to only one is not sufficient.

Items without Locations or Processes

Some items, such as Risk Registers, do not have locations or processes. For these items, only the ownership and role membership tests apply. Users must own the item or be assigned to it via a role to see it.

Items without Owners

Configuration items such as rating bands, risk matrices, groups, roles, permissions, and object types do not have owners and do not have locations.

Child data versus associated data

Child data belongs to a parent record and is visible whenever the parent is. Examples include a Risk's assessment history or a Control's assurance records.

Associated data has separate owners and locations. Visibility of the parent does not ensure visibility of associated data. Examples include linked Controls and Actions on a Risk.

Generally, if an object has its own owner, location, or exists independently, it is associated data with separate visibility rules.

Access types

Roles

Roles define a user's position or function related to a specific record, such as Accountable Party, Risk Manager, Business Owner, or Stakeholder.

They are user-defined and can be set for different object types or subtypes. Assigning a role to an object type adds a field to its records for user assignment.

Key points:

• Roles have minimum and maximum user limits (e.g., "Risk Manager: min 1, max 2")
• Roles may include linked permissions
• Users "portray" a role when assigned to its record field
• Role assignment gives the user visibility of that record

Teams

A Team is the collective set of users assigned to the various roles on a single record. For example, a Risk's team might consist of:

The team membership determines who can see and interact with the record, particularly for Audit-level objects where team membership is the primary visibility mechanism.

Owners

Every key object on the platform must have a single owner responsible for it.

Key points:

• Owners have full control, including deletion.
• The owner field cannot be empty or removed.
• Changing the owner requires special permission.
• Only the owner or an admin can remove users from the watchers list.

Note

Configuration objects such as groups, roles, risk matrices, and other system settings do not have owners. These objects are managed by users with the appropriate administrative permissions.

Watchers

Watchers are users who follow a record to get notifications about updates, even if they aren't part of the assigned team.

Key points:

• Users can add or remove themselves as watchers if they can view the record
• Only the owner or an admin can remove other watchers
• Team members are usually added as watchers automatically
• Watching does not grant access to the record

Groups

Groups are user collections with two main roles:

• Linking to Locations and Processes to control user access
• Assigning permissions to all group members

Key points:

• Users gain all permissions from their groups (permissions add up)
• Group visibility requires linking to both Location and Process of a record
• With Restrict Locations enabled, visible locations depend on group memberships

Location and process

Locations and Processes assign your data a home within your organisation. If you have multiple sites or units, create a location for each and assign data using the Location field.

Locations form a ragged hierarchy; viewing data at one location includes its sub-locations' data.

Objects with Locations

Locations suit data tied to a real-world place. For example, a risk might be linked to a finance office, a factory with heavy machinery, or a warehouse prone to theft or fire.

Controls may share locations with risks but can be separate. A global insurance policy might be managed centrally while covering multiple sites.

Location data access

Data in locations you can't access via groups is forbidden, but you can always see the location itself - unless 'restrict locations' is enabled and you lack 'view locations' permission.

This may seem odd but makes sense. You can reference inaccessible locations, like seeing houses on a street but not entering them, or knowing your organisation's Sales or HR departments but not their files.

The location record is visible, but its contents are hidden.

You can assign an item, like a risk, to a location you can't access. It becomes hidden once you lose ownership or role access - like posting through a private house's letterbox, you can't easily retrieve it.

Note

Process is not a mandatory field on all objects. When an object has a Location but no Process assigned, it is available to all users who can see its location.

Permission types

Permissions control user actions in the software, such as Create Risk, Edit Control, Delete Objective, View Locations, and Manage Lists.

Key points:

• Permissions cannot be assigned directly to users
• Users inherit permissions from their groups
• Users inherit role-based permissions for specific records
• Group permissions apply globally; role permissions apply only to relevant records

Groups

When you add a permission to a group, every member of that group gains that permission for all objects they can see, at all locations.

Example

If a user inherits the Delete Risk permission from a group, they can delete any Risk they can see, regardless of its location.

Some permissions can only be assigned to groups (not roles) because they do not relate to specific records:

• Create permissions (you cannot create an object that already exists)
• Configuration object permissions (groups, roles, matrices, etc.)

Roles

When you add a permission to a role, users who portray that role gain that permission only for the specific objects where they hold that role.

Example

If the Lead Auditor role has the Delete Audit permission, a user in that role can only delete the specific Audits where they are assigned as Lead Auditor - not all Audits.

Use cases

Universe versus Audit visibility

It's important to understand the difference between Universe-level and Audit-level visibility, as they function differently.

Universe objects

Universe objects (Risks, Controls, Objectives, Tests, Actions, Incidents) follow this model:

• Ownership grants access
• Role/Team membership grants access
• Group access applies only if the group is linked to both the record's Location and Process

A user's Universe view depends on their group memberships and the associated Locations and Processes. Both must match for group-based access.

Audit Objects

Audit visibility differs, as a user must be on the Audit Team to see it in their register:

• Audit visibility works like Universe object visibility
• The audit's scope defines which groups and locations can access it
• Audit Team members can view everything within that Audit

Further reading

• Configuring system settings that affect visibility