Overview

Roles are applied to users and govern which actions they can or cannot take. If you are a user with Administrator privileges, or have role creation rights, you will be able to create new custom roles using the Beeswax UI and API.

Creating a Role

In order to create a role:

1. Navigate to Admin > Roles from the top navigation bar.

   2. This will bring you to the Roles page. Click on New Roles to bring up the Create Role page.

    3. Fill in all the relevant fields (required fields marked with an asterisk):

Role Types

There are default system roles that come with your Buzz Key (e.g. Administrator, Campaign Manager, Trafficker, Reporting) which are assigned preset permissions, but you can create custom roles in order to tailor access for each of your users.

System Roles 

System Roles are pre-configured for convenience and cannot be edited. When attempting to edit a system role, the fields will be disabled and a lock icon will appear in the top right corner to indicate that it is locked for any changes.

Custom Roles 

Custom roles give you full control over what objects each user can read, create, update and delete within their account. 

1. To create a custom role, a Parent Role must be selected from the dropdown - options for which are the system roles defined by Beeswax. This enables the custom role to inherit any new field configurations added in the future.
   
2. Name your custom role. Optionally, set the Alternative ID to a value of your choice at the bottom of the dialog. This can be left blank if not relevant.
   
3. Select a Share across accounts setting. This toggle set to either Yes or No determines if the role can be used across multiple accounts within the Buzz Key.
   Notes: This functionality was renamed from “Global” in the November, 2020 release. Only Administrators who are multi-account users and have “edit/create” permission to the Roles object can create roles shared across accounts.
   
   
4. Select the desired permissions for the custom role. There are four types of permissions that can be set - each controls an aspect of the user’s access to objects and information. See the Permissions section below for details.
5. Submit the new role settings.
6. Assign the role to a User. 

   A role can be archived to be hidden from the roles selection menu on the user screen. Once archived, no new users can be created with this role. Existing users with this role will not experience any disruption in service and they will still have the same level of permissions as before. To archive a role, switch the Archive toggle in the top right corner.

Permissions

Report Permissions control which reports within Report Builder the user can access.

Report Field Permissions control which dimensions and measures are available to the user across all reports in Report Builder. Each permission setting within this field will affect a group of fields. For example, Experiments is a permission group that has all the fields related to the Experiments feature (i.e. Test Plan ID, Test Group ID etc) while Vendor Data is a different permission group that has all the fields associated with vendors (i.e. Vendor Fees, Vendor fee name etc).  For a full list of report field groups, see here.

Object Permissions control which objects the user can access and which actions they can perform. This works independently from other permissions. Read permission on the “account” and “static” objects are required for users to use our platform, thus those cells are locked for edits.

Dashboard Permissions control which dashboards the user has access to. You can read more about the Dashboard feature here.

FAQ

Q: What is the impact of Archiving a role?
A: Archiving a role means that no users can be created or updated to use this role. Any existing users can continue to use this role and the associated permissions. 

Q: How do Dashboard Permissions work with Report Field Permissions?
A: Dashboard permissions control which dashboards are accessible to the user. Note that fields within the dashboard are not affected by the report field permissions. So even if a user’s role has “Core Metric” data fields disabled in their report field permissions, they will still be able to see core metric data if permitted access to a dashboard with these metrics included.

Q: How do Reporting Permissions work with Report Field Permissions?
A: Reporting permissions control which reports are accessible to the user (e.g.- Performance Report, Platform Report, Domain Report). The Report Field Permissions control which fields within these reports are shown. Field permissions were previously nested under each report and controlled on a per report basis, but the new Report Field Permissions works across all reports.

Q: Can field name aliases be used in Report Builder?
A: No, users cannot set alias names for fields per-report in the UI. This functionality was previously available in the Query Tool, but has been deprecated.

Q: The data groups available in Report Field Permissions do not support the granularity I need for a custom role. Can these be changed?
A: Please reach out to your Customer Success Manager to provide feedback and inquire further.