CRM セキュリティモデルの作成

TOP > Dynamics CRM > CRMのカスタマイズ
- CRM セキュリティモデルの作成
- CRM 追加のセキュリティオプション

概要

ロールベース

職務内容に即したアクセス許可を定義するロールベースのセキュリティモデルを適用できる。

移行メモ（正誤）: 元ページの「セキュリモデル」は
「セキュリティモデル」の脱字と判断し、補った（以下同様の箇所も同じ）。

組織・チーム・ユーザ
- 組織・チームはグループ的なもの。
- 組織にはユーザ / チームを追加できる。
- チームにはユーザを追加できる。
- 組織・チーム・ユーザの作成
  - ユーザを作成する。
  - 組織構造を定義する部署を作成する。
  - チームを作成する。
セキュリティロールを作成する。
- 特権（アクセス許可）の設定
- アクセスレベルの設定
組織・チームにセキュリティロールを割り当てる。
- 組織にユーザを追加し、組織にセキュリティロールを割り当てる。
- チームにユーザを追加し、チームにセキュリティロールを割り当てる。
  チームを使用し 1 ～複数の部署のユーザをグループ化できる。
- ユーザ個人にセキュリティロールを割り当てる。
グループ的なものである組織・チームはソリューションに追加できない仕様。
ちなみに、セキュリティロールはソリューションに追加できる仕様。

移行メモ（正誤）: 元ページの「ユーザ個人にに」は「に」の重複と判断し、修正した。

レコードベース

レコードベースのセキュリティは、

個々のレコードに対してアクセス権を使用することで提供される。
エンティティ特権が有効な場合にのみレコードのアクセス権が適用される。

補足（2 つのモデルの関係）: この 2 つは並列ではなく、直列である。
ロール ベース（特権 × アクセス レベル）
  ↓ ここを通った上で
レコード ベース（個々のレコードのアクセス権）
「エンティティ特権が有効な場合にのみレコードのアクセス権が適用される」
という一文がそれを示している。
つまり、ロールで許されていないものは、
個別に共有しても見えない。
トラブルシューティングでは、まずロール側を疑うのが定石になる。

特権

特権（privilege）≒ アクセス許可
CRM では、Administrator 等の特別な権限ではなく単にアクセス許可を指している。
システム開始時に、580 を超える特権が事前に定義される。

エンティティ特権

エンティティに対して実行できる特権

エンティティとレコードに対するアクセス許可をグリッドで表現している。

タブ：エンティティのカテゴリ
縦：エンティティ
横：特権（アクセス許可）

	特権（アクセス許可）	説明
1	作成	レコード作成
2	読み取り	レコード表示
3	書き込み	レコード変更
4	削除	レコード削除
5	追加	別のレコードと関連付け。
6	追加先	エンティティと関連付け。
7	割り当て	レコードの所有権を移転。
8	共有	レコードのアクセス権を共有。
9	リペアレント	エンティティに異なる親を割り当て。

補足（「追加」と「追加先」の違い）: 混同しやすいが、
関連付けの方向が違う。
A を B に関連付ける場合、

A 側に「追加」 の特権

B 側に「追加先」 の特権

の両方が必要になる。
後述の「複数のアクセス権が必要な操作」の表でも
この対が現れる。
「関連付けができない」という問い合わせでは、
片側だけ見て判断しないことが要点になる。

各エンティティで使用できる特権

特定のエンティティの種類に対しての操作（アクション）実行のアクセス許可。
エンティティ別の特権
https://msdn.microsoft.com/ja-jp/library/gg309366.aspx

各エンティティで使用できる特権

エンティティに関連付けられない特権

https://msdn.microsoft.com/ja-jp/library/gg328200.aspx

UI操作

UI 操作は、複数のエンティティ特権を必要とする場合も多い。

例えば、営業案件の作成は以下の特権（アクセス許可）が必要になる。
- 作成
- 読み込み
ガイドとして、エンティティ特権がない場合、ボタンが表示されなくなる。

補足: 「特権がないとボタンが表示されない」という挙動は
親切である一方、「メニューに項目が出てこない」という問い合わせの
大半が権限不足という状況を生む。
エラーが出ないぶん原因に気づきにくいので、
権限を疑う習慣が要る。

その他の特権

アプリケーションの機能に関する特権（アクセス許可）

