1. まずは、5つの基本要素を知る

Vtiger CRM OSSの権限は、ひとつの設定だけで決まるものではありません。次の5つを組み合わせて、業務に合った利用範囲をつくります。

2. ユーザー管理は、利用者を登録するところから

ユーザーは、CRMにログインして仕事をする人のアカウントです。通常は管理者が設定 → ユーザー管理 → ユーザー（Users）から追加・編集します。

「管理者」と「営業責任者」は別のもの

管理者（Admin）はシステム全体を管理するための区分です。一方、「営業責任者」はロール階層上の役割です。部下の案件を見せるためだけに管理者へ変更すると、業務上必要な範囲を超えて権限が広がります。まずロールとプロファイルで対応できるかを検討しましょう。[2][4]

3. ロールは階層、プロファイルは操作内容

ロール：誰のレコードまで扱うかに関わる

ロールは組織の階層を表します。モジュールの共有設定が非公開（Private）の場合、一般ユーザーは基本的に自分に割り当てられたレコードと、下位ロールのユーザーに割り当てられたレコードにアクセスします。実際に使える操作は、プロファイルの許可にも従います。[1]

同じ「営業担当者」ロールを山田さんと佐藤さんに設定しても、それだけで互いのレコードが共有されるわけではありません。横の共有には、公開設定やカスタム共有ルールなどを組み合わせます。

プロファイル：閲覧・編集・削除などを決める

プロファイルは、業務に必要な操作をまとめた設定です。たとえば「営業担当用」では顧客企業と案件を利用できるようにし、削除やエクスポートは必要性を確認して許可します。

必須項目やシステム管理項目など、制限を変更できない項目があります。また、モジュールごとに提供される操作・ツールは異なります。プロファイルで許可を付けても、未提供の機能は追加されません。[3]

4. 共有ルールで、レコードの公開範囲を決める

共有ルールは、顧客企業・案件などのモジュールごとに設定します。「顧客企業は社内で閲覧できる」「案件は担当者と上司を基本にする」といった、情報の性質に合わせた運用を検討できます。

上表は共有範囲の説明です。どの設定でもプロファイルの制限が適用されます。所有者や上位ロールへのアクセスは別途考慮します。また、共有設定を変更できるモジュールは画面で確認してください。[1][5]

カスタム共有ルール：必要な相手に追加で共有する

全員への公開では広すぎる場合は、ロールやグループを対象に追加共有を設定します。たとえば案件を非公開にしたまま、営業担当者の案件を「営業支援グループ」へ閲覧共有する、といった考え方です。

ここで重要なのは、共有ルールはアクセスを追加するために使うことです。広く公開した設定の上に「この人だけ見せない」というルールを重ねる発想では、意図どおりに制限できません。必要な制限を基本設定でつくり、必要な相手へ共有を足していきます。[1][5]

グループ：部署をまたぐ共同担当にも使える

グループにはユーザー、ロール、ロールと配下、ほかのグループなどを組み合わせられます。ロール階層を変えずに、営業とサポートの一部メンバーで共通のレコードを扱いたいときにも役立ちます。

グループを作るだけで、全員の個人担当レコードが共有されるわけではありません。対応するモジュールでレコードの担当先をグループにするか、グループを対象とした共有ルールを設定します。操作権限は各ユーザーのプロファイルに従います。[2][5]

5. 営業チームに当てはめてみる

営業責任者1名と営業担当者2名で、案件を管理する例を見てみましょう。ここでは、全員が通常ユーザーで、案件の閲覧・作成／編集は許可し、削除は許可しないプロファイルを使います。

表の前提：個人担当の案件、追加共有なし、グループ経由の共有なし、View All／Edit Allなどの全体権限なし。関連する顧客企業からのアクセスなど、モジュール間の共有の影響もないものとします。実際の設定では関連レコードも含めて確認します。[1][5]

6. 設定は、業務の整理から順に進める

設定画面を開く前に、対象モジュールごとの「誰の情報を見るか」「どの操作を使うか」を決めておくと、迷いが減ります。次の順序がおすすめです。

1. 利用範囲を表にする

   営業担当者・営業責任者・営業支援などの役割ごとに、利用するモジュール、閲覧範囲、編集・削除・出力の要否を整理します。

2. プロファイルを作成する

   設定の「Profiles」で、必要な操作・項目・ツールを設定します。職種が同じ人は共通のプロファイルにすると、見直しやすくなります。

3. ロール階層とユーザーを設定する

   「Roles」で上位・下位の関係をつくり、プロファイルを関連付けます。「Users」で各利用者へロールを割り当てます。

4. グループと共有ルールを設定する

   共同担当が必要なら「Groups」を作成し、「Sharing Rules」でモジュールの公開範囲と追加共有を設定します。画面に再計算（Recalculate）等の反映操作がある場合は実行し、完了を確認します。

5. 通常ユーザーで確認する

   担当者本人・上司・同僚のテスト用アカウントで、それぞれ見えるレコードと操作を確認します。管理者だけで確認を終えないことが大切です。

ロールに権限を直接設定する方式もあります。この記事では、同じ操作権限を複数の役割で再利用しやすい「既存プロファイルの関連付け」を基本として説明しています。[3][6]

7. 異動・退職と、設定後の見直し

異動では、ロールとグループを両方確認する

営業部からサポート部へ異動した場合、ロールを変更するだけでなく、所属グループと追加共有の対象も見直します。以前の業務で付けたアクセスが残っていないか、確認しましょう。

退職では、利用停止とレコードの引き継ぎを分けて考える

ユーザーの無効化と、担当レコードの移管は別の確認事項です。OSS 8.4にはユーザーをInactiveにする処理と、ユーザー削除時に移管先を指定する処理があります。画面の操作に合わせて、利用状態と引き継ぎ先を確認します。[4]

運用上は、顧客企業・案件・問い合わせ・活動などの担当情報に加え、そのユーザーを参照する通知先やワークフローも確認しておくと、引き継ぎ漏れを減らせます。完全削除を行う場合は、必要な履歴の保存と移管結果を先に確認しましょう。

設定後に確認したいこと

• 担当者本人・上司・同僚で、レコードの見え方が想定どおりか。
• 一覧だけでなく、詳細・編集・関連一覧でも想定どおりに扱えるか。
• 非表示・読み取り専用にした項目が、必要な画面で意図どおりになっているか。
• 削除やエクスポートなど、許可していない操作が使えないか。
• 顧客企業と案件など、関連するモジュールの担当者や共有設定がアクセスに影響していないか。
• 管理者指定、全体権限、複数のプロファイル・グループから権限が広がっていないか。

「見えてはいけないものが見えない」だけでなく、「仕事に必要な情報が使える」ことまで確認して、設定を完了させます。

8. よくある質問