Permissions Management
The Permissions system allows administrators to control access to reports, fields, templates, layouts, dashboards, and data sources in the Reporting Portal.
Permissions are based on Allow and Deny rules applied to users or user groups. The system supports hierarchical inheritance, component-level restrictions, and data-level restrictions to help enforce security and visibility policies.
With this functionality, administrators can:
- Control access to reports, fields, templates, and layouts
- Implement targeted restrictions and security best practices
- Restrict visibility of sensitive information
- Configure access to Providers, Connectors, Connector Accounts, and Accounts
- Apply permissions to users or groups
- Apply rules to individual objects or groups
Note: everything is denied by default — grant access explicitly. Component access (which reports/fields/templates a user can see) and Data access (which providers/connectors/accounts a user can see) are separate and both must be configured.
CORE RULES
CORE RULES
- All access is denied by default. You must explicitly grant Allow.
- Every rule has three parts: Object (what), Subject (who: user or group), Relation (Allow / Deny).
- There are two independent permission layers: Component and Data. Both must be configured.
- Permissions are inherited: a rule on a parent object applies to all its children automatically.
Priority & Override Rules
| Situation | Result |
|---|---|
| Group → Deny | Access denied |
| Group → Deny + User → Allow | Allow wins (user-level overrides group-level) |
| User → Deny | Access denied — cannot be overridden by anything |
| No rule at all | Denied (default) |
Deny beats Allow at the same level. But a direct user Allow always overrides a group Deny.
What Each Object Controls
Component Permissions (permissions/assign)
| Object | What it controls |
|---|---|
| Reports | Visibility of report types and fields |
| Reports → [Report Type] | Access to that specific report type |
| Reports → [Report Type] → [Field] | Access to that specific field |
| Scheduling | Visibility of the scheduler / task management component |
| Predefined Templates | Which predefined templates a user can import — does not restrict creating custom reports from allowed fields |
| Predefined Layouts | Which predefined layouts a user can import |
Granting access to at least one field enables: dashboards, template creation/editing, and filters.
Granting access at the Reports top level = access to all report types and fields under it.
Data Permissions (permissions/data-assign)
| Object | What it controls |
|---|---|
| Data Filters (top level) | All data sources and AB Book filter |
| Providers | Access to provider-based data |
| Connectors | Access to connector-based data |
| Connectors → [Connector] → [Account] | Access to a specific connector account |
| Accounts | Access to account-based data |
| AB Book | Visibility of the AB Book global filter on dashboards only — does not affect AB Book fields in reports |
Granting access to a Connector = access to all Connector Accounts within it.
RECOMMENDATIONS
RECOMMENDATIONS
How Data Permissions Affect Reports
| Without access to… | These reports are empty |
|---|---|
| Accounts | Account Wallet, Account Position, Account Position EOD, Account Wallet EOD, Account EOD |
| Providers or Connectors | All other report types |
Common Mistakes to Avoid
-
Broad top-level Allow — Granting
ReportsorData Filtersat the root level gives access to everything under it, including items added in the future. Grant specific items instead. -
AB Book for all users — Only grant AB Book access when the user role genuinely requires the global filter. It is a sensitive operational filter.
-
Connector vs Connector Account — Allowing a Connector grants access to all its Connector Accounts. If a user should see only one account, allow that Connector Account specifically.
-
User-level Deny is permanent — A Deny rule on a specific user cannot be overridden by any group rule. Use it deliberately.
-
Deleting a group in use — You cannot delete a group that is referenced in any rule. Remove all related rules in
permissions assign/permissions data-assignfirst. -
Component access without Data access — A user may have report types and fields allowed (Component), but if no data sources are allowed (Data), all reports will be empty.
-
Data access without Component access — A user may have data sources allowed, but without field-level Component access, the user cannot interact with any reports.
Prefer Group-Based Rules
- Assign permissions to User Groups, not individual users whenever possible.
- Use object groups (Report Type Groups, Field Groups, Provider Groups, etc.) to manage related items together.
- This reduces configuration errors and makes future changes easier.