機能
- 印刷
- 重複レコードの統合
- Excel にエクスポート
- オフラインにする
指定可能なアクセスレベル
- "なし"
- "グローバル（組織全体）"
設定場所：
一部、［コアレコード］タブの［その他の特権］

補足（情報持ち出しの統制点）: 「印刷」「Excel にエクスポート」
「オフラインにする」は、データを CRM の外へ出す操作である。
これらが独立した特権になっているのは、
内部統制や情報漏洩対策の観点で制御できるようにするためで、
CRMのクライアント要件の
「企業のポリシーによってオフラインでの使用がサポートされていない場合」
という記述に対応する。

アクセスレベル

特権（アクセス許可）にはアクセスレベルを設定できる。
アクセスレベルは、特権（アクセス許可）がどの範囲の所有者に適用されるか的な制御をする。

	アクセスレベル	説明
1	グローバル（組織全体）	部署階層レベルに関係なく、組織のエンティティ（機能・データ）を使用可能通常は組織全体に対する権限を持つ責任者に対してのみ使用される。
2	ディープ（部署配下）	部署とその配下の部署のエンティティ（機能・データ）を使用可能通常は配下の部署全体に権限を持つ責任者に対してのみ使用される。
3	ローカル（部署）	自部署のエンティティ（機能・データ）を使用可能通常は部署全体に権限を持つ責任者に対してのみ使用される。
4	ベーシック（ユーザー）	ユーザ・共有・チームのエンティティ（機能・データ）を使用可能通常は営業やサービスの担当者に対して使用される。

補足（このモデルの要点）: 権限が
「何ができるか」（特権）× 「誰のデータに対してか」（アクセスレベル）
の 2 軸で表現されている点が Dynamics CRM のセキュリティモデルの核心である。

例えば「営業案件の読み取り」という 1 つの特権でも、

グローバル → 全社の案件が見える（役員）

ディープ → 配下部署の案件が見える（部長）

ローカル → 自部署の案件が見える（課長）

ベーシック → 自分の案件だけ見える（担当者）

と、同じ特権のまま見える範囲だけを変えられる。
役職の階層と部署階層が対応する日本の組織構造とは相性が良い。

指定可能なアクセスレベル

組織所有のエンティティには、"なし" or "グローバル（組織全体）"のアクセスレベルのみ指定可能。
ユーザ・チーム所有のエンティティには、5 つすべてのアクセスレベルを指定可能。

移行メモ: 上の表は 4 段階だが、本文は「5 つすべて」としている。
"なし" を含めて 5 つと数えていると思われる。
元ページの記載のまま残す。

一部のアクセスレベルを使用できない特権も存在する。
- ユーザレベルに設定できない特権（アクセス許可）
  - ユーザ
  - チーム
  - 設備 / 備品
- ユーザレベルにしか設定できない特権（アクセス許可）
  - 保存されているビュー
  - ユーザグラフ
  - ユーザエンティティの UI 設定

セキュリティロール

セキュリティロールとは、特権（アクセス許可）・アクセスレベルのグループ化。

ロールベースのセキュリティモデルで使用するセキュリティロールを使用する。
ユーザに 1 つ以上のセキュリティロールを割り当て
ユーザに特権（アクセス許可）・アクセスレベルを付与する。
1 ユーザに複数のセキュリティロールを割り当てられた場合、
- セキュリティロールの "OR"（合計）の特権（アクセス許可）・アクセスレベルが付与される。
- 同じアクセス許可がある場合、アクセスレベルは高い方を使用できる。
これにより、組織、職務、役職、プロジェクトの一時的ロール等に基づいて
ユーザへ与える特権（アクセス許可）・アクセスレベルの管理が容易になる。

移行メモ（正誤）: 元ページの「アクセク許可」は「アクセス許可」、
「一次的ロール」は「一時的ロール」、
「管理が用意になる」は「管理が容易になる」の誤記と判断し、修正した
（「アクセク許可」は本ページ内の他の箇所も同様に修正）。

補足（OR 合成であることの含意）: 複数ロールが OR で合成される
ということは、「あるロールで禁止する」ということができないことを意味する。
Azure 条件付きアクセスが
**ブロック優先（AND 合成）**であるのと対照的である。

したがって、権限を絞りたい場合は
強いロールを外すしかなく、
「基本ロール + 制限ロール」という設計は成立しない。
ロール設計では足し算だけで組み立てる必要がある。

