Workspace Roles¶

Workspace roles govern user access within a workspace. Each role is a set of permissions that controls what a user can see and do across different features of CxReports.

Default Role¶

CxReports provides a default Administrator role that grants full access to all workspace features and settings. All other roles must be created manually to match your organization's needs.

Creating Custom Roles¶

To create a custom role:

1. Navigate to the Admin application, then Workspace → Roles.
2. Click Add New Role.
3. Name the role and provide a description.
4. Set the access level for each permission. The permissions shared by every application come first: Reusable Data Sources, Reusable Parameters, Semantic Models, External Databases, File Management, AI, Tools and Workspace Configuration. The application-specific permissions follow under their own headings:
   • Reports — Reports, Templates, Themes, Dictionaries and Jobs.
   • Portals — Portals, Portal Designs and Portal Themes. This section is shown only when Portals is enabled for the instance.
5. Use the switch next to each application heading to allow or deny access to that whole application (see Application Access).
6. Click Save.

For details on assigning roles to users, see User Management.

Application Access¶

The switches next to the Reports and Portals headings control whether members with the role can use that application at all. New roles have Reports switched on and Portals switched off; the default Administrator role has both on.

When an application is switched off for a role:

• The application is hidden from the application switcher, and opening its address shows a "no access" page that asks the member to contact a workspace administrator.
• Every permission in that section counts as No Access, whatever level is set.
• Access granted on individual reports, report generation jobs or portals no longer applies, including reports and portals the member created or that were shared with them or their role. For Portals this includes viewing portals through their published links.
• Scheduled report generation jobs created by members with the role can no longer generate their reports.
• The levels set in the section are kept, so switching the application back on restores them.

Permissions¶

Each feature category supports a specific set of access levels. The available levels vary by category — not all categories offer the same options.

Reports¶

Templates¶

Themes¶

Dictionaries¶

Attaching a shared dictionary to a report requires Read access to Dictionaries, and changing a shared dictionary's name or languages from a report requires Full Access. A report's own dictionaries need only access to the report.

File Management¶

Jobs¶

Jobs require that the user has at least Read access to Reports, Templates, Themes, Dictionaries, File Management, Reusable Parameters, and Reusable Data Sources — otherwise jobs cannot function correctly.

Reusable Parameters¶

Covers the parameters shared across the workspace (Parameter Groups, Reusable Parameters and Global Parameters).

Using a reusable parameter in a portal page or layout requires Read access to Reusable Parameters, in addition to edit access to the page or layout.

Reusable Data Sources¶

Covers the reusable data sources shared across the workspace (Global Data Sources). Data sources defined on a report or portal page are not governed by this permission.

Using a reusable data source in a report or a portal requires Read access to Data Sources, in addition to edit access to the report, portal page or layout. A report's or page's own data sources need only edit access to the report or page.

A reusable data source that a user can't read is not listed for them in the report designer. When they open or export a report it applies to, the report shows an error naming that data source, and the export fails.

External Databases¶

A user can have Full Access to Reusable Data Sources while having only Read access to the External Databases those data sources connect to. This allows the user to manage data source configurations without being able to alter the underlying database connections.

Workspace Configuration¶

Semantic Models¶

Portals¶

The role's level applies to every portal that inherits access from the workspace, as long as the role's Portals switch is on. A portal's own access settings can raise or lower it for specific users and roles — see Portal Access Control.

Portal Designs¶

Designs are shared across portals, so a change to a design affects every portal built on it.

Portal Themes¶

Best Practices¶

• Least privilege — assign only the minimum access necessary for each user's responsibilities.
• Review periodically — ensure roles still align with current duties and organizational policies.
• Clear naming — use descriptive role names so their purpose is immediately obvious.