The Roles resources have been updated for the 2.0 API and we recommend using that version instead of the 0.5 API. The 2.0 API is required for granular control over the new Report Builder capabilities. Read more...
The diagram below shows the relationship between these key objects:
Buzz supports multi-tenant SaaS usage through the establishment of Accounts that separate access for most objects. Outside of Users enabled as Super Users all actions within Buzz are restricted to the scope of the Account in which the requesting user exists.
Only Super Users or Multi-Account users can create or edit Accounts.
Every action in Buzz is completed by a User. Users may be set as Super Users, for access across Accounts, but only a Super User can create or edit another Super User.
Every User must be assigned a Role, which determines the User’s rights to read, edit, write and delete Objects. A Role is defined by a series of Permissions, each of which corresponds to an Object.
Global Roles are created by the system administrator and are available to all Accounts. The only reason to create a Role other than the global ones is if you need different or more granular permissions for certain objects than what is provided by the Global Roles. In these cases, you can create your own Roles that inherit permissions from one of the Global Roles.
Permissions are defined by the Object name and a 4-bit operator corresponding to read, create, update, and delete privileges, respectively.
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:
|advertiser||7||User can read, create, and update advertisers, but not delete them|
|campaign||15||User has full access to campaigns|
|line_item||3||User can read and create line_items, but cannot edit or delete them|
|segment||0||User cannot perform any action on segments|
Updated 7 months ago