Access and identity

Users and workspaces are both Accounts and can own Playbooks. A Playbook exposes visibility (private or public) and explicit editors (active User Account or Team IDs). public grants read access to its published content only; editors can read and edit content. The owner is implicit, is never listed as an editor, and can always read, edit, manage access, and archive. For a Workspace-owned Playbook, Workspace Owners and Admins are owner managers with the same rights. Cases do not support public access.

Playbook and Case ACLs are independent. Starting from a public, shared, or team-readable Playbook does not copy its visibility into the Case. Choose a Case ACL explicitly because its input, outcomes, and Records may be more sensitive than the reusable guidance.

Authorization is evaluated against current ACLs. Record reads always intersect filters with the live Case ACL; an acl filter only narrows authorized results and never grants access. Suggestion access also rechecks the current target Playbook rather than relying only on the creation-time snapshot.

Only an owner manager can manage Playbook access, archive the Playbook, or archive a historical Version. The latest Version cannot be archived. A readable user can create a Suggestion; the Suggestion author can edit an open proposal, while the Playbook owner resolves it. Aliases provide names, share tokens provide token-based reads, and stars provide personal saving—none changes ownership.

Use idempotency UUIDs for mutations. Reuse one only for the identical request after an uncertain response. Case and Task mutations additionally require lock versions so concurrent collaborators do not silently overwrite each other.