Access and identity

Users and workspaces are accounts and can own playbooks. Playbooks and cases use one settings object: access: { visibility, grants }. Visibility is restricted or public; stored grants map user-account or team UUIDs to viewer or editor. public is never a grant key. Updates replace the complete settings object atomically; preserve existing grants when changing only visibility. Creation retains creator editing through a direct grant or a selected Team editor grant. Updates must retain at least one explicit user or team editor, regardless of ownership or publication.

Choose initial sharing

For case creation, playbook creation, and playbook copy in a workspace, choose exactly one sharing option, even when the workspace comes from the credential or connection default:

Personal-space creation may omit sharing. A non-admin workspace member may create a playbook or copy with restricted creator access or editor grants to their current workspace Teams; other initial sharing requires an owner or admin.

Grant keys in access.grants accept user/team UUIDs or registered user emails. Emails resolve to user UUIDs before saving; responses always contain UUID keys. Matching email and UUID entries with the same role coalesce. An unregistered email or conflicting roles for the same resolved user rejects the entire write.

Sharing updates take the complete access object. Read current settings first, preserve unrelated grants, and retain at least one editor. They do not merge a Team or remove self-access automatically; keep or omit your own grant explicitly.

Ownership and ongoing access

Viewers can read shared content but cannot edit; playbook drafts require editing. Editors may change content and sharing, retain at least one explicit editor when changing grants, and archive or restore. Ownership is required for affiliation transfer, maintainer changes, permanent case deletion, and historical playbook version archival. assignedTo expresses responsibility and never grants rights. A newly selected assignee or maintainer must already have editing access and, for a workspace-owned resource, belong to that workspace. Reassignment preserves sharing; ownership transfer does not automatically add the former owner as an editor.

Playbooks and cases have an owning user or workspace account (ownerId), which is also the billing home. A personal owner has full rights; current owners and admins exercise ownership rights for a workspace. Other members need explicit user or team grants, or public visibility for published reads. Workspace membership alone grants no resource access. Removing a workspace member clears their direct grants on items owned by that workspace, including archived and completed items. If removal would leave any affected item without an explicit editor, add another user or team editor first, including on completed and archived items. Personal and other-workspace shares remain unchanged. Team and management authority follow current membership. Required SSO applies to members; non-member direct shares use normal Epismo authentication. Cross-workspace team sharing verifies the participation workspace's SSO. Lists use explicit access and supported public visibility; ownership alone does not include an item.

Omit ownerId on creation or copy to use the active workspace, or your personal account when no workspace is selected. Supplying it explicitly chooses the home subject to authorization. Maintenance and assignment do not replace sharing.

Public case reads expose the current title, input, tasks, records, and readable handoffs, including later additions. They retain public author and assignee account references, but omit private grants, linked sources, review reports and summaries, and private configuration. The web UI shows public handles and avatars; users without a public handle appear as Anonymous user without an avatar. Public visibility never permits editing or assignment changes. Public playbook visibility permits published reads, never drafts.

Case and playbook sharing are independent. Starting from a readable playbook does not copy its access into the case. Choose case sharing explicitly for its input and evidence. Changing a case’s sharing hides review reports generated for the earlier audience. A new evaluation uses evidence available to the current case audience.

Teams can connect multiple workspaces. A team grant applies only while the caller's participation workspace and the resource's home remain connected. Disconnecting removes that workspace's participants and stops its team-based resource access immediately; other connections and direct user grants remain. Reconnection restores access through retained team grants.

Authorization uses current ownership, sharing, membership, and SSO. Record filters only narrow authorized results; they never grant access. Editors may retrieve complete sharing with access-get. capabilities.canManage and capabilities.canEdit describe the current request’s capabilities; clients cannot submit them as grants. A sharing-update replay returns that operation’s saved response.

Suggestions belong to their live parent playbook and have no separate owner or sharing snapshot. authorId records who created the proposal; baseVersionId preserves the immutable content reference for evaluating it. Reading requires current parent access; an archived parent hides its suggestions until restored. Authors may edit their open proposals while retaining parent access; current playbook editors may adopt or decline proposals. After a transfer, existing proposals follow the parent’s current sharing. Publish the result before marking a proposal applied.

Aliases provide names and share URLs redirect to a resource where current access still applies. Neither grants permission or changes ownership. Mutation requests use an idempotency UUID; reuse it only for an identical request after an uncertain response. Existing case and task mutations additionally require the latest lock version.

The Visible teams heading selects or deselects all Teams at once. The Web sidebar narrows discovery to direct user shares and selected teams, including connected-team shares from other owning accounts. All teams can be deselected; the empty selection persists and leaves direct user shares. Workspace lists, search, archives, and work inboxes do not implicitly filter by owner. Sidebar selection does not change direct-link access, editing capabilities, or mutation permissions. API, CLI, and MCP use normal access-based visibility and expose no sidebar team-selection filter.

Sharing scope and discovery

Visibility uses restricted or public. The independent sharingScope filter accepts private, shared, or anyone: Private means a single known user principal; Shared means multiple users or any team, workspace, or unresolved principal; Anyone means public visibility. Classification includes the playbook owner or case assignee and is independent of the viewer. Restricted visibility can still have explicit user or team grants.

Omit sharingScope to include all classifications within the verified discovery scope. Filters only narrow readable resources; they never grant access. Case and playbook lists, playbook search, and resource aggregates support this filter. The CLI flag is --sharing-scope; playbook discovery also accepts --assigned-to for the maintainer. includePublic and --include-public have been removed.

Case discovery uses GET /v1/cases, epismo_case_list, or epismo case list, ordered by update time and ID descending. Anonymous callers receive public cases, including cases without records. Use playbookId (--playbook-id) to select a source playbook, and combine status and sharing-scope filters. assignedTo=me requires authentication. Popularity discovery has been removed. Archived discovery continues to require private access.

Web operational lists exclude publication-only access; Explore uses public authority even when signed in. API, CLI, and MCP discovery include public resources by default.