Access Control

Access Control

Zingasolve lets you publish some documentation to the whole world and lock other
documentation down to specific people — in the same site, at any level of the
tree. This article explains how restricted content works and how you grant
access.

The three visibility levels

Every Space, collection, and article resolves to one effective visibility:

A Space always has a concrete level. Collections and articles can set their own
level or choose inherit, in which case they take the effective level of their
nearest parent that specifies one, up to the Space. You set an article's level
from the visibility selector in its editor; you set a collection's and the
Space's from their settings.

How restriction resolves

For a given page, Zingasolve walks from the article up through its collections to
the Space and uses the first concrete level it finds. So a public Space can
contain a restricted chapter, and a restricted Space can expose a single
public page — the most specific setting wins.

• Public pages are open and cacheable.
• Authenticated pages require any signed-in reader.
• Restricted pages require a signed-in reader who matches at least one
  allow-list grant on the page or any of its ancestors.

Grants: the allow-list

Restricted content is opened up with grants. A grant is attached to a scope —
a Space, a collection, or an article — and names who is allowed in. There are
three kinds:

Because Zingasolve shares the same customer identity as your other Zingasuite
apps, tags and contacts you already manage can be used to gate documentation. For
example, tag a group of beta customers and grant that tag access to a "Beta
Docs" collection — everyone with the tag gets in, and access follows the tag as
you add or remove people.

Inheritance down the tree

Grants flow downward. A grant on a Space authorizes every restricted
collection and article inside it; a grant on a collection authorizes every
restricted page beneath it. This means you usually set access once, high in the
tree, rather than page by page:

• Grant at the Space level for "everyone allowed into this whole manual."
• Grant at a collection level for "this chapter is for a specific audience."
• Grant at an article level for one-off exceptions.

A reader can open a restricted page if any grant on that page or on any
collection or Space above it matches them.

Navigation and search respect access

Access control isn't just applied when a page loads. The site's navigation
tree and search results only ever list pages the current reader is allowed
to open, and the hub landing page only lists manuals they can enter. Readers
never see the titles or links of content they can't access. Reusable content
respects this too: a restricted source section will not appear on a more open
page that includes it.

Team access to restricted manuals

Members of your own organization often need to read restricted manuals without
being added as individual contacts. A team member can sign in with their
Zingasuite account from the docs site — an "Sign in with your Zingasuite
account" option appears on sign-in and access-restricted pages. Once signed in as
a verified member of the manual's owning organization, they can read every manual
in that organization regardless of its visibility or grants.

This gives you two independent audiences on the same site: your readers
(customers and partners, gated by grants) and your team (who see everything
they own).

Putting it together

1. Decide the baseline: is this Space public, sign-in only, or restricted?
2. Override at the collection or article level only where it differs.
3. For restricted content, add grants — as high in the tree as possible —
   using any-signed-in-reader, a contact tag, or a specific contact.
4. Rely on inheritance so you manage access in a few well-chosen places.