SSO & Identity¶
This page describes how sign-in, tenancy, and access control work across WorkDone products, and what your IT team needs to know to manage users.
Invitation-Only Provisioning¶
There is no self-signup on any WorkDone product. Every account is created by invitation:
- Your organization's designated administrators (or your WorkDone implementation contact, during onboarding) invite users by email address.
- Invited users receive an email and complete sign-up against your organization only.
- Anyone not invited (including someone who discovers the portal URL) cannot create an account or see that your organization exists.
This keeps your user list a deliberate, auditable set rather than an open door.
Organization-Scoped Tenancy¶
Every WorkDone customer is a separate organization tenant:
- All data (documents, knowledge base content, part data, analytics) is partitioned by organization, and every request is evaluated against the signed-in user's organization.
- Users belong to your organization and see only your organization's data. There is no cross-tenant visibility of any kind.
- Integrations (SharePoint, Google Drive, your business systems, Teramind) all land their data inside your tenant boundary.
Roles in Corporate Memory¶
Corporate Memory uses four roles, assigned per user by your administrators:
| Role | Intended for | Typical access |
|---|---|---|
| Admin | IT and platform owners | Everything, including the admin console, organization settings, user management, update tracking, and approval queues |
| Management | Leadership and managers | Analytics and oversight views (Vision Dashboard, Copilot usage) in addition to standard features |
| Automation | Workflow operators | The automation workflows configured for your operation: review/approval queues and related data views |
| Member | Everyone else | Copilot and the standard knowledge-base experience |
Role checks are enforced server-side on every request: the portal does not merely hide menu items; the backend rejects actions the user's role does not permit.
Least privilege applies to people too
Give most users Member, grant Automation and Management only to those who work in those areas, and keep the Admin list short. Roles can be changed at any time by your administrators.
Session Security¶
- HttpOnly session cookies. Sessions are carried in HttpOnly cookies, which cannot be read by page scripts, mitigating token theft via cross-site scripting.
- HTTPS everywhere. All WorkDone portals are served exclusively over HTTPS; session cookies are never sent over unencrypted connections.
- Server-side enforcement. Identity, organization, and role are established server-side on every request; clients cannot elevate their own privileges.
- Sessions expire and require re-authentication per WorkDone's session policy.
Managing Users¶
- Additions. Organization admins can invite users directly from the portal's admin console; alternatively, send the user's email address and intended role to your WorkDone implementation contact.
- Role changes. Performed by your organization admins, or on request through your implementation contact.
- Removals. Remove the user in the admin console (or request removal via support). Removal ends the user's access to your tenant; treat it as part of your leaver process alongside your own directory offboarding.
- Access reviews. Your admins can view the current member list and roles at any time; this is worth folding into your periodic access-review cycle.
Enterprise SSO¶
If your organization requires federation with your identity provider (for example SAML or OIDC single sign-on from Entra ID or Google Workspace), enterprise SSO options can be discussed with support or your WorkDone implementation contact. Invitation-only provisioning and organization-scoped tenancy apply regardless of the sign-in method.