ソリューションとセキュリティロール

ソリューションには、ルート部署のセキュリティロールのみ含めることができる。

既定のセキュリティロール

	ロール	説明
1	最高経営責任者	会社レベルで組織を管理するユーザー。
2	顧客サービス課長	地域またはチームレベルで顧客サービス活動を管理するユーザー。
3	顧客サービス担当者 (CSR)	すべてのレベルの顧客サービス担当者 (CSR)。
4	代理人	別のユーザーに代わって行動することを許可されたユーザー。
5	マーケティング課長	地域またはチームレベルでマーケティング活動を管理するユーザー。
6	マーケティングプロフェッショナル	すべてのレベルのマーケティング活動に関与するユーザー。
7	営業課長	地域またはチームレベルで営業活動を管理するユーザー。
8	営業担当者	任意のレベルの営業担当者。
9	フィールドサービス課長	サービスの予定を計画するユーザー。
10	フィールドサービス担当者	サービスを管理するユーザーで、リソースと作業時間を必要とするユーザー。
11	サポートユーザー	顧客サポートエンジニアであるユーザー。
12	システム管理者	任意のレベルでプロセスを定義して実行するユーザー。
13	システムカスタマイザ	Microsoft Dynamics CRM のエンティティ、属性、関連付け、およびフォームをカスタマイズするユーザー。
14	マーケティング担当副社長	部署レベルでマーケティング活動を管理するユーザー。
15	営業担当副社長	部署レベルで販売組織を管理するユーザー。

補足: 既定ロールが
マーケティング /
営業 /
サービスの 3 モジュールと
課長 / 担当者という 2 階層で構成されている点に注目したい。
Dynamics CRM の 3 モジュール構成が、
そのままロール設計にも反映されている。

システム管理者

すべての既定のロールを変更可能。

その他、以下の特別な性質を持つ。

少なくとも 1 人がシステム管理者をもつ必要がある。
エンティティ、機能に対するグローバル（組織全体）レベルの全アクセス許可。
ただし、一部ベーシック（ユーザー）レベルだけが適用される例外がある。
- 保存されているビュー
- ユーザグラフ
- ユーザエンティティの UI 設定
追加されたカスタムエンティティに（組織全体）レベルのアクセス許可
（このアクセス許可は、システムカスタマイザーにも付与される）
システム管理者フィールドセキュリティのメンバ
- セキュリティで保護されたすべてのフィールドに対する全アクセス許可
- フィールドセキュリティプロファイルを管理し、
  フィールドレベルセキュリティを実装。

用例

以下のケースで使用する。

経験の少ない小規模な組織で使用。
プロジェクトの初期段階のデモ・実証で使用。

変更

ビジネス要件から変更が必要な場合、以下の 3 つの変更方法がある。

既定のロールを変更
ユーザ・チームに割り当てる既定のロールを変更
既定のロールをコピー
ロールのコピー後にカスタマイズに使用する。
- 新しい名前を指定可能。
- 部署は指定不可能（同じ部署）
- 継承されたロールのコピーも作成可能。
- コピー元とコピー先のロールに関連は無い。
- コピー元との比較（差分の確認）が可能。
  既定のロールのカスタマイズ時に便利。
ロールを新規作成
- 主要なロールに追加する特権（アクセス許可）を持つロールを作成する。
- チームにセキュリティロールを割り当てれば、
  ロールを持つユーザの識別が容易、管理し易い。
注意：セキュリティロールは部署を変更できない。

補足（既定ロールを直接変更しない方がよい理由）: 3 つの方法のうち、
**「既定のロールをコピーしてカスタマイズ」**が実務では無難である。
既定ロールを直接変更すると、

製品の更新で既定ロールが変更された場合に競合しうる

元に戻せなくなる（比較の基準が失われる）

新規に作った組織との差分が追えなくなる

という問題が生じる。
本ページが「コピー元との比較（差分の確認）が可能」と
わざわざ挙げているのは、この運用を前提にしているためと読める。

部署

階層構造でアクセス許可のスコープを制御する境界として機能する。
レポートのクエリで部署を使用して結果をフィルタするなどができる。

ルート部署

組織を作成する際に展開プロセスにより最初の部署として作成される。
- 展開プロセス
  - セットアッププログラム（初回）
  - 展開マネージャ（2 つ目以降の組織）
