Teams & Collaboration

DocPlatform is designed for team documentation. Invite members, assign granular roles, and track every change with a full audit trail.

Workspace membership

Every user belongs to one or more workspaces with a specific role. Roles determine what actions a user can perform.

Invite members

Via web UI:

1. Open Workspace Settings → Members
2. Click Invite Member
3. Enter the person’s email address
4. Select a role
5. Click Send

If SMTP is configured, an invitation email is sent with a unique link. Without SMTP, the invitation link is displayed on screen — copy and share it manually.

Via API:

curl -X POST http://localhost:3000/api/v1/workspaces/{workspace-id}/invitations \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "colleague@example.com",
    "role": "editor"
  }'

Remove members

Admins can remove members from Settings → Members → click the user → Remove.

Removing a member revokes their access immediately. Their past edits and audit log entries are preserved.

Change roles

Click a member’s current role to change it. Role changes take effect immediately — active sessions are updated on the next API call.

Roles

DocPlatform uses a 5-level role hierarchy. Higher roles inherit all permissions of lower roles.

Super Admin
    └── Admin
            └── Editor
                  └── Commenter
                        └── Viewer

Default role for new members

Configure the default role assigned when users accept an invitation:

# .docplatform/config.yaml
permissions:
  default_role: viewer

Page-level access

Restrict individual pages to specific roles using frontmatter access rules:

---
title: Internal Runbook
access:
  read: ["sre-team", "admin"]
  write: ["sre-team"]
---

Pages with access rules are invisible to users without the required role — they won’t appear in search results, navigation, or published docs. Access rules can only restrict within a user’s role, never grant beyond it.

Real-time presence

When multiple users are active in the same workspace, the web editor shows who’s online:

• Sidebar indicators — colored dots next to pages being viewed or edited by other users
• Avatar stack — user avatars in the page header showing who else is viewing the current page

Presence is powered by WebSocket connections and updates in real time.

How presence works

The WebSocket connection also delivers real-time content events:

Concurrent editing

DocPlatform does not support real-time collaborative editing (Google Docs-style). If two users edit the same page simultaneously:

1. The first save succeeds
2. The second save triggers a conflict detection (HTTP 409)
3. Both versions are preserved for manual resolution

To avoid conflicts:

• Use page-level ownership conventions (one writer per page at a time)
• Presence indicators help your team coordinate who’s editing what
• For high-concurrency teams, consider shorter git sync intervals

Audit trail

Every content mutation is logged with:

Viewing the audit log

Access the audit log from Workspace Settings → Activity.

Filter by:

• User — see all changes by a specific team member
• Page — see the full history of a specific page
• Date range — narrow to a time window
• Operation type — filter to creates, updates, deletes, etc.

Audit action types

The action field in the audit log uses dot-notation for precise filtering:

Retention

Audit logs are stored in SQLite alongside your regular data. They’re included in daily backups. Audit logs are retained indefinitely.

Email notifications

With SMTP configured, DocPlatform sends transactional emails for:

DocPlatform does not send notification emails for content changes. Real-time WebSocket updates serve that purpose for active users, and the audit log covers historical review.

SMTP configuration

export SMTP_HOST=smtp.example.com
export SMTP_PORT=587
export SMTP_FROM=docs@yourcompany.com
export SMTP_USERNAME=docs@yourcompany.com
export SMTP_PASSWORD=your-app-password

Without SMTP, invitation links and password reset tokens are printed to stdout (server logs).

Tips for team workflows

• One writer per page — use presence indicators to avoid conflicts
• Editors write, Admins publish — separate concerns with roles
• Use tags for ownership — tag pages with owner:jane to clarify responsibility
• Git for review workflows — push changes to a branch, open a PR, merge after review
• Audit before publish — review the audit log for unexpected changes before making content public