How the portal fits into TENSOR, how tenants and audiences are isolated, and which flags, jobs and audit records sit behind it.

The employee portal is a separate employee surface of the TENSOR web application. It shares sign-in, tenant, branding and data with the IT workspace, but it has its own page frame: no IT sidebar or IT menu can appear on a portal page. Content and services come from the TENSOR modules that own them.

How the portal fits into TENSOR

Module	What it contributes to the portal
Portal	Home page layout and sections, push banners, polls, quick links, the unified portal manager.
Announcements	Publications and categories, acknowledgements, events.
Request (service catalogue)	Request types, catalog items, bundles, service requests and approvals.
Incident and intake	Report an issue, the requester conversation, live chat.
Knowledge	Articles visible to employees, ratings, suggested help.
Identity	Sign-in, roles, the people directory, org chart, directory sync.
CMDB and licence management	Devices, services and licences shown under My assets; ownership shown on profiles.
Change	Change proposals raised by employees.
Notification	In-app and email notifications, the action badge, notification preferences.
Projects	The company project portfolio under People.
Customization and branding	Company name, logo, accent colour, all labels in English and German.
Pseudonymization and audit	Masked views for the works council; the tamper-evident audit log.

Every company (tenant) has its own database schema. Every read and every change runs inside a transaction bound to the signed-in user's tenant.

The portal is always behind single sign-on; there is no anonymous access. Public help content lives in a separate, hardened public FAQ, never on the employee portal.

Every active human member of the organisation can use the portal, whatever their role. This basic set of rights (read the portal, read and acknowledge publications, vote in polls, view banners, read the directory, read and rate knowledge) is granted automatically at sign-in. It never includes authoring, administration or agent rights, and it does not apply to service accounts or API clients. See Roles and permissions for the permission keys.

Core objects

Object	Holds	Relationships
Publication	Title, text, category, audience, state, publish and expiry time, acknowledgement required yes or no, cover image	Many acknowledgements; attachments; optional project links
Acknowledgement receipt	Who acknowledged which publication or banner, and when	Append-only; linked to an audit entry written in the same transaction
Event	Title, details, start, end, location, external link, audience, state	Link-out only; no attendee data
Push banner	Message, severity, dismissible, mandatory, regulated intent, icon, tone, audience, state	Per-user dismissals and receipts
Poll	Title, questions, anonymous flag, results threshold, audience, state	Responses (without user when anonymous) and one participation token per user
Quick link set	Links with label, URL, icon, audience, order	Shown on the home page
Layout section	Section type, configuration, audience, order	Composes the home page
Request type and catalog item	Form fields, approval steps, fulfilment tasks, visibility	Produce service requests
Service request	Requester, answers, state, approvals, tasks	Parent and child requests for bundles
Directory profile	Job title, team, location, work phone, photo, availability, expertise	Visible only for published fields

The states each object moves through are described in Lifecycles and processes.

Integrations with other modules

Service desk. Issues and requests raised in the portal land in the service desk queues; agent replies marked public appear in the employee's conversation. See Service desk and Service requests and the catalog.
Knowledge. While you describe an issue, TENSOR suggests matching articles; the knowledge base and guides are linked from Services.
CMDB. My assets lists the devices, services and licences assigned to you; Report issue and Request service on an asset pre-fill the affected item. See CMDB.
Change. Employees can propose a change; change managers accept it (creating a draft change) or decline it with a reason. See Changes.
Notifications. Updates on your issues and requests, new announcements and asset notices arrive in-app and by email; compliance notifications cannot be muted. See Notifications.
Chat tools. Approvers can decide service requests from approval cards in Slack or Microsoft Teams when that option is switched on.
Directory sync. User and organisation data can be taken over from Active Directory or Entra ID through WorkOS Directory Sync. Importing people is separate from publishing them; see Directory Sync — ingest is not publish.

Automation and background jobs

