Data access permissions

Permissions identify the information users can access. They are defined by a combination of units, unit groups, and fields in records. Permissions are assigned to Roles, with access determined by the user's active role. Users may have multiple roles but only the permissions of the active role at any time. Some users may have additional, specific permissions assigned just to their account or by using Data views.

Important: Granting permissions and data access to other users is governed by the admin's Primary role.

Understand basic data access

Data access defines the specific data a user can see. It works on a per-record basis, so users see only the records for which they have permission. This includes the aggregate information derived from the records. For example, Store Managers looking at a report might see information only about their particular store, while Regional Directors might see the records for all stores in the same region (the report defines which fields in those records the user sees).

To manage other users, the administrator must be granted the Manage Users administrative permission and then have scope limited to the specific users that administrator should be able to manage. Data permissions are determined by comparing the data access set for the default data view of the primary role of the administrative user to the data access set for the default data view of the primary role of the target user. An administrator can manage any users with the same or less data access for the specified roles.

For each role, the data views assigned to the primary role of the administrative user is compared to the permission set for each of the target users' roles to evaluate if the data access can be changed.

For each data view, the target user needs to have the same or more permissions fields specified in Permission by segment.
Note: Permission by segment is required for delegated administration to work.
To update data access, the administrator must have access to at least one unit group, unit, or segment for the data view they are managing.

Watch this video to learn about data access using a spreadsheet with filterable columns:

No permission

Access control compares values in fields in the report and records to the permissions granted to the user account. When the permissions match the fields, access is granted to the record. When no permissions are defined, the users have no access, as in the following image:

User can only see fields for which they have permission

Unit-only permission

When a Unit is assigned to user accounts, those users are able to access the records for their individual stores, but not for the other stores.

User accounts can only see their unit's records

All units permission

Alternatively, you can assign access to all units to each user, which allows each user to see all records for all units.

User accounts for Company can see all records for all units

Note: The All Units option allows the user to see all records, including ones where the unit field is empty (null), which can happen when surveys are not associated with a particular unit.
Warning: When Org Hierarchy filtering is disabled, all Company Units data access makes the role behave as dynamic access regardless of the data access you set on it.

User-specific permission

Data access permissions can be combined. For example, the user Mike can see all records in the company where the Program Access field value is Parts.

User accounts for Company, and the record for the Mike user can see the Parts segment

To grant additional access to specific users, see Users.

Additive and subtractive permission combinations

When there are multiple permission criteria, the system combines them to determine the final permission. Specifically, permissions can be granted on three categories of data: units, unit groups, and segments (fields).

Within a category the permissions are additive, or the union of the results (an OR condition). If one record is a match for one segment, and another record is a match for another segment, both in the same permission, then both records are shown.

Within a category, users can see all records for which they have permission

However, between across multiple categories, the records are the subtraction or intersection of the results (an AND condition). A record must match in all relevant categories to be visible to the user.

Between three categories, users must have a permission in each of the categories to see the record

Roles as data access filters

Roles classify users by feature and data permissions. All users have a primary role, and some users have additional roles. Users can switch between roles to change their feature and data permissions, but only the active role (selected) determines the user’s access permissions at that time.

By default, a role has no affect on a user’s permission. But, when the role has an Org Hierarchy or unit segment specification, those settings act as filters and effectively put limits on the records the user can see. Specifically:

  • Org hierarchy — Associates the role with a unit group, which is a segment of the company’s business model. Unit groups define a segment of the company’s business structure and are a way of classifying a unit. Traditionally, unit groups were related to the company’s organizational structure, such as job level, but can also be any way the company classifies units, such as by sales region, product brand, or company division. When an Org Hierarchy is specified for a role, users in that role can see only records in that business segment.
  • Unit segment — Associates the role with records meeting a specific criteria based on field values in the record. For example, a segment might be for records associated with a specific survey program, such as when there are different surveys for Customer Sales and for Internal Employees. Segments can be based on a combination of one or more invitation and fields. When a unit segment is specified for a role, users in that role can see only records in that segment (records with the matching field values).
Tip: Use roles to define data access permissions wherever possible, as this sets the same general permission to all users in the role, and then use specific, data access permissions to limit users within the role.

Permissions on roles filter the records available. The following example has four roles, three of which filter the records the users can access:

Example of four roles, three of which filter records that users can access

In the example above:

  • Skyler can see any records tied to any unit in the Bay Area region because his Data access specifically limits him to that region.
  • Nancy has no filters, and can specifically see all the records associated with all units.
  • Kendra does not have any Unit or Region restrictions, but can only see the records associated with the Sales program because of the segment filter on her role.
  • Mike can see any records tied to any unit in the So Cal region that are also associated with the Parts program.
  • Linda has a filter on Region, but because there is no specific region specified in her data access, she can see any record tied to a unit in any Region.
  • John does not see any records because his role shows only records from the Sales program, but his specific data access is only for the Parts program.
Important: In the example, Nancy (with the Corporate role) can see any record in the company, while Linda (Director) is limited to records that are tied to units in any Region (must have a region). If every record is tied to a unit that is tied to a Region, they will see the same set of records. But if there are records that are tied to a unit that is not tied to a Region, Nancy will see them but Linda will not. This is because Linda’s Corporate role filters her records.

Data views

Data views supplement and override the account permissions, but only in the specific context in which they are applied. Unlike other areas of access control that combine to restrict access, this is a way to grant permissions beyond what the user would normally be allowed to see.

One circle labeled "Specific data a Role can see" contained in a larger circle labeled "Additional data from data views"

The most common use case for data views allows users to view data that would otherwise require an unacceptably broad data access relative their role. For example, Store Managers in a retail environment might want to see how they rank against other stores, but it may be inappropriate for a Store Manager to be able to drill down to data for employees at other stores.

For example, users with the Store Manager role might be limited by default to see information only for their unit (store). To see how their unit compares to others in the same unit group, the Ranker report can accept a data view that overrides the default permissions, and thereby permit the user to see the summary scores for other units.

Note: In this example, Store Managers are still not permitted to drill down in the other stores to see the details of those units. This works because the Ranker report is preconfigured to access a data view when displaying the ranked list. Other modules and custom reports can also accept data views.

You can also use data views to target data access for a specific report. For example, if the default data access is very broad, but a particular report is intended to focus on a subset of that data, apply a data view that is more restrictive than the default.