Teams, Workspaces, and RBAC
Overview
TokenTimer supports organizations through Workspaces and role-based access control (RBAC). Workspaces isolate tokens, alert preferences, and audit events. RBAC defines who can manage or view them.
Roles and Permissions
- Admin: full control; create/rename/delete workspaces and tokens, manage members, update preferences, view audit (org + workspace), and access System Settings.
- Workspace Manager: manage members (except admins), create/update/delete tokens, and update preferences within assigned workspaces; view workspace audit.
- Viewer: view tokens in assigned workspaces.
Practical guidance: grant Viewer to most teammates or auditors, Manager to service owners who renew assets, and Admin to a minimal set of security owners.
Role changes are admin-only. Workspace managers can invite/remove members but cannot change admin roles.
Permission boundaries
- System Settings is admin-only. Workspace managers cannot access system-wide configuration.
Pending invitations
When you invite a teammate who does not yet have a TokenTimer account, we create a pending invitation. The invitation stays pending until the invitee signs up and accepts, or an admin or workspace manager cancels it from the workspace settings.
On the Workspaces page, under the members table, any admin or workspace manager can see the list of pending invitations and click "Cancel invite".
Cancelling a pending invitation deletes the row and writes an INVITATION_CANCELLED audit event. It never affects invitations that have already been accepted. The invitation token is treated as a bearer secret and is never returned by the list endpoint.
Invitations clear automatically when the invitee accepts them. If you do not see an expected pending invitation, it has likely already been accepted or cancelled.
Practical guidance: Workspaces vs Sections
Choose the right boundary to keep ownership and notifications clean and predictable.
- Create a new workspace when you need:
- Isolated workspaces and notifications (e.g. different default contact points).
- Separate audit and membership boundaries (e.g. different customers).
- Create a new section when you need:
- Separate tokens by teams, products, or environments inside the same workspace.
- Different contact groups per section.
Transferring tokens between workspaces
Move tokens from one workspace to another without re-creating them. This keeps alert settings and history attributed to the correct workspace going forward.
- Where: open Workspaces, pick a workspace, then click Transfer tokens.
- Who: Admins; Workspace Managers may transfer if they are attributed to two or more workspaces.
- Scope: available in TokenTimer Core; access is role-based.
How To
- In the Workspace section, click on "Transfer tokens", select the source and destination workspaces.
- Use the search, category, or section filters to narrow the list.
- Select individual tokens or select all filtered tokens, then click Transfer selected.
Transferring a token moves only the token row itself. If Certificate operations is enabled and the token has any CertOps history, its managed certificates, domain monitors, certificate targets, and certificate instances all stay behind in the source workspace. The destination workspace sees a token with no CertOps history, and if it later observes or monitors the same endpoint, it can create a second, separate managed-certificate record for what is really the same certificate. If a token has active CertOps inventory you care about, review and recreate that monitoring in the destination workspace after the transfer rather than assuming it followed the token.
Deleting a Workspace
Deleting a workspace removes its tokens, members, sections, invitations, and settings. Audit and delivery logs remain for history, with their workspace unlinked.
- Consider transferring tokens to another workspace beforehand if you still need alerts.
- Export data for an offline record.
This action is irreversible. Consider exporting data before deletion.
Alert Preferences are Workspace-scoped
Default thresholds and channels are configured per workspace. Recipients are managed via contact groups; a token uses its selected groups (one or more when plural writes are enabled), falling back to the workspace's default group when none are assigned. Groups can optionally define their own thresholds policy which overrides workspace defaults for that group; multi-group tokens use the union of effective thresholds.
- Use sections to route ownership (e.g., different teams) and filter dashboards.
- Changes to workspace thresholds apply to tokens without a group thresholds override.