Name the reader before choosing the setting
Avoid treating “customer-only” as equivalent to “one named customer.” An audience-based system and per-customer entitlements solve different problems. If one customer must never see another customer’s material, verify that exact requirement before storing it in a shared documentation product.
| Audience | Typical content | Access expectation |
|---|---|---|
| Anyone evaluating the product | General setup overview and supported capabilities | Readable without a customer account. |
| Authenticated customers | Instructions intended for people with app access | Reader sign-in is required when the help center is private. |
| The product team | Internal notes and unreleased operating details | Customer sessions must not grant editing or internal access. |
Keep useful product explanations public when appropriate
Public instructions help someone evaluate how a product works before signing up. They also provide a stable link for onboarding or a support reply. A public answer should stand on its own without revealing account-specific data.
A general “How project sharing works” article can explain roles and expected behavior. It does not need a real customer’s project, invitation address or internal configuration. Use clearly labeled sample data when an example needs context.
Keep reader authentication separate from authoring access
A customer who signs in to read an article should not gain access to the editor, draft revisions or management tools. Likewise, an author’s preview is not evidence that an anonymous or customer session can read the published page.
ClearWay Docs supports public, private and mixed help centers. Core and Pro include the customer-access connection for your app’s login. Customer sessions are separate from team sessions, and team-only articles stay restricted. Private customers use full-page Help links; the public launcher is not a private embedded-identity solution.
Test the boundary with a small access matrix
Choose one article for each audience you intend to use. Test its published URL while signed out, signed in as a customer and signed in as a team member. Also test its search result, media and any machine-readable reading endpoint you enable.
Repeat the checks after removing access or disconnecting customer authentication. The goal is the same intended boundary across reading surfaces, not merely a hidden navigation link. Keep draft-only content out of public tests.
Ask about capabilities your audience model requires
If you need identity-provider group mapping, customer-specific entitlements or automatic provisioning, ask about each requirement explicitly. A product mentioning SSO does not establish that all of those capabilities are included.
The current ClearWay Docs customer-access workflow connects app login to published customer content. Per-customer group and entitlement rules, SCIM and identity-provider group mapping are outside the current implementation. Evaluate private documentation using the implemented features rather than assuming an enterprise access model.
Common questions
Does robots.txt protect a private knowledge base?
Can customers edit ClearWay Docs articles after signing in?
Choose the audience first, enforce that boundary on every reading surface, and test with signed-out and customer sessions before publishing sensitive material.