Gainsight CSの権限管理と優先順位
全社でGainsightを使って運用する際、支店や部署、役割に応じて権限範囲を制御したいケースがありますよね。
Gainsightの権限設定では、[データ権限]メニュー、[権限バンドル]メニューと複数の「権限」に関するメニューがあります。
この記事では、Companyオブジェクトを例に、3つの権限設定の役割の違いと、Permission Bundleの中にあるAccess PermissionsとFLPの違い、そして複数の権限を設定した場合の適用優先度を整理します。
- 先に結論：権限メニューの役割分担
- 1. データ権限とは
- 2. 権限バンドルとは
- 3. Access PermissionsとFLPの違い
- 4. Field-Level Permissions（FLP）の詳細
- 5. 具体例：Companyの場合
- 6. 権限の適用優先度
- 7. 権限の切り分けチェックリスト
📌 先に結論：権限メニューの役割分担
「どのレコードを見られるか」「どの機能を使えるか」「どの項目を編集できるか」を、それぞれ別の設定で制御します。
| 設定 | 主に決めること | 例（Company） |
|---|---|---|
| データ権限 | どのレコードにアクセスできるか | 東京支店グループのメンバーは、 「担当部署：東京G」のCompanyだけ表示する |
| 権限バンドル └①Access Permissions | どの機能・画面を利用できるか | CSMメンバーは、 C360やCockpitを利用できるようにする |
| 権限バンドル └②Field-Level Permissions | オブジェクト内の各フィールドを、編集可能・閲覧のみ・非表示のどれにするか | 特定メンバーは、 CompanyのStatusは閲覧のみ、ARRは非表示にする |
つまり、データ権限はオブジェクト単位で誰がどのレコードにアクセスできるかを制御し、権限バンドルで機能の利用有無を制御します。
また、権限バンドルには、①Access Permissionsと②Field-Level Permissionsがあり、②はフィールドレベルで修正・閲覧・非表示が制御できる一番細かい単位の権限設定です。
②Field-Level Permissionsは、以下の注意点があります。
・標準では非搭載となり、利用するためにはサポートへ有効化への依頼が必要です。
・本設定を有効にすると、JOや管理系の設定メニューにSuper-Adminしかアクセスできなくなってしまいます。
→管理メニューは制御したいが、JOは許可したい。などができなくなりますので、まずはデータ権限と権限バンドル（①）でやりたいことが実現できるかを検討ください。
🔐 1. データ権限とは
データ権限は、「どのデータ（レコード）にアクセスできるか」の範囲を制限する機能です。
ユーザー（またはユーザーグループ）側の条件と、リソース側の条件を組み合わせて、アクセスできる範囲を絞り込みます。たとえば、次のような条件を設定できます。
- ログインユーザーが所属するグループ
- ユーザー属性や拠点
- CompanyなどのOwner
- Companyなどに登録されたグループや拠点
ユーザー側の条件をCriteria、リソース側の条件をAdviceとして設定します。Company、Relationship、Success Planなど、対象オブジェクトごとに設定でき、親オブジェクトから子オブジェクトへ継承されるアクセスも考慮されます。
例）「部署名」が「東京第一支店」のユーザーの場合、カンパニーオブジェクトの「Tier」フィールドが「Tier1」の会社レコードの閲覧・修正が可能
「閲覧／修正」権限となり、「閲覧のみ」の設定はできません。
🧩 2. 権限バンドルとは
権限バンドルは、ユーザーやユーザーグループに、利用できる機能や権限をまとめて付与する仕組みです。
- Access Permissions：ユーザーが利用できる機能やデータを決める
- Field-Level Permissions：オブジェクト内の各フィールドの閲覧・編集・非表示を決める
設定後は、「Assign Users」のステップで、手動またはルール（条件）によってバンドルにユーザーを割り当てます。
権限バンドルの基本ルール
- デフォルトでは、ユーザーはどのページにもアクセスできません。バンドルで許可されたページだけが利用できます。
- アクセスできないページは、グローバルナビゲーションバーで検索しても表示されません。
- 1人のユーザーに複数のバンドルを付与した場合、すべてのバンドルの権限の和集合が適用されます。
- 管理者向けのDEFAULT_ADMIN_BUNDLE、Viewerライセンス向けのVIEW_GROUPなどは、標準で用意されています。
⚖️ 3. 権限バンドル（①Access Permissionsと②Field-Level Permissionsの違い）
Access Permissionsは「機能・画面を使えるか」、Field-Level Permissionsは「フィールドを編集できるか」を決める設定です。
| 比較項目 | Access Permissions | Field-Level Permissions |
|---|---|---|
| 制御する単位 | ページ・機能・操作 | オブジェクト内のフィールド |
| 設定できる内容 | チェックボックスによる利用可否 | Edit／Read／Hideの3種類 |
| 設定例 | Cockpitを開ける、CTAを作成・削除できる | CTAやCompanyの特定フィールドをReadにする |
| 利用の前提 | 常に利用可能 | ・サポートへの申請による有効化が必要 ・ONにするとJOや管理メニューは |
＜Access Permissionsで設定できること＞
ConfigureをクリックするとAccess Permissionsの設定画面が開き、バンドルに含めたいモジュールや機能にチェックを入れます。主な種類は次のとおりです。
| 種類 | 設定できること |
|---|---|
| Navigation Permissions | Gainsight内のページ・サブページを表示できるか。親ページにチェックを入れても、配下のページには自動でチェックが入らないため、必要なページを個別に選ぶ |
| Survey Permissions | サーベイの設計（Design）、配信（Distribute）、分析（Analyze）、管理（Admin） |
| Email Template Permissions | メールテンプレートの設計（Design）、管理（Admin） |
| Program Permissions | プログラムの設計（Design）、配信（Distribute）、分析（Analyze）、管理（Admin） |
| Productivity and Workflow | Cockpitのリストビューで、詳細フィルターを使ったビューの作成・編集、カラムの追加、CTAのエクスポートを許可するか |
| Cockpit／Success Planの操作権限 | CTAの作成・削除・Playbookの適用、Success Planの作成・削除・テンプレートの適用・共有 |
このようにAccess Permissionsは、「CTAを作成できるか」「Success Planを共有できるか」といった機能・操作の単位で許可を決めます。
＜Field-Level Permissionsで設定できること＞
Field-Level Permissionsは、使える機能の中で、オブジェクトのどのフィールドを編集・閲覧・非表示にするかを決めます。Access Permissionsで機能の利用を許可したあとに、さらにフィールド単位で細かく制限するための設定です。
Field-Level Permissionsの注意点
- 有効化するためにはサポート依頼が必要です。
- テナントでFLPが有効になると、すべての管理画面にアクセスできるのはSuper Adminのみになります。Super Admin以外のユーザーは、Journey Orchestratorや管理（Administration）関連のページにアクセスできなくなります。
- Hideにしたフィールドを使ったフィルターは、ビューが空になったり、権限エラーが表示されたりします。
- CTAをクローズする際に必須フィールドがHideになっていると、CSMはCTAをクローズできません。
- FLPは、外部コラボレーター・内部コラボレーターには適用されません。
※前述した通り、まずはデータ権限と権限バンドル（①Access Permissions）でやりたいことが実現できるかを検討ください。
たとえばCTAの場合は、次のように役割が分かれます。
- Access Permissions：CTAを作成できるか、削除できるか、エクスポートできるか
- Field-Level Permissions：CTAオブジェクトの特定のフィールドを、編集できるか、閲覧のみか、非表示か
🎯 5. 具体例：Companyの場合
やりたいことに応じて、使う設定が変わります。
| ケース | やりたいこと | 使う設定 |
|---|---|---|
| A | グループ内のCompanyだけ閲覧できるようにする | データ権限 |
| B | CSMがC360やCockpitを使えるようにする | 権限バンドル （①Access Permissions） |
| C | CompanyのStatusは閲覧のみ、ARRは非表示にする | 権限バンドル （②Field-Level Permissions） |
| D | 同じグループのメンバーは閲覧のみ、担当CSM本人だけ編集させる | 実現できない |
🧮 6. 権限の適用優先度
優先度は1本の順位表ではなく、3つの段階に分けて考えると理解しやすくなります。
6-1. データ権限内のルール
同じユーザーに複数のルールが該当する場合、アクセス範囲は基本的に和集合になります。ルール同士が足し合わされ、最も広いアクセスが有効になります。Success Planのデータ権限の「Sharing Rules」画面にも、ルールの優先順位を設定する項目はありません。
| ルールA | ルールB | 最終結果 |
|---|---|---|
| CompanyのA〜Cにアクセス | CompanyのD〜Fにアクセス | A〜Fにアクセスできる |
| Owner条件でアクセス | グループ条件でアクセス | どちらかの条件に該当するレコードにアクセスできる |
| 狭い範囲のルール | 広い範囲のルール | 広い範囲が有効になる |
また、親オブジェクトからの継承や、複数のデータ権限ソースがある場合も、権限が合算され、より高いアクセスが適用されることがあります。
6-2. 複数の権限バンドル
同じユーザーに複数の権限バンドルが付与されている場合、ユーザーはすべてのバンドルの権限の和集合を取得します。
- Access Permissions：バンドルAでページA・B・C、バンドルBでページC・D・Eが許可されていれば、ユーザーはA〜Eのすべてのページを利用できます。
- Field-Level Permissions：複数のバンドルで同じフィールドに異なる権限が設定されている場合は、次の表のとおり、制限の弱い権限が適用されます。
| バンドルA（CompanyのStatus） | バンドルB（CompanyのStatus） | 最終結果 |
|---|---|---|
| Read | Edit | Edit |
| Hide | Read | Read |
| Hide | Edit | Edit |
意図しないバンドルが重複していると、
制限したつもりのフィールドが編集できてしまうことがあるため注意しましょう。
6-3. データ権限とField-Level Permissionsの組み合わせ
データ権限とField-Level Permissionsを組み合わせた場合は、制限の強い方が適用されます。
どちらか一方でHideになっていれば、そのフィールドは非表示です。
| データ権限 | 権限バンドル （Field-Level Permissions） | 実際の動作 |
|---|---|---|
| レコードアクセスあり | Edit | 対象フィールドを編集できる |
| レコードアクセスあり | Read | レコードは見えるが、対象フィールドは編集できない |
| レコードアクセスあり | Hide | 対象フィールドは表示されない |
| レコードアクセスなし | Edit | レコード自体にアクセスできないため、編集できない |
✅ 7. 権限の切り分けチェックリスト
うまく動かないときは、次の順番で確認すると原因を切り分けやすくなります。
- そのユーザーは、対象の機能・画面を利用できるか？
→ 権限バンドルのAccess Permissions（Navigation Permissionsなど）とライセンスタイプを確認する - 対象のCompanyレコードにアクセスできるか？
→ データ権限のCriteriaとAdviceを確認する - 対象フィールドを編集・閲覧できるか？
→ 権限バンドルのFLPで、対象オブジェクトのEdit／Read／Hideを確認する - 複数のバンドルやルールが重複していないか？
→ 意図しないEdit権限や、広すぎるデータ権限が残っていないか確認する
まとめ
- データ権限は、レコード単位のアクセス範囲を制御します。レコードごとにReadとWriteを分けることはできません。
- 権限バンドルには、Access Permissions（ページ・機能・操作）とField-Level Permissions（フィールド）の2つの設定があります。
- Access Permissionsは「CTAを作成できるか」「Success Planを共有できるか」など、機能・操作の単位で許可を決めます。
- Field-Level Permissionsは、Company、CTA、CS Task、CTA_Groupなどオブジェクト単位で対象を選び、フィールドごとにEdit／Read／Hideを設定します。
- Field-Level Permissionsはデフォルトでは有効ではなく、利用にはサポートへの申請が必要です。（注意点もあるので先述内容を把握の上まずは標準の権限で運用可能かご検討ください。）
- 複数のバンドルでは、Access Permissionsは和集合になり、FLPは制限の弱い権限が適用されます。
- データ権限とFLPの組み合わせでは、制限の強い方が適用されます。
- 「担当CSMだけ編集、同じグループは閲覧のみ」のように、レコードごとに編集可否を分ける設定はできません。
役割分担を押さえておけば、権限まわりの設計や、トラブル時の切り分けがぐっとスムーズになりますね！