Access Control
Bronto offers a flexible access management system that allows you to customize the level at which you control access to your Bronto resources.
Role Based Access Control
Roles categorize users and define what account permissions those users have, such as what data they can read or what account assets they can modify. By default, Bronto offers three roles.
| Role Name | Description | |
|---|---|---|
| Administrator | The Administrator Role grants individuals full access and control over the application. | |
| Standard | The standard role grants full access over all non sensitive areas of the application. | |
| Read-Only | The read only role grants read access to non sensitive areas of the application. |
Custom Roles
Create custom roles to combine multiple permissions into new, tailored roles. A custom role allows you to assign various CRUD permissions across Access Management, API Key Management, Billing and Usage, Dashboards, Integrations, Limits, Log Management, Monitors, and Tags Management.
Once a role is created, you can assign or remove permissions directly by updating the role in the Organization Roles Settings page.
You can assign granular permissions across:
- Access Management
- API Key Management
- Billing & Usage
- Dashboards
- Integrations
- Limits
- Log Management
- Monitors
- Tag Management
You can manage roles in Organization Settings → Roles.
Note:
Permissions for roles in Bronto are additive — if a user is assigned multiple roles, they receive the union of all permissions from those roles. For example, if one role grants permission to create monitors and another does not, the user will still be allowed to create monitors. However, for dataset access permissions, denials take precedence: if a dataset or collection is explicitly forbidden, access will be denied even if another role permits it.
Fine-Grained Access with Dataset Restrictions
Bronto supports access restrictions for datasets and collections.
These allow you to:
- Restrict a role to only access datasets or collections
- Deny access to specific datasets or collections (even if the role has general read permissions)
Example Use Cases
- A security team role that only provides access to the
securitycollection - An external auditor role that cannot access PII-related datasets
Best Practices
- Use built-in roles for general access and admin controls.
- Use custom roles to create scoped access patterns (e.g., Billing-only, Security-only).
- Always test new roles with limited users before broad rollout.