Scheduled publishing and expiry. Publications, banners and polls go live and expire at the times set by the editor. Failed releases appear in the portal manager with a retry option.
Catalog order fulfilment. Each ordered catalog item becomes exactly one service request, created by a background job; retries never create duplicates.
Directory sync. An initial bulk load, near-real-time updates and a scheduled full reconciliation. A user deactivated in the company directory loses access and disappears from the published directory.
Notifications. The action badge counts only items that need you, never passive information. On the current release the You badge counts mandatory acknowledgements; counting approvals and replies awaiting you is planned — not yet available.

Feature flags

Flag	Switches on
`portal_intranet`	The intranet home with sections and the employee navigation.
`tenant_publications`	Publications and the news feed.
`publication_acknowledgements`	Mandatory acknowledgements and receipts (sticky after the first receipt).
`portal_events`, `portal_polls`, `portal_banners`	Events, polls and push banners (`portal_banners` becomes sticky with the first banner receipt).
`portal_quick_launch`	Quick links.
`portal_authoring`	The in-app home layout editor.
`portal_projects`	The project portfolio.
`tenant_directory`	The people directory (also requires the works-council acknowledgement).
`tenant_directory_sync`	Import of users and organisation data from the company directory.
`request_bundles`	Catalog bundles (one order, several requests).
`change_portal_proposals`	Request a change in the portal.
`live_chat`	Live chat with the service desk.
`approval_delegation`, `chat_inline_approvals`	Approval delegation beyond single change seats; approval cards in Slack or Teams.
`gdpr_enhanced_data_export`	Self-service download of your personal data.
`betrvg_works_council_view`	The pseudonymised works council view.
`product_analytics`	Opt-in, anonymous usage analytics and the in-product feedback card.

All of these are off for a new tenant and are switched on under Workspace settings → Regulatory features. When a flag is off, the matching pages, sections and menu entries are not shown at all.

Sticky flags can only be switched off with a reason and a second approver. Why regulatory toggles are sticky explains the reasoning; the toggle catalog lists every flag. For the feedback card behind product_analytics, see In-product feedback surveys.

Data protection

Every column that can hold personal data is classified at schema level (for example identifying, contact, free text).
Audience and publication state are enforced by the server. Drafts, future or expired items, content for other audiences and other tenants are never sent to the browser, so nothing can be revealed by inspecting the page.
Directory fields leave the server only if the administrator has published them. Importing users from the company directory does not publish anything.
Anonymous polls store answers without a user ID; a separate token only records that you voted, never what.
Usage events and analytics are free of personal data: they never contain search text, poll answers, publication titles or the person you looked up.
The portal uses only strictly necessary session cookies; no analytics or marketing tags load by default.

Audit trail

Every publish, retire, acknowledgement, poll opening and closing, banner change, layout change, link change, directory setting change, directory sync run and profile override writes exactly one entry in the audit log, in the same transaction as the change.

The audit log is append-only and hash-chained per tenant, and a daily check verifies the chain. Acknowledgement receipts have no update or delete right at database level and survive the archiving of their publication.

Technical detail for IT administrators

Stable URLs. The portal routes live in a dedicated route group and URLs are stable. Older paths redirect: for example /portal/requests redirects to /portal/services, and /portal/directory to /portal/people.
Independent sections. Each home section loads independently with a three-second timeout; a failing section shows its own error and retry without affecting the others.
Conflict protection. Content edits in the portal manager are protected by an optimistic version check: if another editor saved first, you get a conflict and can reload the current version.
Featured stories limit. At most three featured stories can be active at the same time; the database enforces the limit.
Token-only branding. Branding is limited to tokens (name, logo, accent colour, default theme); there is no way to inject CSS, HTML or scripts. The server enforces a minimum colour contrast. See Publish company branding.
Directory sync keys. Directory sync keys users on the identity provider's external ID. Synced fields are read-only in TENSOR; locally maintained fields can be pinned so the next sync does not overwrite them.

How the employee portal works