Visibility & Sharing

The Docs module uses a visibility system to control who can see each book and its contents. This guide explains the four visibility levels, how they interact with page status, and how to publish content to different audiences.

Visibility Levels

Every book is assigned one of four visibility levels:

Personal

• Who can see it: Only the book owner (the user who created it, or was assigned ownership).

• Use case: Personal notes, private drafts, individual reference material.

• Portal access: No. Personal books are never visible in the portal.

• Public access: No. Personal books are never publicly accessible.

Personal books have an owner_user_id set to the owning user. Other team members, including administrators, cannot see personal books in the Docs grid.

Internal

• Who can see it: All team members in your tenant.

• Use case: Internal documentation, team processes, company policies, training materials.

• Portal access: No. Internal books are not visible in the portal.

• Public access: No. Internal books are not publicly accessible.

This is the appropriate visibility for documentation that your team needs but clients should not see.

Portal

• Who can see it: All team members, plus authenticated portal contacts.

• Use case: Client-facing documentation, FAQs, how-to guides, product manuals that you want to share with your clients through the portal.

• Portal access: Yes. Portal contacts see the book in their Docs section.

• Public access: No. The book requires portal authentication.

Public

• Who can see it: Everyone, team members, portal contacts, and unauthenticated public visitors.

• Use case: Public knowledge base, help center, API documentation, open-source project docs.

• Portal access: Yes. Portal contacts see the book in their Docs section.

• Public access: Yes. No authentication required.

Visibility Comparison

How Visibility and Page Status Interact

Visibility controls who can see the book. Page status controls which pages are visible to non-team audiences:

The key rule: draft pages are always hidden from portal and public views, regardless of the book's visibility. This lets you work on new pages within a portal or public book without exposing unfinished content.

Setting Book Visibility

When Creating a Book

1. Click New Book on the Docs page.

2. In the Visibility dropdown, select Personal, Internal, Portal, or Public.

3. Complete the other fields and click Create.

Changing an Existing Book's Visibility

1. Open the book workspace.

2. Click the book settings or edit action.

3. Change the Visibility dropdown.

4. Click Save.

Visibility Change Side Effects

• Personal to Internal/Portal/Public: The owner is cleared. The book becomes visible to your team (and portal/public as applicable).

• Internal to Portal: Portal contacts gain access to published pages immediately.

• Internal to Public: Both portal contacts and public visitors gain access to published pages.

• Portal/Public to Internal: Portal contacts and public visitors lose access immediately. Any bookmarked or linked URLs will return errors for non-team users.

• Any to Personal: You become the owner. All other team members, portal contacts, and public visitors lose access.

Publishing Pages for Portal and Public Access

Making a page visible to portal contacts or the public is a two-step process:

1. Set the book's visibility to Portal or Public.

2. Set the page's status to Published.

Both conditions must be met. A published page in an internal book is still invisible to portal contacts. A draft page in a portal book is still invisible to portal contacts.

Publishing Workflow

A recommended workflow for publishing content to the portal:

1. Create the book with Internal visibility while you are drafting content.

2. Create pages and write the content. Leave pages in Draft status.

3. Review the content with your team.

4. Set pages to Published status as they are ready.

5. Change the book's visibility to Portal (or Public) to make it accessible.

Alternatively, you can set the book to Portal/Public visibility from the start and use draft status to control which pages are live:

1. Create the book with Portal visibility.

2. Create pages as drafts. Portal contacts cannot see drafts.

3. When a page is ready, change its status to Published. It becomes visible in the portal immediately.

What Portal Contacts See

When portal contacts access the Docs section:

Books Index

• Only books with Portal or Public visibility are listed.

• Each book shows its name, description, icon, and the count of published pages.

• Books with zero published pages still appear in the list but will show an empty state when opened.

Book Detail

• The sidebar navigation tree shows only published pages.

• Chapters that contain no published pages are hidden entirely.

• The first published page (by sort order) loads automatically when the book is opened.

Page View

• The page title, rendered content, and last-updated date are displayed.

• Pages are read-only. Portal contacts cannot edit content.

• The page excerpt is not prominently displayed but may appear in search results.

What Public Visitors See

Public books follow the same rules as portal visibility, with the additional trait that no authentication is required:

• Public books and their published pages are accessible to anyone with the URL.

• Draft pages remain hidden.

• Empty chapters are hidden.

Controlling Who Sees What. Practical Examples

Scenario: Internal SOPs

You want to document standard operating procedures for your team only.

• Create a book with Internal visibility.

• Add chapters and pages as needed.

• Published or draft status does not matter for team visibility, your team sees all pages.

• Portal contacts and the public cannot access the book at any point.

Scenario: Client Knowledge Base

You want to publish a FAQ and how-to guide for your clients.

• Create a book with Portal visibility.

• Create pages for each FAQ topic or guide section.

• Set pages to Published as they are ready.

• Portal contacts see only published pages.

• Draft pages are your workspace for upcoming content.

Scenario: Public Help Center

You want a publicly accessible help center.

• Create a book with Public visibility.

• Organize content into chapters (e.g., "Getting Started", "Billing", "Troubleshooting").

• Publish pages as they are reviewed and approved.

• Anyone can access the help center without logging in.

• Use draft status to stage upcoming articles without exposing them.

Scenario: Personal Notes

You want a private notebook for your own reference.

• Create a book with Personal visibility.

• No one else can see it, not even administrators.

• Use it for scratch notes, meeting prep, or personal task tracking.

Transitioning Between Visibility Levels

You can change a book's visibility at any time. Common transitions:

Security Considerations

• Draft pages as a safety net: Use draft status to stage content in portal/public books. Drafts are never exposed to non-team audiences.

• Visibility changes are immediate: There is no "publish" step for visibility changes. Changing a book from internal to portal makes all published pages instantly visible to portal contacts.

• Personal books are truly private: Even administrators cannot browse other users' personal books.

• Soft deletion: Deleted books, chapters, and pages are soft-deleted. They are not accessible after deletion, but the data is retained briefly before permanent purge.