Roles and what you can do#

Reportworq tailors the app to each account. What a person sees, the side rail, the toolbars, the actions on a row, is decided by their role. Two things combine to produce what an account can actually do:

• Role decides the shell and the set of actions available (for example, whether the New button appears at all).
• Permissions (ACLs) decide which items the account can see and act on inside that shell.

An account's effective access is the role constrained by the permissions on each item. This page is a reference to the roles themselves.

The four roles#

Reportworq has three licensed roles, Administrator, Author, and User, and one role that is not a license at all: the Recipient, who simply receives distributed content. Every person who signs in holds exactly one licensed role, and that role applies across the whole installation (you are not an Author in one workspace and a User in another).

What each role sees#

• Administrator. An administrator gets the author experience plus the Settings surfaces (security, integrations, configuration), is the only role that can see any content regardless of item permissions, and is the only role that can change who can see content.
• Author. The Workspace browser, the Job Editor, Scheduled Content, monitoring, the Address Book, and Global Parameters. This is the primary content-building role. An Author respects item permissions and workspace scope; it is not an administrator and does not bypass content security. An Author can see who has access to an item, read-only, but cannot change it.
• User. A User signs in to consume Reportworq rather than build it. Depending on what they are granted, a User browses a read-only Workspace to find reports and view their outputs, participates in contribution campaigns as a contributor or approver, refreshes a distributed PowerPoint deck through the add-in, or reaches governed content through the MCP server and the built-in AI assistant. In the read-only Workspace the row ⋯ menu is trimmed to Properties only (every other action is a change), and the shell omits the header search box and the Activity area. A User assigned to a contribution campaign keeps the same read-only Workspace and gains a My Input Forms entry in the side rail, where they fill in and submit the forms the campaign assigns. There is no separate contribution-only shell and no contribution-only account.
• Recipient. A recipient is not a Reportworq account and never signs in. They simply receive distributed output where they already work. Recipients are managed as contacts in the Address Book, they hold no role, consume no license, and are unlimited and free.

Recipient is a concept, not a setting. "Recipient" describes anyone who receives distributed content without a login. There is no Recipient entitlement to grant and no Recipient seat to buy; you never assign it in Security. Sending an output to someone does not require them to have a Reportworq role. See Address book and contacts.

Who can see and change permissions#

An item's permissions, the list of accounts and groups that can see a folder, a report, or the workspace as a whole, are themselves governed by role.

As an Author you can open the Security tab of any item you can reach and see exactly who has access, which is often what you need in order to answer "why can't they see my report". The list is read-only: there is no Save, no way to add an account or group, and no way to remove one. Changing access is an administrator task, so ask an administrator.

This holds however you reach a security surface, including from a saved link or browser history.

Earlier role names fold in#

If you are reading older documentation, license notes, or an account export, several retired names map onto the three current roles:

• Reader, Consumer, Contribution End User, and PowerPoint End User all fold into User. Contribution participation and PowerPoint add-in refresh are capabilities of the User role, not separate seats.
• Reporting End User and the "Reporting add-in for Excel" seat fold into Author. The Excel authoring add-in is part of the Author role.
• The Author entitlement was labeled Reportworq Administrator in earlier versions; it is the same entitlement under a clearer name. Where you see "Reportworq Administrator" used as a user role, read it as Author. It is not an administrator: it grants authoring, not administration, and it cannot change permissions.

Administration and workspace access#

Administration is not tiered. The Administrator role has full access to every workspace on the server regardless of individual grants, and it governs roles and cross-workspace scope. There is no per-workspace administrator: Settings, including datasource configuration, is Administrator-only.

Within a workspace there is one kind of grant: everyone listed on a workspace is a member, and a member can reach the workspace and its content as their item permissions allow. There is no second level to choose.

Workspace membership decides whether an account can enter a workspace; per-item permissions decide which items inside it the account can see and act on.

If you are looking for Configuration Access. Earlier versions offered a second workspace level, Configuration Access (sometimes called Workspace Administrator), that allowed datasource management inside one workspace. It has been removed. Member is the only level.

Notes and limits#

• Roles constrain access, not distribution recipients. Sending an output to someone does not require them to have a Reportworq role; recipients are managed through contacts and the Address Book, and they consume no license.
• Contribution participation (contributor or approver) is a capability of the User role, available when the Contribution capability is licensed. It is not a separate seat.
• At least one Administrator must always exist; an account with no workspace access cannot sign in.
• How roles are assigned (directly, through groups, or through identity-provider claims) and how permissions are configured are administrator tasks. See Sign-in and SSO and Workspaces.