Administer workspaces and organizations

Administration defines who controls a workspace, who can read or change it, and how it moves through its lifecycle. Use organization controls for organization-wide responsibilities and workspace settings for each knowledge boundary.

Separate administration scopes

• Account: profile, personal tokens, personal subscription, and user lifecycle.
• Organization: organization members, roles, billing context, Hosted Zones, and organization-owned controls.
• Workspace: content boundary, visibility, members, fragment types, notifications, webhooks, and workspace lifecycle.
• Application: application administrators, consent, credentials, and install access.

A workspace owner is not automatically a platform administrator. An organization member is not automatically a collaborator in every workspace.

Maintain ownership

Every production workspace should have an accountable owner and at least one documented recovery path. Keep owner access limited but avoid relying on an unavailable individual.

Review ownership when:

• a maintainer changes role or leaves;
• the workspace becomes public;
• billing ownership changes;
• a critical integration is added;
• the workspace is moved to a Hosted Zone;
• the workspace is prepared for archival.

Manage members and invitations

1. Open the workspace.
2. Go to Settings and the members/access area.
3. Review current members and pending invitations.
4. Invite by email only after confirming the intended workspace.
5. Choose the lowest suitable role.
6. Resend, revoke, update, or remove access when responsibilities change.

Typical roles:

• Owner: full workspace management.
• Collaborator: create and maintain content.
• Contributor: contribute with less management authority where exposed.
• Viewer: read-only workspace member.
• Subscriber: read-style access to a public workspace.

Invitation emails and notifications can expose workspace and organization names. Do not paste recipient addresses, raw invitation IDs, or tokens into public support threads.

Configure workspace settings

Document changes to:

• name and description;
• visibility and access scope;
• fragment types;
• member roles;
• notification rules;
• webhooks and integrations;
• auto-link rules;
• Hosted Zone placement where selected at creation.

Test settings with a representative lower-privilege account. Client-side hidden controls are not proof of server-side access.

Change visibility safely

Before making a workspace public:

1. review all fragments and statuses;
2. inspect tags, summaries, files, screenshots, and collection descriptions;
3. inspect webhooks, apps, and symlink rules;
4. remove private links and customer data;
5. test subscriber access;
6. assign a publication owner;
7. plan ongoing review.

A public workspace remains permission-controlled: subscription provides read-style access and does not grant authoring.

Organization administration

Organization owners/admins can manage organization-level surfaces exposed to their role, including membership, billing context, and Hosted Zones for eligible organizations.

Keep organization member roles distinct from ordinary workspace membership. Adding an organization member can affect billing and does not remove the need to grant appropriate workspace access.

Platform-admin organization invitation controls are separate from ordinary workspace invitations. Do not document admin-only routes as general user APIs.

Archive or delete deliberately

Before archiving or deleting a fragment or workspace:

• identify owners and dependent users;
• review collections, links, files, symlinks, webhooks, and applications;
• export content if policy requires it;
• disable external integrations;
• decide whether historical context requires archival;
• record the decision without sensitive data.

Prefer archive when knowledge may be needed for history. Deletion and retention behavior must follow current product controls, legal policy, and organization requirements.

Leaving a workspace does not necessarily remove content you previously contributed. Transfer or clean up responsibility before leaving.

Administrative review checklist

Review periodically:

• owners and privileged roles;
• stale invitations and inactive members;
• public visibility;
• tokens and applications;
• notification recipients;
• webhook targets;
• auto-link destinations;
• Hosted Zone health and keys;
• billing owner and current plan;
• abandoned workspaces.

Troubleshooting

I can read but cannot manage settings

Your role is read-only or content-focused. Ask an owner to perform the action or grant the minimum appropriate role.

A member cannot see the workspace

Confirm account identity, invitation acceptance, workspace membership, organization context, and whether the workspace is archived or still processing.

An invitation email did not arrive

Check pending invitation state, spelling, expiry, and email delivery. Resend or revoke/recreate where appropriate without sharing the invitation token.

An organization setting is missing

The control may require an owner/admin role or a particular plan. Confirm the effective organization role and tier.

Related pages

• Workspace members and invitations
• Workspace roles and permissions
• Organizations and membership
• Publish and share knowledge safely
• Operate Hosted Zones and Leaf workspaces