Vtiger CRM OSS · STANDARD FEATURES
「誰が」「何を」「どこまで」
できるかを整理する。
顧客情報をチームで活用したい。一方で、すべての情報を全員に公開するのは避けたい。そんなときに土台となるのが、Vtiger CRM OSSのユーザー管理と権限管理です。
この記事では、混同しやすいロール・プロファイル・共有ルールの違いを図解しながら、営業チームの設定例と運用のポイントを紹介します。
対象：Vtiger CRM Open Source 8.4系の標準機能。日本語の項目名は翻訳や導入環境で異なるため、英語名を併記しています。図は仕組みを説明する概念図です。
最初に押さえたいこと
「レコードが見える範囲」と「そのレコードに対してできる操作」は、別々に設定します。共有範囲を広げても、プロファイルで許可していない操作が自動的に使えるようになるわけではありません。[1]
1. まずは、5つの基本要素を知る
Vtiger CRM OSSの権限は、ひとつの設定だけで決まるものではありません。次の5つを組み合わせて、業務に合った利用範囲をつくります。
ユーザー / Users
誰が使うか。ログインする一人ひとりのアカウントです。氏名、メールアドレス、ロール、利用状態などを管理します。
ロール / Roles
組織のどこに位置するか。営業責任者、営業担当者などの階層です。上位・下位の関係が、レコードへのアクセスに関わります。
プロファイル / Profiles
何の操作ができるか。モジュールの利用、閲覧・作成／編集・削除、項目やツールの利用権限を定義します。
共有ルール / Sharing Rules
どのレコードを扱えるか。モジュールごとの公開範囲と、特定のロールやグループへの追加共有を設定します。
グループ / Groups
誰と一緒に扱うか。ユーザーやロールなどを束ねる単位です。「営業支援チーム」「問い合わせ受付」など、共同担当や共有先のまとまりに利用できます。[2]
2. ユーザー管理は、利用者を登録するところから
ユーザーは、CRMにログインして仕事をする人のアカウントです。通常は管理者が設定 → ユーザー管理 → ユーザー（Users）から追加・編集します。
| 設定項目 | 確認すること |
|---|---|
| ログイン情報 | 重複しないユーザー名とパスワードを設定する。メールアドレスとユーザー名は、画面上の項目を区別して確認する。 |
| 氏名・メール | 担当者として識別できる名前と、業務で使用するメールアドレスを登録する。 |
| ロール | その人に必要なレコード範囲と操作権限につながるロールを選ぶ。 |
| 管理者の指定 | システム設定を担う人に限定する。一般の営業担当者は通常ユーザーとして運用する。 |
| 利用状態・個人設定 | 有効／無効の状態に加え、言語・タイムゾーン・日付表示などを確認する。 |
「管理者」と「営業責任者」は別のもの
管理者（Admin）はシステム全体を管理するための区分です。一方、「営業責任者」はロール階層上の役割です。部下の案件を見せるためだけに管理者へ変更すると、業務上必要な範囲を超えて権限が広がります。まずロールとプロファイルで対応できるかを検討しましょう。[2][4]
運用のコツ
アカウントは一人にひとつ。共通IDを複数人で使うと、担当者の区別や利用停止時の管理が難しくなります。
3. ロールは階層、プロファイルは操作内容
ロール：誰のレコードまで扱うかに関わる
ロールは組織の階層を表します。モジュールの共有設定が非公開（Private）の場合、一般ユーザーは基本的に自分に割り当てられたレコードと、下位ロールのユーザーに割り当てられたレコードにアクセスします。実際に使える操作は、プロファイルの許可にも従います。[1]
同じ「営業担当者」ロールを山田さんと佐藤さんに設定しても、それだけで互いのレコードが共有されるわけではありません。横の共有には、公開設定やカスタム共有ルールなどを組み合わせます。
プロファイル：閲覧・編集・削除などを決める
プロファイルは、業務に必要な操作をまとめた設定です。たとえば「営業担当用」では顧客企業と案件を利用できるようにし、削除やエクスポートは必要性を確認して許可します。
| 設定の単位 | 主な内容 | 設定例 |
|---|---|---|
| モジュール | 顧客企業・案件などの利用可否と、閲覧・作成／編集・削除 | 案件は利用できるが、削除は許可しない |
| 項目 | 非表示・読み取り専用・書き込み可能 | 社内管理用の項目は読み取り専用にする |
| ツール | そのモジュールが提供するインポート・エクスポートなど | 一覧の閲覧は許可し、エクスポートは許可しない |
必須項目やシステム管理項目など、制限を変更できない項目があります。また、モジュールごとに提供される操作・ツールは異なります。プロファイルで許可を付けても、未提供の機能は追加されません。[3]
「すべて閲覧」「すべて編集」に注意
View All／Edit Allなどの全体権限は、細かな制限に影響します。レコードを限定したいときは、管理者指定、全体権限、ロールに関連するすべてのプロファイルを確認しましょう。[3]
4. 共有ルールで、レコードの公開範囲を決める
共有ルールは、顧客企業・案件などのモジュールごとに設定します。「顧客企業は社内で閲覧できる」「案件は担当者と上司を基本にする」といった、情報の性質に合わせた運用を検討できます。
| 設定 | 他ユーザーのレコードへの基本アクセス | 利用を考える場面 |
|---|---|---|
| 非公開 Private | 自分と下位ロールを基本に制限。グループや追加共有も影響する | 担当者ごとに案件を分けたい |
| 公開：閲覧のみ Public: Read Only | 閲覧を許可する | 顧客情報を参考情報として共有したい |
| 公開：閲覧・作成／編集 Public: Read, Create/Edit | 閲覧・編集を許可する。削除は公開しない | 複数人で情報を更新したい |
| 公開：閲覧・作成／編集・削除 Public: Read, Create/Edit, Delete | 閲覧・編集・削除を許可する | 全員で広く管理する必要がある |
上表は共有範囲の説明です。どの設定でもプロファイルの制限が適用されます。所有者や上位ロールへのアクセスは別途考慮します。また、共有設定を変更できるモジュールは画面で確認してください。[1][5]
カスタム共有ルール：必要な相手に追加で共有する
全員への公開では広すぎる場合は、ロールやグループを対象に追加共有を設定します。たとえば案件を非公開にしたまま、営業担当者の案件を「営業支援グループ」へ閲覧共有する、といった考え方です。
ここで重要なのは、共有ルールはアクセスを追加するために使うことです。広く公開した設定の上に「この人だけ見せない」というルールを重ねる発想では、意図どおりに制限できません。必要な制限を基本設定でつくり、必要な相手へ共有を足していきます。[1][5]
グループ：部署をまたぐ共同担当にも使える
グループにはユーザー、ロール、ロールと配下、ほかのグループなどを組み合わせられます。ロール階層を変えずに、営業とサポートの一部メンバーで共通のレコードを扱いたいときにも役立ちます。
グループを作るだけで、全員の個人担当レコードが共有されるわけではありません。対応するモジュールでレコードの担当先をグループにするか、グループを対象とした共有ルールを設定します。操作権限は各ユーザーのプロファイルに従います。[2][5]
5. 営業チームに当てはめてみる
営業責任者1名と営業担当者2名で、案件を管理する例を見てみましょう。ここでは、全員が通常ユーザーで、案件の閲覧・作成／編集は許可し、削除は許可しないプロファイルを使います。
田中さん
山田さん営業担当者ロール
担当：案件A
佐藤さん営業担当者ロール
担当：案件B
| ユーザー | 案件A 山田さん担当 | 案件B 佐藤さん担当 | 案件の削除 |
|---|---|---|---|
| 田中さん 営業責任者 | 閲覧・編集できる | 閲覧・編集できる | できない |
| 山田さん 営業担当者 | 閲覧・編集できる | アクセスできない | できない |
| 佐藤さん 営業担当者 | アクセスできない | 閲覧・編集できる | できない |
表の前提：個人担当の案件、追加共有なし、グループ経由の共有なし、View All／Edit Allなどの全体権限なし。関連する顧客企業からのアクセスなど、モジュール間の共有の影響もないものとします。実際の設定では関連レコードも含めて確認します。[1][5]
上司になっても、禁止された操作はできません。
田中さんは部下の案件を参照できますが、プロファイルで削除を許可していないため、この例では削除できません。階層と操作権限を分けて考えると、設定が理解しやすくなります。
6. 設定は、業務の整理から順に進める
設定画面を開く前に、対象モジュールごとの「誰の情報を見るか」「どの操作を使うか」を決めておくと、迷いが減ります。次の順序がおすすめです。
- 利用範囲を表にする
営業担当者・営業責任者・営業支援などの役割ごとに、利用するモジュール、閲覧範囲、編集・削除・出力の要否を整理します。
- プロファイルを作成する
設定の「Profiles」で、必要な操作・項目・ツールを設定します。職種が同じ人は共通のプロファイルにすると、見直しやすくなります。
- ロール階層とユーザーを設定する
「Roles」で上位・下位の関係をつくり、プロファイルを関連付けます。「Users」で各利用者へロールを割り当てます。
- グループと共有ルールを設定する
共同担当が必要なら「Groups」を作成し、「Sharing Rules」でモジュールの公開範囲と追加共有を設定します。画面に再計算（Recalculate）等の反映操作がある場合は実行し、完了を確認します。
- 通常ユーザーで確認する
担当者本人・上司・同僚のテスト用アカウントで、それぞれ見えるレコードと操作を確認します。管理者だけで確認を終えないことが大切です。
ロールに権限を直接設定する方式もあります。この記事では、同じ操作権限を複数の役割で再利用しやすい「既存プロファイルの関連付け」を基本として説明しています。[3][6]
7. 異動・退職と、設定後の見直し
異動では、ロールとグループを両方確認する
営業部からサポート部へ異動した場合、ロールを変更するだけでなく、所属グループと追加共有の対象も見直します。以前の業務で付けたアクセスが残っていないか、確認しましょう。
退職では、利用停止とレコードの引き継ぎを分けて考える
ユーザーの無効化と、担当レコードの移管は別の確認事項です。OSS 8.4にはユーザーをInactiveにする処理と、ユーザー削除時に移管先を指定する処理があります。画面の操作に合わせて、利用状態と引き継ぎ先を確認します。[4]
運用上は、顧客企業・案件・問い合わせ・活動などの担当情報に加え、そのユーザーを参照する通知先やワークフローも確認しておくと、引き継ぎ漏れを減らせます。完全削除を行う場合は、必要な履歴の保存と移管結果を先に確認しましょう。
設定後に確認したいこと
- 担当者本人・上司・同僚で、レコードの見え方が想定どおりか。
- 一覧だけでなく、詳細・編集・関連一覧でも想定どおりに扱えるか。
- 非表示・読み取り専用にした項目が、必要な画面で意図どおりになっているか。
- 削除やエクスポートなど、許可していない操作が使えないか。
- 顧客企業と案件など、関連するモジュールの担当者や共有設定がアクセスに影響していないか。
- 管理者指定、全体権限、複数のプロファイル・グループから権限が広がっていないか。
「見えてはいけないものが見えない」だけでなく、「仕事に必要な情報が使える」ことまで確認して、設定を完了させます。
8. よくある質問
同じロールなのに、同僚の案件が見えないのはなぜですか？
共有設定がPrivateなら、同じロールというだけでは個人担当のレコードは共有されません。チームで閲覧する必要があれば、公開範囲やカスタム共有ルール、グループ担当を検討します。
案件を閲覧できるのに、編集できないのはなぜですか？
共有が閲覧のみになっている、プロファイルに編集権限がない、対象項目が読み取り専用になっている、といった理由が考えられます。レコード範囲・操作・項目の順で確認します。
上司のロールなら、削除もできるようになりますか？
ロールが上位でも、プロファイルで削除が許可されていなければ削除できません。管理者や全体権限などの条件も含め、通常ユーザーで実際の動作を確認してください。
グループに入れれば、メンバー全員の案件を見られますか？
グループに入るだけでは、そのメンバーが個人で担当するすべての案件が共有されるわけではありません。レコードをグループ担当にするか、共有ルールの対象に設定する必要があります。
顧客企業と案件は、同じ公開範囲にする必要がありますか？
共有設定はモジュール単位で考えられます。ただし、顧客企業との関連や従属モジュールへの共有が影響する場合があるため、設定後は顧客企業と関連案件の両方でアクセスを確認します。[5]
権限設計は、情報を活用するための土台
ユーザー管理では「誰が使うか」、ロールでは「組織のどこに位置するか」、プロファイルでは「何ができるか」、共有ルールでは「どのレコードを扱えるか」を整理します。
まずは営業担当者と営業責任者など、身近な役割から小さく設定し、通常ユーザーで確かめながら広げていきましょう。
Vtiger CRMを基盤に業務の仕組みづくりを検討している方は、vtplusのサービス紹介もご覧ください。