ワークスペースとチーム

ワークスペースは、アカウント、データ、クレジット、請求を組織単位で管理するための枠組みです。個人での試行には個人スペースを使い、組織が所有すべき案件やプレイブックはワークスペースを選択して作成します。

役割はオーナー、管理者、メンバーの3種類です。主なワークスペース操作の権限は次のとおりです。

別々のワークスペースのメンバーが、一つの共同チームに参加できます。各社は自分のワークスペースで参加者を管理し、チームに共有された案件やプレイブックを一緒に使います。

操作上は、参加に使うワークスペースをそのチームに「接続」します。チーム招待の送信・一覧表示・取り消しは、接続済みワークスペースのオーナーまたは管理者であるチーム参加者のみが行えます。受信者は招待先のメールでログインして既存のワークスペースを選ぶか新規作成します。送信者は接続先を指定しません。受け入れ時にはワークスペースを接続し受信者を参加者にしますが、所属メンバー全員を追加するわけではありません。すでにチームに接続済みのワークスペースで招待を受け入れると、招待を消費せずに HTTP 409 を返します。そのワークスペースの参加者はチームのメンバー管理から追加してください。各ワークスペースは自分の参加者を管理します。同じユーザーは複数のワークスペースから参加でき、あるワークスペースのメンバーから削除しても、ほかのワークスペースからの参加は維持されます。切断するとその接続と参加者を削除し、ほかの接続は保持します。チーム経由の権限には参加元ワークスペースとリソースの所属先の両方が接続中である必要があります。直接のユーザー共有は切断後も維持されます。招待の有効期限は14日で、再送すると前の招待を閉じます。接続してもワークスペースの購読要件は変わりません。

オーナーと管理者は、未登録のメールアドレスをメンバーとして招待できます。Epismo は招待リンクをメールで送り、招待先のアドレスでアカウントを作成するとワークスペースへの参加が自動で完了します。既存の Epismo ユーザーはすぐに追加されます。オーナーと管理者は保留中の招待を確認・取り消しできます。招待時の役割は常にメンバーで、参加後に役割を変更します。

CLI 操作は管理と CI、ACL の意味はアクセス権とアカウントを参照してください。

作成時の明示的な共有設定と共有設定の更新は access: { visibility, grants } を使います。公開範囲は restricted/public、共有先はユーザー・チームの UUID または登録済みユーザーのメールアドレスをキーに viewer/editor を指定します。メールアドレスは保存前にユーザーの UUID に解決し、応答は UUID を返します。未登録のメールアドレスや、同じユーザーに解決される共有先の権限が競合する場合は、更新全体を拒否します。更新は設定全体を置き換えるため、無関係な共有先を保持し、自分への直接共有を残す場合も含めてください。所有者は共有設定とは独立して管理権限を持ち、担当者や管理者には自動で権限を付与しません。編集者は共有設定の取得・変更、少なくとも1件の明示的な編集者を保持した共有設定の変更、アーカイブ・復元ができます。通常の取得結果には非公開の共有先一覧が含まれないため、編集者は共有設定の取得操作で設定全体を確認します。アクセスと権限も参照してください。

顧客と使うチームを用意する

自社と顧客が、それぞれのワークスペースに所属したまま、一つのチームで共同作業できます。例えば「顧客 A 導入チーム」に双方の担当者が参加し、そのチームへ共有した案件やプレイブックを一緒に使います。参加者は各社が管理し、他の案件やプレイブックの共有設定はそのままです。

まず、自社のオーナーまたは管理者がチームを作り、自社の担当者を追加します。顧客が先にチームを作り、自社の窓口を招待する進め方もできます。

顧客の参加方法は、次の二つから選びます。

それぞれのワークスペースから参加する場合

1. 送信元ワークスペースのオーナー・管理者であり、そのチームの参加者でもある人が、顧客の窓口へチーム招待を送ります。
2. 受信者が招待先のメールでログインし、顧客のワークスペースを選ぶか新規作成します。送信者が接続先を指定するものではありません。
3. 受信者が、自分のワークスペースに所属したまま共同チームへ参加します。この操作で、そのワークスペースがチームに接続されます。参加するのは受信者本人です。他の参加者は顧客側のチームメンバー管理から追加します。すでに接続済みなら、別の招待を受け入れるのではなく、その管理画面から追加します。
4. 対象の案件・プレイブックをチームへ共有し、顧客の参加者が自分のワークスペースを選んだ状態でアクセスできるか確認します。

