Administer a Zentrik workspace safely

Zentrik workspace roles are:

• Owner: workspace ownership and the most sensitive workspace-level controls
• Admin: workspace settings, integrations, API keys, team administration, and product configuration
• Editor: day-to-day creation and editing in product workflows without access to workspace Settings
• Viewer: read-only workspace participation

Keep at least one active Owner. Do not use Owner as the default collaboration role. Review Admin access whenever responsibilities change.

Open Settings → People to manage access to the current workspace. If you administer several workspaces, use Switch workspace in the top-left team menu first.

For the task-by-task invitation flow, start with Invite people and manage access. This administration guide covers the wider policy and security boundary.

For new teammates:

1. Enter one or more email addresses.
2. Confirm the default Workspace role, Team, and Team role shown in the access summary.
3. Choose Change only when the batch needs a different assignment.
4. Send the invitations, then use the Invitations view to review pending delivery and the Members view to review accepted members.
5. Resend only after checking the recorded delivery state.
6. Verify that an accepted invitation shows the intended workspace role, team assignment, and joined date.

From the Members tab, Owners and Admins can search active members or pending invitations in separate views. Member rows show the workspace role, team assignments, and joined date. Invitation rows show the invitation date, delivery state, expiry, intended roles, and team. Owners and Admins can resend an invitation, copy its invite link, or revoke it after checking the delivery state. They can also change workspace roles. Use the Teams tab to change team membership. Confirm the person before a sensitive change, especially when names are similar. Use Teams and team access for the team role model.

The Settings hub groups product configuration and workspace administration:

• Discovery: evaluation, workflow, and property configuration
• Definition: requirements, documentation templates, and user-story standards
• Delivery: cycles and team capacity
• Integrations: connected evidence and delivery providers
• API Keys: credentials for MCP clients and the external API
• People → Members: workspace members, workspace roles, and invitations
• People → Teams: operational teams, team membership, and team roles
• Billing: plan, usage, and invoices when the role can manage billing
• Portal: Ideas Portal access and configuration when enabled
• Workspaces: workspace naming, switching, and defaults; only Owners can add another workspace

The options shown in Settings depend on the workspace plan and enabled capabilities.

The top-left menu shows the current team. Use Switch workspace in that menu before administering another workspace. Members and Teams always apply to the selected workspace.

Treat provider credentials and Zentrik API keys as secrets:

• create separate credentials for distinct systems or agents when practical
• name keys by purpose and owner
• grant only the scopes the workflow needs
• store secrets in an approved secret manager or environment variable
• never paste a key into documentation, chat, source control, screenshots, or support messages
• revoke credentials that are unused, exposed, or owned by a departing teammate
• confirm the active Zentrik workspace before connecting an MCP client

Use MCP setup or the REST API reference for the relevant authentication flow.

Use Settings → Billing for the workspace plan, current usage, configured limits, and invoices when your role has billing access. Use the pricing page for current published packaging.

Workspace Owners and Admins can use Settings → Workspaces to rename, declare the company email domains, and choose a default among the workspaces they administer. Declare every domain your own people send from; anyone on those domains counts as your team in imported conversations, whichever mailbox they joined from, so a colleague is never recorded as a customer. Only Owners can create an additional workspace. Use Switch workspace in the top-left team menu, then open People → Members when you need to manage its access. Separate workspaces when teams or clients require distinct access and context. Confirm authorization and downstream integrations before you move data across a workspace boundary.

Before removing a teammate:

1. Transfer ownership of important product decisions, documents, integrations, and operating routines.
2. Identify credentials, connected providers, or external automations they own.
3. Create replacement credentials where needed.
4. Revoke the person’s invitations or remove their membership.
5. Revoke or rotate affected API keys and provider credentials.
6. Verify that required integrations and scheduled imports still run.

Removing a member is not a substitute for rotating a credential they could access.

• at least one current Owner is active
• Admin access matches current responsibilities
• Editors and Viewers have the least access they need
• pending and expired invitations are reconciled
• API keys have a current purpose and owner
• integration credentials still belong to active administrators
• billing contacts and invoice access are current
• workspace boundaries match team or client access requirements
• teammates understand which capabilities are enabled for the workspace

Use Security and trust for current public assurance information. For a workspace-specific access, billing, or configuration issue, use the Still stuck? path below and include the workspace name, the screen, what you expected, and what happened.

Do not include passwords, API keys, access tokens, private customer content, or full diagnostic exports in the initial support message.