Administration and CI

Workspaces and teams

epismo workspace create --handle team
epismo workspace update <workspace-id> --handle new-name
epismo workspace checkout <workspace-id>
epismo workspace use acme
epismo -w acme workspace member list
epismo workspace member list
epismo workspace member upsert <user-id> --role admin
epismo workspace member delete <user-id>

epismo team list
epismo team create --name "Website" --description "Marketing and docs"
epismo team update <team-id> --name "Website launch"
epismo team member list --team-id <team-id>
epismo team member add <user-id> --team-id <team-id>
epismo team member delete <user-id> --team-id <team-id>

epismo workspace checkout <workspace-id> starts a hosted subscription checkout. If the workspace has a cancellation scheduled for the end of its current billing period, it resumes that existing subscription instead of creating a second one.

Workspace roles are owner, admin, and member. A workspace reference is an exact ID or unique handle such as acme; use --workspace/-w for a one-command override, EPISMO_WORKSPACE for a shell or job, and workspace use only to save a default. Teams are private sharing principals inside the selected workspace. Member commands accept supported bulk forms; use --help for the exact current argument shape.

Credits

epismo credit balance
epismo credit checkout --quantity 500

The resolved execution context determines which balance is read or purchased. Check whoami and the current workspace before a large automated job. A credit-gated request may return 402 when the selected context has insufficient balance.

CI tokens

epismo token create --workspace-id <workspace-id>
EPISMO_TOKEN=<access-token> epismo whoami

Store tokens in a secret manager, never in a playbook definition, case input, record, repository, or shell history. A workspace-scoped EPISMO_TOKEN limits access to its workspace; do not use a conflicting --workspace value. Give each automation environment its own token so it can be rotated without interrupting personal sessions.

A team can connect multiple workspaces. 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.

epismo -w <sender-workspace> team invite <team-id> --emails customer@example.com
epismo -w <sender-workspace> team invitation list <team-id>
epismo team invitation get <token>
epismo -w <recipient-workspace> team invitation accept <token>
epismo -w <workspace> team invitation revoke <team-id> <invitation-id>
epismo -w <workspace> team disconnect <team-id>
epismo workspace create --handle <handle> --team-invitation-token <token>

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.

The HTTP handover request now uses memberId, successorId, and transferApprovals. Its response contains counts in cases, playbooks, tasks, approvals, and suggestions. The CLI needs a matching release before its handover command can use this contract.