Capabilities

Capabilities grant access to actions and areas of Experience Cloud. They are hierarchical, in that some are parents to others. Selecting a parent capability grants access to all of its child capabilities. For example, to see social media reports, a role needs the Social Media reporting capability. When you grant that access to a role, all of the users with that role will gain the capability, but none of the other social media features. However, selecting the Social Media (all access) capability grants access to all social media features.

Assign capabilities on the Roles screen, or when necessary, on the Users > Capabilities screen.

For a complete list of available capabilities, see Capabilities.

Permissions

Access control works on a per-record basis. Users see only the records for which they have permission. This includes the aggregate information derived from records. For example, store managers looking at a report might only see information about their particular store, while regional directors might see the records for all stores in the same region. (The report defines which fields the user sees.)

Access control compares values in fields to the permissions granted to the account. When the permissions match the fields, access is granted to the record. When no permissions are defined, users have no access.

Data view

The first step in defining permissions is to identify all the fields that may be used for access control. This is done on the Permission by Segment screen, where you pick the default fields available to all roles, and the specific fields available only to certain roles and contexts. The following example shows the Stores (Units), Region (Unit Group), and Program (Segment) fields as available for access control for all accounts:

The set of permission fields is called a data view. The data view identifies the data access fields available to user accounts per role and context.

Data access

Data access defines the specific data users can see. Data can be manually assigned for each user with the Data Access option on the Users screen. Permissions can also be defined as part of the import process for accounts. See Setting access permissions with Auto Importer for details.

In the following example of a data access declaration, units are called Stores, so each defined unit appears in the All Individual Stores list.

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

Alternatively, you can assign access to all units:

Doing this allows each user to see all records for all units, as shown in the following tables:

Data access permissions can be combined. For example, with the following settings the user can see records where the value of the Program segment is Parts:

In the following example, the user Mike can see all records in the company where the Program field value is Parts:

Additive and subtractive permission combinations

When there are multiple permission criteria, Experience Cloud combines them to determine the final permission. Specifically, permissions can be granted on three categories of data: units, unit groups, and segments (fields). Within any individual category, 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.

However, between the three categories, the records shown are the intersection of the results (an AND condition). A record must match in all three categories to be visible to the user.

Roles as data access filters

Roles classify users by capabilities and permissions. All users have a primary role, and some users have additional roles. Users with multiple roles can switch between them to change their capabilities and permissions. Regardless of how many roles a user has, only one role is active at any time, and only that role 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 setting 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 are related to the company’s organizational structure, such as job level, but they can also be used to classify units in other ways, such as by sales region, product brand, or company division. When an Org Hierarchy is specified for a role, users with that role can see records in that business segment only.
• 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 survey fields (E-Field, A-FIelds, Q-Fields, and K-Fields). When a segment is specified for a role, users with that role can see records in that segment only (records with the matching field values).

Remember, permissions on roles filter the records available. The following example shows four roles, three of which filter the records the 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 will 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.

Org Hierarchy and Data Access

The Org Hierarchy setting on the Roles screen associates the role with a unit group, thereby limiting the role to see only records tied to those units in that business segment.

Unit groups are arranged in a hierarchy called the Organizational Structure, which is defined and visible on the Roles screen. The top of the structure (the root node) represents the entire company, and has a name in the form "All COMPANY UNITS", such as "All Orion Stores". As such, when no unit group is assigned to a role, each member of that role has access to all of the units in the company. On the account’s Data Access dialog, you can manually choose to make all units available, or select the specific units the user can see.

However, when a unit group is assigned to the Org Hierarchy, the Data Access screen changes to reflect the units in that segment.

Each unit group, including the root, can contain zero, one, or multiple child unit groups. The nodes immediately below the root node are the parent unit groups. The Org Hierarchy selection only accepts parent unit groups, regardless of the number of levels of descendant child unit groups.

All units usually belong to at least one unit group segment, but they do not have to belong to any, nor do they have to belong to all parent unit groups.

Contexts

Permission contexts supplement and override user 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 place where permissions can be granted beyond what the user would normally be allowed to see.

For example, users with the Manager role might be limited by default to see information only for their unit. To see how their unit compares to others in the same unit group, the Ranker report can accept a context that overrides the default permissions, and thereby permits the user to see the summary scores for other units. However, the managers are not permitted to drill-down in the other stores to see the details of those stores. This works because the Ranker report is preconfigured to access a permission context when displaying the ranked list. Other standard reports have similar context areas, and dashboards and custom (AA2) reports can also use permission contexts.

In the following image, some of the roles are limited to various segments, and there is a permission context named Ranker Access that has access to all units. While some of the roles are restricted to the data they can usually see, all roles (example Manager Store) can see how all units in the company rank compared to the others on the Ranker report. The store managers can see all the stores in their regional segment (which is a custom segment).

After the permissions are assigned to a context, you can use the context in the following reports:

• Custom report — Using the report's Permission Context property.
• Standard report — Creating a context assignment, which associates the role, context, and report.

The general steps for creating and using permission contexts are:

1. Create the context on the Permission Contexts screen.
2. Optionally, assign the context to one or more standard reports or Ranker reports on the Context Assignments screen.
3. Optionally, reference the context in a custom report by setting the Permission Context property. To apply a context to an entire report, select it from a dropdown on the Advanced Analytics page, or on a dashboard module that is using that report. To use a context within a custom report, use the <permission-context name="Insert Permission Context Name Here"/> node. This node behaves differently depending on usage. See the XML documentation for details.
4. For roles that will use the context, assign the context on the Roles screen. Otherwise, the permissions assigned to the context can apply to the entire company.
5. Grant the specific permissions to the context on the Permission by Segment screen.

Setting permissions with Auto Importer

The Auto Importer Account plugin allows you to set data access permissions for accounts, and permissions by segment settings for roles as part of the import process. For more information, see Setting access permissions with Auto Importer.