Accounts, Users, Roles, Permissions

📘

Migration Notes

• The Roles and Users resources are available in the 2.0 API, but Accounts are only available on the 0.5 API for now.
• In the 0.5 API, permissions and reporting permissions were set explicitly on each Role. In the 2.0 API, permissions are inherited from parent roles, and may be omitted if the parent's settings are sufficient.
• The 2.0 API has different fields and syntax for controlling reporting fields and permissions, as described below.
• The 2.0 API supports Users and Roles, but the Accounts resource is not yet available.

The diagram below shows the relationship between these resources:

Accounts

Buzz supports multi-tenant usage through the establishment of Accounts that separate access for most resources. Outside of Users enabled as Multi-Account Users all actions within Buzz are restricted to the scope of the Account in which the requesting user exists.

Only Multi-Account users can create or edit Accounts or create or edit objects in Accounts other than the one in which their User was created.

Users

Every action in Buzz is completed by a User. Users may be set as multi-account, for access across Accounts.

Roles and Permissions

Every User must be assigned a Role, which determines the User’s rights to read, edit, write and delete objects as well as which reports, dashboards, and report fields they may access. A Role is defined by a series of Permissions, each of which corresponds to a resource, for example the advertiser resource.

Default Roles and Custom Roles

A set of default Roles are created are available to all Accounts for each Buzz Key. You may create a custom Role if you need different or more granular permissions than what is provided by the defaults. In these cases, the Role you create will inherit permissions from one of the defaults, using the parent_role_id field.

Role Scope

📘

Sharing Roles Across Accounts

You can now create your own roles that work across Accounts! This is available to users who are enabled for multi-account.

Roles may be specific to an Account or may be used across Accounts. All default Roles work across accounts. In the 2.0 API any multi-account user can create a role to work across accounts by setting the shared_across_accounts field to true.

Object Permissions

Permissions are defined by the resource name (singular) and a 4-bit operator corresponding to read, create, update, and delete privileges, respectively. Permissions are set within a Role using the permissions field.

If a Permission is set to 1, the User enabled can only read that type of object. If set to 3, the User can Read and Create the object (1+2). When a Permission is set to 15 then have full rights to the object (1+2+4+8). Examples:

Reporting and Dashboard Permissions

Roles can limit access to reports, the fields within reports, and dashboards within the UI. If these settings are left blank for a Role, the assigned Users will inherit access to those objects from the parent role. The fields in the Role object for editing these settings differs significantly between the 0.5 and 2.0 APIs.

A summary of the reporting permissions:

• The report_ids field determines which reports the Role can access. A list of available reports may be retrieved from the /reporting/reports resource.
• The dashboard_ids field determines which UI dashboards the Role can access. A list of available dashboards may be retrieved from the /ref/dashboards resource.
• The report_field_group_ids field determines which groups of fields the Role can access. For example, you may not want certain users to have access to financial reporting data. A list of available field groups may be retrieved from the /ref/report-field-groups resource.