Roles and permissions
Who can do what in the employee portal, the separation-of-duties rules TENSOR enforces, and how to grant editor and approver rights.
Most people need no setup to use the employee portal: an active account in your organisation is enough. Editing content, approving requests and administering the portal each need a role that holds the matching permissions.
Who can do what
| Role | In the portal | Key permissions |
|---|---|---|
| Every active employee (baseline) | Use the portal, read and acknowledge publications, vote, view and dismiss banners, read the directory, read and rate knowledge | employee.portal.read, publication.read, publication.acknowledge, portal.poll.respond, portal.banner.view, directory.read, knowledge.article.read, knowledge.article.rate |
End user (end_user) | Report issues, raise service requests, see only their own requests, propose changes | request.servicerequest.create, request.servicerequest.read.owned_only, change.proposal.submit |
| Approver (for example service owner, service desk supervisor, tenant admin) | Approve or reject service requests at the steps assigned to their role | request.servicerequest.approve |
| Portal manager (tenant admin, service desk supervisor, Platform Owner by default) | Author and publish publications, events, polls, banners; manage quick links and layout; publish projects (tenant admin and Platform Owner only) | publication.author, publication.publish, portal.event.author / .publish, portal.poll.author / .publish, portal.banner.author / .publish, portal.layout.author, portal.project.* |
Tenant admin (tenant_admin) | Everything a portal manager can do, plus categories, quick links, directory settings, directory sync, branding and feature flags | portal.publications.admin, portal.links.admin, directory.admin, directory.sync.admin |
| Compliance officer | Acknowledgement coverage, audit log, reports | Reporting and audit permissions |
| Works council member | Pseudonymised aggregate view only; no individual tickets, no directory | Pseudonymised view context |
An employee who also has an IT role (for example service desk agent) keeps the full portal and additionally sees Open IT workspace.
The baseline is automatic
The baseline rights in the first row are granted automatically at sign-in to every active human member of the organisation, whatever their role. They never include authoring, administration or agent rights, and they do not apply to service accounts or API clients.
Directory: publishing versus importing
directory.admin governs publishing the directory and recording the works-council acknowledgement; directory.sync.admin governs connecting and running directory sync. Because they are separate permissions, the person who imports people and the person who publishes them can be different people. See Directory Sync — ingest is not publish.
Projects
The project portfolio uses its own permissions (portal.project.*). Only tenant admins and Platform Owners publish projects by default. See Employee project portfolio for the full table.
For every built-in role and its complete permission list, see the role catalog.
Separation of duties enforced in code
The rules below are enforced by TENSOR itself, not by convention. They are part of the platform-wide segregation of duties.
| Rule | Effect |
|---|---|
| Mandatory publication: author is not publisher | Whoever wrote a publication that requires acknowledgement cannot publish it. This rule is always on and cannot be switched off per tenant. |
| Mandatory poll or critical or mandatory banner: author is not publisher | Whoever authored it cannot open or publish it; another portal manager must. |
| Requester is not approver | Nobody can approve their own service request, also not through a delegation. |
| Change proposals are decided by change managers | An accepted proposal becomes a draft change with the employee as requester; the normal change approval rules apply from there. |
| Directory and polls need the works council | The directory cannot be switched on, and a poll cannot be opened, until the works-council acknowledgement is recorded. |
| Compliance-relevant role grants need a second administrator | Adding report exports or audit permissions to a custom role requires dual approval. |
What this means for you in practice:
- Portal editors need at least two people with publishing rights if they plan to send mandatory publications, mandatory polls, or critical or mandatory banners. The author prepares and submits; a colleague publishes.
- Approvers never see their own requests as something they can approve. A delegate is bound by the same rule: your delegate cannot approve their own requests on your behalf.
- Tenant administrators cannot enable the people directory or let a poll open before the works-council acknowledgement exists. See Compliance.
Granting access
Employees
Employees need no setup: an active account is enough.
Portal editors
To make someone a portal editor, do one of the following:
- Assign a role that holds the portal authoring permissions, for example Service desk supervisor, under Admin → Users.
- Or create a custom role under Admin → Roles with exactly the portal permissions you want, and assign it under Admin → Users.
A custom role that should include report exports or audit permissions needs a second administrator to approve the grant.
Approvers
Approver rights come from the approver role named in each request type's approval steps. Anyone holding that role and request.servicerequest.approve can decide at that step, except the requester. See Approvals and Guides for managers and approvers.
Works council and compliance
Works council members work only in the pseudonymised view, which requires the betrvg_works_council_view flag. Compliance officers use reporting and audit permissions to check acknowledgement coverage and the audit log.