Control who can see a report page

Mark a page invisible to keep it available to report editors while excluding it from the report's viewer-facing content. Visibility applies to both native and HTML pages.

Use it for work in progress or supporting pages that editors need. It is an access control for page content, separate from presentation mode or a collapsed navigation panel.

Change page visibility

Open the report as an Owner or Admin.
Find the page in the page list.
Use its visibility control, labeled Visible to viewers or Invisible to viewers.
Wait for the change to save.
Review the report using the intended viewer permissions.

The control updates its indicator during the save and reports a failed change. Editors can see the invisible indicator, but cannot change visibility unless they have Admin or Owner access.

Who can see the page

Report role	Visible page	Invisible page	Change visibility
View	Yes	No	No
Edit	Yes	Yes, with an indicator	No
Admin	Yes	Yes	Yes
Owner	Yes	Yes	Yes

A team management role does not bypass this table. The person's effective report permission determines the result.

What invisibility protects

Viewer-facing access excludes the invisible page from page lists and report catalogue content. Protected reads also cover its visual metadata, results, relevant history, and AI context.

Knowing the page's URL or identifier is not permission to open it. The server checks authorization rather than relying only on a hidden navigation item.

Organization membership, an API key, and a copied report link also do not bypass visibility.

Understand history restrictions

Conversation history, snapshots, and background-run records can contain unstructured content from an invisible page. These surfaces can require editing access when invisible-page history exists, including records associated with a deleted page.

Visible current pages can remain available to viewers while protected historical surfaces are restricted. This prevents an old message or snapshot from exposing content that is no longer viewer-accessible.

Duplicate, delete, and restore

Duplicating an invisible page preserves its invisibility. Supported deletion and undo preserve the page's visibility identity rather than allowing ordinary content restoration to reset access accidentally.

HTML page version restoration keeps current access settings. It restores supported content and registrations, not a historical viewer policy.

Use Change history to understand content restoration separately.

Access changes in an open report

Unity rechecks access as the workspace regains focus, receives access-change signals, and periodically while visible. Server operations also check current permissions.

An open page may therefore disappear or stop accepting actions after an access change. The recheck does not recall information already delivered to a browser.

Visibility and data security

Page visibility protects access to that page. It is not source-level row security and does not prevent an authorized editor from using a shared connection through other permitted workflows.

If different users must receive different source rows, enforce the relevant source and application access requirements in addition to page visibility. A display filter is not a security boundary.

Troubleshoot visibility

Problem	Check
Viewer cannot find a page	Whether it is marked invisible and whether report access remains valid.
Editor can still open an invisible page	Expected behavior for Edit, Admin, and Owner.
Editor cannot toggle the flag	Visibility changes require Admin or Owner.
History becomes unavailable to a viewer	It may contain invisible-page content.
A copied page remains invisible	Duplication preserves visibility intentionally.

See Sharing and access for effective report roles.