Workspaces and teams

A workspace is the organizational boundary for identity, data, credits, and billing. Keep personal experiments in personal space and create organization-owned cases and playbooks in workspace context.

Roles are owner, admin, and member. Their main workspace capabilities are:

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.

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.

Owners and admins can invite unregistered email addresses as members. Epismo emails each invitee a link; after they create an account with that address, their membership is applied automatically. Existing Epismo users are added immediately instead. Owners and admins can review and revoke pending invitations; all invitations grant the member role, and role changes happen after the person joins.

People from different workspaces can participate in one shared team. Each company manages its participants from its own workspace and works together on the cases and playbooks shared with the team.

In the setup controls, the workspace used to participate is “connected” to that team. Only team participants who are owners or admins of their connected workspace can send, list, or revoke team invitations. The email recipient signs in with that email and chooses an existing workspace or creates one. The sender never chooses the destination. Acceptance connects the workspace and adds the recipient, not every workspace member. Accepting into a workspace already connected to the team returns HTTP 409 without consuming the invitation. Use team member management to add participants in that workspace. Each workspace manages its own participants. The same user can participate through multiple workspaces; removing their membership in one workspace preserves their participation in the others. Disconnect removes that workspace and its participants; other connections remain. Team-based access requires both the participation workspace and the resource home to stay connected. Direct user grants remain after disconnect. Invitations expire after fourteen days; resending closes the previous invitation. Connecting a workspace does not bypass its subscription requirements.

See Administration and CI in the CLI for operations and Access and identity for ACL behavior.

Explicit creation settings and sharing updates use access: { visibility, grants }: restricted/public visibility and user/team UUID or registered user email keys with viewer/editor values. Emails resolve to user UUIDs before saving; responses contain UUID keys. An unregistered email or conflicting roles for the same resolved user rejects the entire write. Updates replace the whole object; preserve unrelated grants and include your own grant if you want to retain it. Owners retain management independently of grants. Assignees and maintainers receive no implicit access. Editors can inspect and replace sharing, retain at least one explicit editor when changing grants, and archive or restore. Ordinary resource JSON omits private grant maps; editors can retrieve the complete settings with access-get. See Access and identity.

Set up a team with a client

Your staff and client participants can work in one team while staying in their own workspaces. For example, both companies join “Client A delivery” to use cases and playbooks shared with that team. Each company manages its own participants; other cases and playbooks retain their sharing settings.

Start with an owner or admin creating the team in your workspace and adding your participants. The client can also create the team first and invite your contact.

Choose one of these two participation patterns:

Participate from separate workspaces

1. A team participant who is an owner or admin of the sending workspace sends a team invitation to the client contact.
2. The recipient opens the invitation, signs in with the invited email, and selects their workspace or creates one. The sender does not select the recipient’s workspace.
3. The recipient joins the shared team while staying in their own workspace. This step connects that workspace to the team and adds only the recipient. The client workspace adds its other participants through team member management. If already connected, add participants there rather than accepting another workspace invitation.
4. Share the intended cases and playbooks with this team, then verify access with a client participant in their selected workspace.

Invite client members into your workspace

1. An owner or admin invites client members by email. Existing users join immediately; unregistered users receive an invitation and join after creating an account with that address.
2. Add the joined members to the client team. Workspace membership alone does not add them to a team or grant access to cases and playbooks.
3. Grant that team access only to the intended client resources. Review any existing resources shared with the team before adding participants.
4. Confirm the client can open the case and published playbook; test editing only when they need editor access. Your workspace’s membership, subscription, and SSO requirements apply.

Choose the owning and billing workspace for each case and playbook separately. Team creation does not determine resource ownership, and connecting workspaces does not transfer it. Both the owning workspace and each participant’s workspace must be connected for team-based access.

For either pattern, give the team editor access when its participants should contribute, or viewer when they should only read; retain an internal editor for maintenance. A team grant applies to its participants, so use separate internal and client teams if their roles differ. Check cases and playbooks separately, including a copied playbook. At the end of the engagement, review team participation, workspace connections, and direct user grants; disconnecting a workspace removes team-based access through that connection, but direct grants remain.

For the full delivery workflow, see Work with clients. CLI examples for team invitations and members appear in Administration and CI.

Ownership, responsibility, and lifecycle

Before removing a member, an owner or admin can preview and execute explicit handover of case assignments, playbook maintenance, and access. Open approvals transfer only when explicitly requested; completed approvals and authorship remain history. Review the preview and choose a current successor. workspace member handover <workspace-id> --member-id <user-id> --successor-id <user-id> defaults to preview; use --preview=false to execute. This explicitly grants the successor editing access. Remove membership separately with workspace member delete --workspace-id <workspace-id> <user-id>, then repeat handover with --preview=false --finalize to clean up intervening changes. Finalize requires membership to have already been removed and does not remove it. Removal revokes the corresponding team and workspace management authority. Initial handover preserves direct grants; membership removal clears them on that workspace’s items, and finalization repeats cleanup for late grants. 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.