ルート部署の特徴
- 組織と同じ名前で作成される。
- この名前は後に変更できる。
- 1 つだけ存在する。
- 上位部署は作成できない。
- 削除や無効化はできない。
- 他の部署は、ルート部署の派生。

作成

ポイント

小規模：1 部署でも OK
大規模：個別の部署が必要になることもある。
- 会社の組織図を参考にする（ただし、複製では NG）。
- 部署を、事業部、部門、子会社などに読み替えることもできる。
部署を、スキル・役職・責任などユーザのグループに読み替えることもできる。
（ただし、セキュリティロールを併用することもできる）

補足（「組織図の複製では NG」の意味）: 部署は
アクセス許可のスコープを決める境界であって、組織図そのものではない。
組織図をそのまま写すと、

組織変更のたびに部署の再編が必要になる（後述のとおり、
部署を移動するとセキュリティロールが削除される）

階層が深くなり、ディープ／ローカルの使い分けが煩雑になる

という運用負荷を招く。
「データの見える範囲を分ける必要があるか」で切るのが原則で、
見える範囲が同じなら 1 部署にまとめてよい。
横断的なグループ化は次節のチームで行う。

方法

Microsoft Dynamics CRM
［設定］→［管理］→［部署］→［新規］

入力
- 新しい部署の名称
- 上位の部署
- , etc.

更新

ポイント（更新）

ルート部署を除いて部署は移動・削除（無効化）が可能。

方法（更新）

Microsoft Dynamics CRM
［設定］→［管理］→［部署］

移動の場合、
- 部署を選択し、メニューバーから［その他の操作］→［上位の部署の変更］
- 部署をダブルクリックで開き、ツールバーから［操作］→［上位の部署の変更］
- ※
  - 下位部署も合わせて移動される。
  - 循環する関係になるように移動できない。
  - 継承されていたセキュリティロールは削除される。
無効化の場合、
- 部署を選択し、メニューバーから［その他の操作］→［有効にする］・［無効にする］
- 部署をダブルクリックで開き、ツールバーから［操作］→ 有効または無効的な。
- ※
  - 再編準備などで使用する（作成後直ちに無効に、再編後に有効化）。
  - ユーザが所属する部署が無効化されると、ユーザは CRM にアクセスできなくなる。
削除の場合、
- 下位部署が存在しない状態にする。
  - 下位部署を削除する。
  - 下位部署の上位部署を変更する。
- 次に無効化（非アクティブ化）する。
- Microsoft Dynamics CRM →［設定］→［管理］→［部署］
  ビューから［非アクティブな部署］を選択、対象の部署を開き、コマンドバーで［削除］をクリック。
- ※
  - 削除した場合、再び有効化できないので注意。

部署とセキュリティロール

セキュリティロールは部署内で作成・保持される。
セキュリティロールは部署を変更できない。
部署のセキュリティロールは派生の下位部署に継承される（継承されたロール）。

ユーザ管理

大規模な組織では日常的に行われている（入・退社、移動・昇進）。
ユーザ管理を便利にする多数の機能があり、セキュリティ管理とユーザ管理が分離されている。
担当部署
- 中央の運営機関
- 支社・部門のシステム管理者・管理職

認証機構

Dynamics CRM 自体は認証機構を提供しない。

展開によって、以下の認証機構を使用する。

参考：クレームベース認証の用語

Online

Windows Live ID から、MOSP（Microsoft Subscription Program）に変更。
全てのサブスクリプションベース SaaS に単一の認証プラットフォームが提供される。

内部的には、Azure AD を

STS（Security Token Service）
IdP（Identity Provider）

として使用している。

移行メモ（正誤）: 元ページの「MicrosOft」は「Microsoft」の
大文字小文字の誤りと判断し、修正した。
また、Azure AD は現在 Microsoft Entra ID に改称されている。

オンプレ

Intranet 展開
AD DS のみ使用可能。
Internet 展開
AD FS やサードパーティ製の STS（Security Token Service）を使用可能。
従って、任意の IdP（Identity Provider）を使用可能。

補足: 「Dynamics CRM 自体は認証機構を提供しない」というのは重要な設計判断である。
認証を外部（AD DS / AD FS / Entra ID）に委ね、
CRM は認可（誰が何を見られるか）に専念するという分離になっている。
CRMインターネット展開用の構成（IFD）が
認証方式の切り替えの話に終始するのも、この分離のためである。

