Who uses the platform, and the roles that govern what they can do. Because DWPlatform is a multi-tenant SaaS, “stakeholder” splits into two layers: the SaaS layer (the operator and the customer organizations) and the tenant layer (the people inside a customer who do office work).
| Stakeholder | Who they are | What they do |
|---|---|---|
| Platform Operator / Super-Admin | The company running DWPlatform | Runs the Platform Console: creates tenants, assigns plans, provisions databases, manages the catalog, monitors usage/billing. Implicitly Admin of every service. |
| Tenant (organization) | A subscribing customer org | The billing & isolation boundary — owns its brand, users, data, plan and entitlements. |
| Tenant Owner / Admin | The customer’s own administrator | Self-service admin of their tenant: branding, module enablement, subscription/seats, and — via the seat-aware path — creating users and assigning roles. |
| Billing / Account contact | The tenant’s finance/owner contact | Views plan, subscription lifecycle, add-ons, billing events, storage usage. |
| Stakeholder | What they do | Primary modules |
|---|---|---|
| End User / Employee | Everyday work: email, chat, files, meetings, tasks, news, phone lookup, requests, KPI entry | Shell + all entitled modules |
| Department Manager | Oversees a department; approves requests routed to them; department calendar & tasks | WorkFlow, KPIS, Calendar, HR (read) |
| Supervisor | Oversight without full admin — reviews/monitors within scope | Cross-module |
| HR / Organization Admin | Maintains people registry & org structure: persons, departments, jobs, ranks, telephones | HR / Organization |
| Correspondence Receive Desk | Registers incoming official correspondence and routes it | DWMail |
| Correspondence Review Desk | Reviews & approves correspondence | DWMail |
| Correspondence Secretary Desk | Final processing, signing/stamping, archiving | DWMail |
| Approver / Signer | Approves workflow requests or signs correspondence (holds an e-signature) | WorkFlow, DWMail |
| Meeting Organizer | Schedules, runs, records meetings; shares recordings | Meetings |
| News Publisher / Editor | Writes and publishes internal news | News |
| KPI Auditor / Owner | Owns activities/indicators, enters measurements, reports | KPIS |
| Content Contributor | Uploads/shares files, comments, @mentions | Drive, Collaboration Hub |
A backend service calling another with a system JWT (e.g. WorkFlow pushing an approval to the Hub). Runs with elevated, tenant-scoped, deny-by-default access.
Modules publishing notifications, work-item changes and index events; the Hub consuming them. Every event carries the tenant id.
Ingests/relays real email into the correspondence backend (DWMail’s own mail server).
The Drive desktop sync client and the Windows tray notifier — authenticated deliverables that talk to the backends.
DWPlatform does not use one flat role list. Understanding the mechanics is essential for QC:
Broad labels such as
Admin, User, Manager. A user can hold one or more.
The real unit is a
triple (User × Role × Service). Someone can be Admin in Identity but only
User in KPIS.
On login the
token carries role:DWPlatform.KPIS=Admin-style claims; every module authorizes off its own
claim.
A platform
Super-Admin is treated as Admin for every service, even without an explicit per-service row.
Separate from service roles — it records a user’s standing inside a tenant (Owner / Admin / User).
401 = not signed in.
403 = signed in, but lacks the required role:{Service}=… claim.
| Role | Grants | Where it matters |
|---|---|---|
| Admin | Full access to all features | Every module |
| User | Regular user, limited access | Every module |
| Manager | Department-level features | WorkFlow, KPIS, HR, Calendar |
| Supervisor | Oversight capabilities | Cross-module |
| HRAdmin | Elevated HR privileges | HR / Organization |
| Role | Grants |
|---|---|
| ReceiveDesk | Handles incoming correspondence (registration & routing) |
| ReviewDesk | Reviews and approves correspondence |
| SecretaryDesk | Final processing & archiving (sign / stamp) |
| Role | Grants |
|---|---|
| CalendarAdmin / CalendarManager | Calendar administration / department-level calendar access |
role:DWPlatform.News=Admin | ContentManagement | News authoring — full admin vs content only |
role:DWPlatform.Media=Admin | Drive administration (quotas, quarantine, templates) |
| Drive item roles: Viewer / Downloader / Editor | Per-file access: view-only / download / full edit |
KPIS Auditor / IsKpiAdmin | Owns/edits activities & enters values / manages all activities |
| Role | Grants |
|---|---|
| SuperAdmin / Platform Operator | Runs the SaaS across all tenants; implicitly Admin everywhere |
| Tenant Owner / Admin | Self-service admin of one tenant |
There are two separate role systems, set in two different places by two different authorities. Knowing which is which is the whole game:
A single value per
user inside a tenant — TenantAdmin or User (the Owner is a locked TenantAdmin).
It’s the seat: creating a user or promoting to admin consumes a plan seat.
The real capability unit —
a (user × role × service) row that becomes a role:DWPlatform.{Service}=Role claim in the
token. This is what each module authorizes against. Not seat-limited.
| Action | Who can do it | Enforced by |
|---|---|---|
| Create a user + set their tenant role; change a user’s tenant role (Member ↔ Admin); remove a user | Tenant Admin of that tenant, or a platform SuperAdmin | policy RequireTenantAdmin (claim tenant_role=TenantAdmin or is_superadmin=true). Seat-capped — returns 409 at the plan’s user/admin limit. |
Assign / revoke a service role (e.g. give someone ReceiveDesk on DWMail) | A user with global Admin / Manager / HRAdmin, or the Identity-Admin service role (role:DWPlatform.Identity=Admin); SuperAdmin passes implicitly | policy RequireManagerOrAdmin. Not seat-capped and does not require the module be entitled. |
| Create a brand-new role name (for roles not in the seeded catalogue) | Same as above (RequireManagerOrAdmin) | POST /api/v1/roles. Roles are free-form; the catalogue below is just what’s seeded. |
User & role administration lives in the IAM app (DWPlatform.Identity.FE — the “Identity /
Users” area of the shell admin). Two screens:
| Goal | Steps |
|---|---|
| Add a new user | Identity → Users → Add user → email (+ optional password/username) and pick Member or Admin → Save. Blocked with a “seat cap reached” message if the plan is full. |
| Make someone a tenant admin (or demote) | Identity → Users → the user’s row → Change role → choose Admin (TenantAdmin) / Member (User) → Confirm. (The Owner can’t be demoted; the last admin can’t be removed.) |
| Grant a capability (service) role | Identity → Users → open the user (User detail) → Roles card → Add → pick the Service (e.g. DWMail/Correspondence) → pick the Role (e.g. ReceiveDesk) → Assign. Revoke with the trash icon next to the role. The user must sign out & back in for the new claim to take effect. |
Assign these as service roles on the named service unless noted. “Any employee” means no role is needed beyond being a tenant member.
| To make someone a… | Assign | On service |
|---|---|---|
| Everyday employee | — (tenant Member only) | — |
| Tenant administrator | Tenant role Admin (Users → Change role) | tenant membership |
| Correspondence Receive Desk | ReceiveDesk | DWMail / Correspondence |
| Correspondence Review Desk | ReviewDesk | DWMail / Correspondence |
| Correspondence Secretary Desk (sign/stamp/archive) | SecretaryDesk + an uploaded e-signature (Settings → Signatures) | DWMail / Correspondence |
| Mail manager / office manager (manage others’ items) | Admin or Manager (mail) / OfficeManager* | DWMail / Correspondence |
| External-send office (send outside the org) | ExternalSendingOffice* or Director* — or simply Admin | DWMail / Correspondence |
| HR / Organization admin | HRAdmin | HR / Identity |
| Calendar admin / manager | CalendarAdmin / CalendarManager | Calendar |
| News publisher | Admin or ContentManagement | News |
| Drive admin (quotas, quarantine) | Admin | Media |
| KPI auditor / admin | Auditor* / Admin | KPIS |
| Module super-user (one module) | Admin | that module |
ExternalSendingOffice, Director,
OfficeManager, Auditor) don’t exist until an Identity-Admin creates the role name
once (POST /api/v1/roles, or the “new role” action in the IAM app) and then assigns it to the service.
The seeded roles are Admin, User, Manager, Supervisor, HRAdmin, ReceiveDesk, ReviewDesk, SecretaryDesk,
CalendarAdmin, CalendarManager. For external send specifically, granting Admin on DWMail (or being a
SuperAdmin) already works with no custom role — see the Email guide §12.● full/primary · ◐ partial/scoped · ○ minimal or self-only. Module visibility still depends on tenant entitlements.
| Role | Identity | HR | Shell /admin | DWMail | WorkFlow | KPIS | Chat | Meet | Drive | News |
|---|---|---|---|---|---|---|---|---|---|---|
| SuperAdmin | ● | ● | ● Console | ● | ● | ● | ● | ● | ● | ● |
| Tenant Admin | ◐ | ◐ | ● tenant | ◐ | ◐ | ◐ | ◐ | ◐ | ◐ | ◐ |
| Admin | ● | ● | ◐ | ● | ● | ● | ● | ● | ● | ● |
| Manager | ○ | ◐ | ○ | ◐ | ● approve | ● dept | ● | ● | ● | ○ |
| HRAdmin | ○ | ● | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| Correspondence desks | ○ | ○ | ○ | ● desk flow | ○ | ○ | ○ | ○ | ○ | ○ |
| User (employee) | ○ self | ○ view | ○ | ● mailbox | ● request | ● contribute | ● | ● | ● | ● read |