Sites
Sites turns real work into an organization page that preserves its native shape: a table, dashboard, Gantt or project view. You approve the exact page and its access mode; verified contributions return to the Sites studio while your local record remains the source of truth.
Use the view that matches the work. Publish ownership rows for sign-off, a metric dashboard for review, a delivery timeline as a Gantt, or a project view for launch coordination. The browser page is a collective surface; the originating Studio keeps the underlying structure.
◧ Native presentations
Tables, dashboard tiles, Gantt timelines and project views keep their intended form.
◧ Human-gated publishing
The page stays local until you inspect the staged card and click Publish.
◧ Flexible participation
Choose organization contribution access or a page everyone can only view.
◧ Attributed responses
Edits and sign-offs return with verified identity and an activity history.
What it is#
A site is a focused page on Zimac's organization Sites service. Every page has a title and may include prose sections and structured rows; its presentation is table, dashboard, Gantt or project. Dashboard sites preserve headline tiles, while Gantt and project sites preserve the column mapping needed to render their native view. The same service supplies the organization URL, access checks, revisions and contribution log.
Publishing a site#
A specialist stages a confirmable publish card with the destination slug, title, access mode and exact page payload. Rendering the card is read-only; the request to the Sites service happens only when you click Publish to the org. Republishing the same slug creates a new revision.
For a contributable page, choose the row sign-off wording teammates will see: Approve, Confirm, Verify, Acknowledge or Sign off. You can instead publish read-only, where organization members may view but cannot edit or sign off.
How teammates contribute#
Organization members open the URL in a normal browser and authenticate with their Zimac organization identity. On an open page they can use the selected sign-off action, edit allowed values or add a row; on a read-only page they can only inspect the published view. The service attributes actions to the authenticated contributor rather than a name typed into the page.
Statuses, attribution & sync#
Every row carries a status that moves as people act on it:
Each action is attributed server-side to the contributor's verified identity and recorded in a per-site change log. Your app pulls that log down and reconciles it into the local record, so the Sites studio shows the current rows, status counts and a “who did what” activity feed. An open site detail view watches for new contributions; background sync continues even when you are not babysitting the Studio.
The published service copy is the collaboration surface, while the local app remains the source of truth. If the remote page is removed or you unpublish it, Zimac marks it unpublished and retains the local rows and contribution history.
What a site shares#
A site is deliberately different from encrypted team messages. Signals, Broadcasts and Asks travel as sealed team envelopes; a site is meant to be rendered by a browser, so the Sites service stores and serves its published content to authenticated organization members. The publish card is therefore a disclosure boundary, not just a preview.
Tracking contributions#
Each site card shows its live or unpublished state, read-only mode, revision, last update and pending/edited/confirmed counts. Expand it for exact rows and recent activity, open the browser page, force a sync, or use the two-step Unpublish action. Unpublishing removes the organization page but keeps your local copy.