自社ワークスペースに招待する場合

1. オーナー・管理者が顧客メンバーをメールで招待します。既存ユーザーはすぐに追加され、未登録ユーザーは招待メールを受け取り、そのアドレスでアカウントを作成すると参加が完了します。
2. 参加したメンバーを顧客用チームへ追加します。ワークスペースに所属するだけでは、チームへの参加や案件・プレイブックの権限は得られません。
3. 顧客へ見せるリソースだけを、そのチームへ共有します。参加者を増やす前に、すでにチームに共有されている内容も確認します。
4. 顧客が案件とプレイブックの保存済みバージョンを開けることを確認し、編集が必要な場合は編集権限も確かめます。自社ワークスペースの所属・サブスクリプション・SSO の要件が適用されます。

案件・プレイブックごとの所有元と請求先は別に選びます。チームの作成場所でリソースの所有元が決まるわけではなく、ワークスペースの接続でも所有元は移りません。チーム経由でアクセスするには、所有元と参加元の両ワークスペースの接続が必要です。

共同で更新するチームには editor、読むだけなら viewer を設定し、保守する社内の編集者も残します。チームへの権限は参加者に適用されるため、社内と顧客で役割を変える場合はチームを分けます。案件とプレイブック、コピーしたプレイブックはそれぞれ共有設定を確認します。支援終了時には、チーム参加者・ワークスペース接続・個人への直接共有を見直します。ワークスペースを切断するとその接続経由の権限は失われますが、個人への直接共有は残ります。

導入業務全体の流れは顧客と進める仕事に使う、チーム招待とメンバーの CLI 操作は管理と CIを参照してください。

所有・責任・ライフサイクル

メンバー削除前に、オーナー・管理者は案件担当・プレイブックの管理者・共有権限の引き継ぎをプレビューして実行できます。未完了の承認タスクは明示指定した場合だけ引き継ぎ、完了済み承認と作成者は履歴として保持します。現在の所属メンバーから後任を選び、プレビューを確認してください。workspace member handover <workspace-id> --member-id <user-id> --successor-id <user-id> は既定でプレビューです。--preview=false で実行すると後任へ編集権限を明示的に付与します。次に workspace member delete --workspace-id <workspace-id> <user-id> で所属を削除し、--preview=false --finalize で引き継ぎを再実行して、その間の変更も整理します。引き継ぎの最終処理（finalize）は所属の削除後にだけ実行でき、メンバー削除そのものは行いません。退会により該当するチーム経由の権限とワークスペース管理権限は失われます。最初の引き継ぎでは直接共有を保持し、所属削除時にそのワークスペース所有のアイテムへの共有を解除します。最終処理でも、途中で追加された共有を整理します。個人所有や別ワークスペースへの共有は維持されます。

プレイブックと案件には所有元のユーザーまたはワークスペースのアカウント（ownerId）があり、請求先も兼ねます。個人所有者は全権限を持ち、ワークスペース所有の場合は現在のオーナー・管理者が所有権限を行使します。それ以外のメンバーには、ユーザー・チームへの明示的な共有、または公開コンテンツへの公開設定が必要です。所属だけでリソースへの権限は得られません。退会時には、そのワークスペースが所有するアイテムへの直接共有も、完了・アーカイブ済みを含めて解除されます。解除によって編集者がゼロになるアイテムがあれば、完了・アーカイブ済みも含め、先に別のユーザーまたはチームを編集者に追加してください。個人所有や別ワークスペースのアイテムへの共有は維持されます。チーム経由の権限と管理権限は現在の所属に従います。必須 SSO は所属メンバーに適用し、非メンバーへの直接共有は通常の Epismo 認証で利用できます。ワークスペース間のチーム共有では、参加元ワークスペースの SSO を確認します。一覧は明示的な共有と対応する公開設定で決まり、所有権限だけでは表示されません。

閲覧者は共有された内容を読めますが編集できず、プレイブックの下書きには編集権限が必要です。編集者は内容・共有設定の変更、少なくとも1件の明示的な編集者を保持した共有設定の変更、アーカイブ・復元ができます。所属先の移管、管理者変更、案件の完全削除、過去バージョンのアーカイブには所有権限が必要です。assignedTo は責任を表し、権限を付与しません。新しい担当者・管理者には既存の編集権限が必要で、ワークスペース所有の場合はその所属メンバーである必要もあります。担当変更は共有設定を維持し、所有権移管で元所有者を自動的に編集者へ追加することもありません。