ユーザ管理機能

ユーザ作成
ユーザ有効化 / 無効化
ユーザの上司特定
チーム作成
ユーザをチームに割当
ユーザ / チームへのセキュリティロール割当
部署間でのユーザ / チームの移動
既定で自身のプロフィールをメンテできないが、
適切な特権（アクセス許可）を追加して、
住所・電話番号などのメンテナンスを可能に設定可能。

ユーザの追加 / 削除

追加

追加時に自動的に有効になる。

削除

削除はできない。無効化のみ可能。
サインイン不可、ライセンス不要になる。
ユーザ所有のレコードは、システム所有になる。
レコードを有効なユーザに再割当てする適切な方法の検討が必要。
無効化予定のユーザとワークフロー / プロセスの関連を考慮
例：サポート案件のルーティングや、電子メールメッセージの送信
- 特定の情報カテゴリの重要度の高いサポート案件は常に特定の技術者に割当てられる。
- 顧客のサポート案件は取引先企業レコードで指定されているサービス担当にルーティングされる。

補足（「削除できない」ことの意味）: ユーザを物理削除できないのは、
レコードの所有者・作成者・更新者としての参照が残るためである。
監査の観点では正しい設計だが、運用上は

退職者のアカウントが増え続ける

ワークフローの割り当て先が無効ユーザのまま残る

という問題が起きる。
本ページが「無効化予定のユーザとワークフロー / プロセスの関連を考慮」と
注意しているのはこの点で、
退職処理の手順にワークフローの割り当て先の棚卸しを含める必要がある。

チーム管理

Windows のグループ的なもの。
基本的には、組織階層は部署を使用。
プロジェクトチームなどはチームを使用。

種類

所有者チーム

レコードの所有者
実際のセキュリティロールを割当てる。

アクセスチーム

レコードを所有できない。
セキュリティロールを割当られない。
複数のチーム間でレコードを共有するためのチーム
詳しくは「アクセスチームテンプレート」を参照。

チーム種類の変換

可能：所有者チーム → アクセスチーム
不可能：所有者チーム ← アクセスチーム

メリット

セキュリティロール（チームの利点）

部署の組織階層に限定されない
チームレベルのセキュリティロールモデルの管理が可能。

共有（チームの利点）

個人・個人のより効率が良い。
任意のユーザが自分に関連するチームの情報を参照できる。

管理が容易

チームのセキュリティロールの管理
チームのメンバシップの管理

ワークフロー / プロセス

チームをキューにリンク、チームのキューを作成できる。
所有者チームがベーシック（ユーザー）アクセスレベルの読み込みアクセス許可を持っていれば
チームはそのエンティティレコードを所有でき、チームへのルーティングが可能になる。

既定のチーム

部署との関連

部署を作成すると、部署名と同じ名称の "既定のチーム" が自動的に作成される。

削除不可能
名称変更不可能
部署異動不可能

メンバシップ

"既定のチーム" には、

部署の全ユーザが含まれる。
部署のメンバシップを変更した場合、
"既定のチーム" のメンバシップも自動的に反映される。
"既定のチーム" のメンバシップは変更できない。

セキュリティロール（既定のチーム）

"既定のチーム" に派生しないセキュリティロールを割当てるときに便利。
"既定のチーム" に派生しないセキュリティロールを割当てたくない場合は、
"既定のチーム" を所有者チームからアクセスチームに変換する。

チームの作成

チームは 1 つの部署と関連付けが可能。
チームはメンバとしてユーザを追加・削除可能。
- ユーザの所属部署を問わず組織の任意のユーザを追加可能。
- 1 人のユーザは複数のチームに所属可能。
チームのネストモデルはサポートしていない。
チームの共有機能で、チーム内のユーザとレコード共有が可能。

補足（部署とチームの使い分け）: 前述の
「組織図をそのまま部署にしない」という原則と合わせると、
次のような役割分担になる。

部署チーム

構造階層（ツリー） フラット（ネスト不可）

所属ユーザは 1 つだけ 複数に所属可

部署をまたぐ不可可

用途見える範囲の境界プロジェクト、横断的な役割

つまり、縦の統制は部署、横のつながりはチームという設計になる。
組織変更のたびに部署を触るのではなく、
変わりやすいものはチームで表現するのが運用しやすい。

	部署	チーム
