Spaces & Permissions

Spaces organize documents — one per team, product, or topic. By default every space is internal: anyone who can sign in can browse, search, and read it. A space can instead be private — visible only to admins and the groups you grant — or, since 0.14, public: served to anyone on the internet via the read-only public site.

Space visibility applies everywhere a document can surface: the sidebar and dashboard, space and document pages, full-text search, the AI answer (“Ask CompassDocs”), the REST API, and the Claude connector. A user who isn’t granted access gets a 404 — private spaces don’t leak even their names.

Choosing a visibility

Manage visibility in Settings → Spaces — create a new space or Edit an existing one. (While you’re there: every space has a searchable icon picker — type “security” or “training” — plus a color that tints its cards and sidebar entry.) Then pick under Who can see it:

• Internal — everyone signed in. The default; existing spaces land here when you upgrade — nothing changes until you say so.
• Private — selected groups only. Members of the granted groups (plus all admins) see the space. Everyone else doesn’t — it disappears from their sidebar, search, and AI answers.
• Public — anyone, no sign-in. Published documents are served on the anonymous public site (once its master switch is on). Use it for customer-facing docs.

A few rules worth knowing:

• Administrators always see every space, private or not — that’s the space.read_all permission, which the Admin preset holds. A custom role can be given it deliberately, and the access explainer will name it as the reason.
• A private space with no groups granted is visible to admins only — handy while you stage content before opening it up.
• Moving a space out of the private tier clears its group grants, so a later flip back to private starts from an explicit empty grant list.
• Permissions still apply on top: being able to see a space isn’t being able to write in it. Someone in a granted group reads it; authoring needs edit rights, and publishing needs document.publish. The approval workflow is unchanged.

Categories within a space

Larger spaces can group their documents into categories — sections like “Runbooks” or “Architecture” that structure the space page. Manage them while editing a space (Settings → Spaces → Edit → Categories): add, rename, reorder, or delete (deleting one moves its documents back to General). Writers pick a category in the document editor; moving a document to another space clears its category. The space page also gets a search box scoped to that space, so readers can search within it without leaving.

Space views

Every space page has a view switcher (top right of the document list):

• Cards — the classic grid, grouped by category. From 0.77 the sections pack with masonry: cards fill the columns instead of leaving gaps, and a card’s sub-page list caps at 4 rows — the rest (counting the whole nested subtree) folds behind an “N more sub-pages…” link that expands in place.
• Table — a compact sortable table (title, type, status, category, author, updated), with an alarm icon on documents whose content review is overdue.
• Tree — a collapsible outline of the space’s page hierarchy. Appears when nested pages are enabled.
• Board — columns by status (drafts / published / review overdue) or by document type; toggle the grouping at the top of the board.
• Timeline — documents bucketed by freshness (this week / month / quarter / older), with overdue reviews called out on top.
• By tag — one section per tag, plus an Untagged section.

Each person’s choice is remembered per space on their browser. Admins set the view a space opens with under Settings → Spaces → edit space → Default view.

Groups

Groups live in Settings → Groups. A group is just a named set of users that can be granted on any number of private spaces.

• Create a group, then open Members to add or remove users.
• Deleting a group revokes whatever access it granted (the confirm dialog warns you if it’s in use).
• Everything is audited: group create/rename/delete, member changes, and space visibility changes all land in the audit log.

Syncing groups from Microsoft Entra

Enterprise feature — requires the enterprise image and a license with Microsoft 365 directory sync. See Enterprise edition.

If you already manage security groups in Microsoft 365, you don’t have to rebuild them by hand. The Microsoft Entra groups panel at the bottom of Settings → Groups can import them:

1. Connect Microsoft 365 under Settings → Directory first — group sync reuses the same app registration. (It needs the GroupMember.Read.All application permission, which the one-click setup grants automatically.)
2. Click Browse groups, tick the groups you want, and Import.
3. Grant the imported groups on private spaces exactly like manual ones.

Imported groups show an Entra · synced badge. Their membership is mirrored from the tenant:

• Sync now re-pulls membership (and picks up group renames) for every imported group.
• Members are matched to CompassDocs accounts by their SSO identity first, then by email address. Tenant users without a CompassDocs account are skipped — they’re picked up automatically on a later sync once they’ve signed in via single sign-on.
• Manual member edits to a synced group are allowed but overwritten by the next sync — use a manual group if you want hand-picked membership.
• Removing someone from the group in Entra removes their space access on the next sync.

How access is decided

For each signed-in user, CompassDocs resolves the set of spaces they may see:

visible spaces = all internal and public spaces
               + private spaces granted to any group the user belongs to
               (admins: every space)

That scope is applied server-side to every read path — page rendering, search queries, AI retrieval, document APIs, attachments, and the Claude connector — and to every write path (you can’t create, edit, or delete a document in a space you can’t see).

Who can edit a space

Visibility controls who can read; edit rights control who can author — create, edit, move, or trash documents and manage attachments. Only admins can change either.

By default the org-wide switch “All editors can edit all spaces” (top of Settings → Spaces) is on, and anyone with the editor role can author in every space they can see. Turn it off and each space’s “Who can edit” setting applies:

• All editors (default per space) — unchanged behavior.
• Only selected people or groups — pick individual accounts and/or groups (manual or Entra-synced). Only they can author in the space; everyone else with view access can still read and suggest edits.

A few rules to keep in mind:

• The role is still the floor: someone granted on a space also needs the editor role (or higher) to author anywhere.
• Admins always have edit access and are the only ones who can grant it.
• Approvers still review and approve queued changes for any space they can see — but authoring directly in a restricted space requires a grant like anyone else.
• Enforcement is server-side across the app, the APIs, and the Claude connector: the Edit button disappears, restricted spaces drop out of the new-document and move-to-space pickers, and direct API calls get 403.

Where these grants live

Since 0.99 both kinds of per-space grant — read access on a private space, and edit rights on any space — are ordinary role assignments scoped to the space, using the seeded Space member and Space author roles. These screens work exactly as before; the difference is that a grant made here now shows up in Roles & permissions, in Explain access, and in the audit log. Existing grants moved across automatically when you upgraded.