構造	階層（ツリー）	フラット（ネスト不可）
所属	ユーザは 1 つだけ	複数に所属可
部署をまたぐ	不可	可
用途	見える範囲の境界	プロジェクト、横断的な役割

チームのメンバシップ管理

チームから所属ユーザを選択

Microsoft Dynamics CRM
［設定］→［管理］→［チーム］

［所属部署のチーム］からチームを選択
コマンドバーで［メンバーの追加］
［チームにメンバーを追加］ダイアログで 1 ～複数のユーザを追加。

ユーザから所属チームを選択

Microsoft Dynamics CRM
［設定］→［管理］→［ユーザ］

ユーザレコードをダブルクリック。
- 削除：
  - ナビゲーションバーの［チーム］をクリック。
  - 所属チームの一覧から 1 ～複数のチームを選択し［メンバーの削除］をクリック。
- 追加：
  - ナビゲーションバーの［既存のチームの追加］をクリック。
  - チーム名を入力するか、チームのレコードを入力して追加

他のユーザ / チームに単一レコードに特定のアクセス権を与える。
特定のエンティティの全てのレコードでは無く個々のレコードに適用される。
共有を設定するユーザと同じ特権（アクセス許可）で共有のアクセスが構成される。
セキュリティロールのようにシステム管理者でなくても、共有は全てのユーザが設定可能。
（共有の設定は、セキュリティロールを通じてベーシック（ユーザー）のアクセスレベルが必要）
アクセスレベルは適用されない。

チームとの共有

ユーザとの共有と比べ以下のメリットがある。

より少ない作業で共有アクセスを許可できる。
チームのメンバシップ管理と連動する。
性能が向上する（共有設定は PrincipalObjectAccess テーブルに格納）
部署内部での共有は、既定のチームを使用する。

移行メモ（正誤）: 元ページの「性能のが向上する」は
「性能が向上する」の誤記と判断し、修正した。

補足（PrincipalObjectAccess が肥大化する）: 共有は
「誰が」「どのレコードに」「どの権限を」持つかを 1 行ずつ記録するため、
ユーザ単位で共有すると行数が
ユーザ数 × レコード数で膨らむ。
チーム単位で共有すれば チーム数 × レコード数に抑えられる。
本ページが「性能が向上する」としているのはこのためで、
大規模環境では性能問題の直接の原因になり得る。

ビュー、グラフ、ダッシュボードの共有

メリット
- スキルのあるユーザがコンポーネントを作成・共有することで労力を最小限にできる。
- ユーザはメンテナンスを続け、使用の許可や変更の許可ができる。
  - 個別のカスタマイズは独自コピーを作成して行うことができる。
共有の設定
- ［高度な検索］ダイアログボックスの［保存されているビュー］のセクションで個人用ビューを共有。
- ［グラフウィンドウ］の［その他の操作］メニューで、個人用グラフを共有。
- ・・・、個人用ダッシュボードを共有。

レコードの共有

レコードを選択した状態で、
コマンドバーの［その他のコマンド］をクリックし［共有］をクリック
表示されているダイアログボックスで［ユーザまたはチームの追加］をクリック
1 つ以上のユーザ / チームを選択リストに追加し、［追加］をクリック
ダイアログボックスに表示されているユーザ / チームに
チェックボックスを使用して特権（アクセス許可）を割当てる。

セキュリティロールの割当て

［Microsoft Dynamics CRM］→［設定］→［管理］

ユーザへの割当て

→［ユーザ］

追加（割当て）
- ユーザのレコードを選択
- コマンドバーで［その他のコマンド］→［ロールの管理］
- ［ユーザーロールの管理］ダイアログボックスで
  ユーザに割り当てるロールのチェックボックスをオンにして［OK］をクリック。
確認、削除
- ユーザのレコードをダブルクリックして開く
- ナビゲーションバーから［セキュリティロール］を選択してクリック
- ロール一覧を確認、削除する場合はロール一覧からロールを選択し［ロールの削除］をクリック

チームへの割当て

→［チーム］

追加（割当て）
- チームのレコードを選択
- コマンドバーで［その他のコマンド］→［ロールの管理］
- ［チームロールの管理］ダイアログボックスで
  チームに割り当てるロールのチェックボックスをオンにして［OK］をクリック。

部署からユーザ / チームを移動

Microsoft Dynamics CRM
［設定］→［管理］→

ユーザの移動