Dynamics 365にSharePointの統合を設定する

Dynamics 365 Customer Engagement には、ネイティブのサーバーベースの SharePoint 統合機能が組み込まれています。この機能を設定すると、ユーザーは Dynamics 365 のレコードからドキュメントにアクセスできる一方で、実際のファイルは Dataverse ではなく SharePoint に保存されます。.

一般的な Dynamics 365 および SharePoint オンライン環境の場合、セットアップには主に 5 つの手順があります：

1. サーバーベースの SharePoint 統合を有効にする
2. SharePointサイトを接続してください
3. 必要な Dynamics 365 テーブルに対してドキュメント管理を有効にする
4. 「SharePoint」のフォルダ構造を選択してください
5. Dynamics 365とSharePointの両方から統合機能をテストしてください

設定自体は比較的簡単です。より慎重に検討すべき点はセキュリティです。.

Dynamics 365 および SharePoint には 個別の権限モデル. ネイティブ統合を行っても、SharePointのドキュメント権限が自動的にDynamics 365のレコードアクセス権限に従うようにはなりません。ドキュメントへのアクセス権限を対応するDynamics 365レコードに合わせる必要がある場合は、別途対応する必要があります。.

この記事は2020年8月に初めて公開され、2026年9月に最終更新されました。.

このネイティブ統合により、営業やカスタマーサービスなどのDynamics 365カスタマーエンゲージメントアプリと、SharePointドキュメント管理が連携します。.

ユーザーは、アカウント、連絡先、商談、ケース、またはその他の有効化されたテーブルの「ドキュメント」領域を開き、そのレコードに関連付けられたドキュメントを操作できます。ファイル自体は SharePoint に保存されており、バージョン履歴、共同作業、ドキュメントのメタデータなど、SharePoint の機能を利用できます。.

これにより、責任の分担が明確になります：

• Dynamics 365: 業務記録と、その文書保管場所との関係
• SharePoint: 文書そのものと、SharePointの文書管理機能

重要な例外の一つが添付ファイルです。Dataverseにすでに保存されているメモやメールの添付ファイルは、統合を有効にしたからといって自動的にSharePointに移動するわけではありません。これらを移行するには、別途の手順やソリューションが必要となります。.

セットアップウィザードを開く前に、いくつか決めておくべきことがあります。.

SharePoint Online を利用するには、Dynamics 365 環境と SharePoint サイトが同じ Microsoft 365 テナント内にある必要があります。Microsoft は、SharePoint サイトを設定する際にこの条件を満たしているかどうかを確認します。.

また、Dynamics 365 および SharePoint において、適切な管理権限も必要となります。Microsoft の現在のドキュメントによると、ドキュメント管理の設定には「システム管理者」または同等の権限が、SharePoint との統合を有効にするには「グローバル管理者」の権限が必要とされています。.

ご利用になりたい SharePoint サイトは、すでに存在している必要があります。.

単に「できるから」という理由だけで、あらゆる場所で文書管理機能を有効にしてはいけません。.

代表的な候補としては、次のようなものがあります：

• アカウント
• 連絡先
• 機会
• 事例
• 引用
• プロジェクトまたはカスタムテーブル

実際にドキュメントが必要なテーブルから着手することで、結果として得られるSharePoint構造の理解と管理が容易になります。.

SharePointの構造を設計する前に、1つだけ質問をしてみてください：

あるユーザーがDynamics 365レコードへのアクセス権を失った場合、そのレコードに関連する文書へのアクセス権も失うべきでしょうか？

もし答えが「はい」なら、権限の設定は後回しにはできません。セットアップが終わってから、この件について改めて取り上げます。.

現時点で最も明確な手順は、Power Platform 管理センターを経由する方法です。.

移動先：

「管理」→「環境」
（ご利用の環境を選択してください）
設定 → 連携 → 文書管理の設定

選択 サーバーベースの SharePoint 統合を有効にする.

ウィザードが起動し、接続の有効化手順を案内します。Microsoftの現在のドキュメントでは、このPower Platform管理センターの手順が紹介されています。.

サーバーベースの統合は、Dynamics 365およびDataverseのモデル駆動型アプリにおけるSharePointドキュメント管理に対する、マイクロソフトの現在のアプローチです。.

ウィザードから、SharePointサイトの設置場所を尋ねられます。.

標準的な Microsoft 365 の展開については、以下を選択してください。 オンライン.

Dynamics 365で使用したいSharePointサイトのURLを入力してください。例：

https://yourtenant.sharepoint.com/sites/yoursite

Dynamics 365 は URL の有効性を確認します。SharePoint Online の場合、そのサイトが同じ Microsoft 365 テナントに属しているかどうかも確認します。.

検証に失敗した場合は、まず基本的な点を確認してください：

• このURLは正しいですか？
• そのサイトは存在しますか？
• 管理者はそれにアクセスできますか？
• SharePointサイトは正しいテナントにありますか？

この統合機能では複数のSharePointサイトをサポートできますが、初期設計をシンプルに保つことで、通常は管理が容易になります。.

サーバーベースの統合を有効にしたら、次の画面に戻ります。 文書管理の設定.

SharePointの文書管理の対象とするDynamics 365テーブルを選択してください。.

例えば、こうだ：

• アカウント
• 連絡先
• 機会
• 事例
• リード

Microsoft では、特定のテーブルに対してのみドキュメント管理機能を有効にすることができるため、導入当初からすべてを有効にする必要はありません。.

要件が変わった場合は、後で戻ってきて他のテーブルを追加することもできます。.

次に、SharePointのURLを検証し、Dynamics 365がドキュメントの保存場所をどのように整理するかを指定してください。.

標準設定では、次のように、選択した親テーブルを基にドキュメントの配置を構成するか、 アカウント 或いは 連絡先, 、あるいはよりフラットな構造を採用すること。. 

～に基づく構造 アカウント その結果、概念的には次のようなものになる可能性があります：

アカウント / Contoso / 連絡先 / ジョン・スミス

A 連絡先-ベースの構造では、代わりに主に「連絡先」を中心に文書を整理することになります。.

親テーブル構造を選択しない場合、レコードフォルダはよりフラットな構成で並列に配置されることになります。.

Dynamicsでは、ドキュメントの保存場所を一意にするために、フォルダ名に識別子を付加します。SharePointを直接閲覧した際には、あまり見栄えが良くないかもしれませんが、これにより、同じ名前を持つ2つのDynamicsレコードが重複することを防ぐことができます。.

構造を決める前に、ユーザーがDynamics 365以外の場所でドキュメントをどのように見つけるかを考えてみてください。50件の勘定科目であれば問題なさそうに見える設計でも、50,000件になると使い勝手が悪くなる可能性があります。.

ウィザードの手順を完了し、Dynamics 365に必要なSharePointのドキュメント保存場所を作成させます。.

ウィザードが成功を報告しても、そこで停止しないでください。.

有効化したテーブルのいずれかについて、Dynamics 365レコードを開き、次の場所へ移動します。 書類の提出先.

テスト用の文書をアップロードしてください。.

以下の点を確認してください：

• 「ドキュメント」エリアが利用可能です；;
• ファイルのアップロードは正常に完了しました；;
• そのドキュメントは SharePoint に保存されています。;
• 「SharePoint」というフォルダが作成されました。.

次に、SharePointに直接移動して、同じドキュメントを探してください。CRMソフトウェアブログのセットアップ手順ガイドでは、これを基本的な確認手順として採用しています。.

ただし、本番環境の場合は、テストをもう1つ追加し、管理者だけでなく、代表的なユーザーを対象にテストを行うようにしてください。.

例えば、次のように使用します：

• 記録保持者；;
• チームを通じてアクセス権を持つユーザー；;
• 読み取り専用ユーザー；;
• そのレコードへのアクセス権限を持つべきではないユーザー。.

Dynamics 365およびSharePointの直接リンクの両方を通じて、アクセスをテストしてください。.

この2つ目のテストは、ネイティブ統合の最大の限界を浮き彫りにするため、重要です。.

Dynamics 365 と SharePoint では、統一された認証モデルは採用されていません。.

Dynamics 365 および Dataverse は、次のような要素に基づいてレコードへのアクセスを判断することができます：

• セキュリティロール；;
• 事業部門；;
• 所有権の記録；;
• 所有者およびアクセス管理チーム；;
• 記録の共有；;
• 階層型セキュリティ。.

SharePointでは、サイト、ライブラリ、フォルダ、およびドキュメントへのアクセス権を個別に管理します。.

ネイティブ統合では、これら2つのセキュリティモデルは自動的に同期されません。これは、MicrosoftコミュニティでDynamics管理者が指摘している問題でもあります。つまり、ユーザーのDynamics 365の権限では関連レコードへのアクセスが許可されなくなっているにもかかわらず、そのユーザーがSharePointを介してドキュメントにアクセスできてしまう可能性があるのです。.

たとえば、あるアカウントの所有者が変更され、営業担当者がDynamics 365でそのアカウントへのアクセス権を失った場合を想定します。.

その営業担当者が、対応するドキュメントの保存場所に対する SharePoint 権限を依然として保有している場合、Dynamics 365 の所有権を変更しただけでは、SharePoint のアクセス権は削除されません。.

その逆の問題も起こり得ます。ユーザーがDynamics 365レコードへのアクセス権限を持っているにもかかわらず、SharePointが必要なアクセス権を付与していないため、そのドキュメントを開こうとした際にアクセスエラーが発生することがあります。.

これは、マイクロソフトの統合機能に不具合があるという意味ではありません。つまり、2つのプラットフォームは依然として別々の認証システムとして運用されているということです。.

シンプルで安定したセキュリティ要件であれば、カスタム自動化は妥当なアプローチとなり得ます。.

たとえば、商談の所有者に、対応する「SharePoint」フォルダへのアクセス権を付与するとともに、あらかじめ定義された営業グループにもアクセス権を付与するルールを作成することができます。.

この問題は、再現しようとすると現れます Dynamics 365へのアクセスが有効, 、単一の単純なルールというよりは。.

自動化の際には、以下の点を考慮する必要があるかもしれません：

• 所有権の変更；;
• チームのメンバーシップ；;
• 共有および共有解除されたレコード；;
• セキュリティロールの変更；;
• 事業部門の変更；;
• 権限の付与だけでなく、権限の削除も。.

独自の実装では、エラー処理、監視、および調整も必要です。アクセス権の付与時の自動化処理は成功したものの、その後そのアクセス権を取り消すべきタイミングで処理に失敗した場合、ユーザーが意図したよりも長くドキュメントへのアクセス権を保持し続ける可能性があります。.

そのため、カスタム Power Automate フローは、意図的にシンプルに設計された権限モデルではうまく機能しますが、SharePoint へのアクセスが Dynamics 365 のセキュリティ設定を常に反映することが求められる場合、その保守は著しく困難になります。.

その整合性が必須となる環境においては、, CB Dynamics 365 to SharePoint Permissions Replicator これは、関連するDynamics 365のアクセス権限の変更を、関連するSharePointのドキュメントの保存場所に反映するように設計されています。.

もう1つの設計上の考慮点は、独自のアクセス権が設定されるフォルダの数がどれくらいかということです。.

一つの方法は、Dynamics 365のレコードごとに個別のフォルダを作成し、そのフォルダに固有のアクセス権限を割り当てることです。技術的には、この方法は機能します。しかし、大規模に展開する場合は、事前の計画が必要です。.

SharePoint Online は最大 リストまたはライブラリごとに 50,000 の固有の権限スコープ, 、また、マイクロソフトは、その数を以下に抑えることを推奨しています 5,000 最高のパフォーマンスを得るために。.

Dynamicsのレコード数が数万件に達すると予想される場合は、レコードごとに一意に保護されたフォルダを1つ用意するという方法が、単一のライブラリ内で無制限に拡張可能であると想定しないようにしてください。.

可能な場合は：

• 継承された権限を使用する；;
• 安定したユーザーグループにはグループ機能を活用する；;
• アーキテクチャ上の観点から妥当である場合は、コンテンツをライブラリやサイトごとに分割する；;
• 本番運用を開始する前に、一意に保護された場所の数を推定してください。.

Microsoftの標準的なDynamics 365ドキュメント配置構造よりも、より体系的なSharePoint階層構造が必要な場合は、次のようなプロビジョニング手法が考えられます。 SharePoint Structure Creator 必要なフォルダやライブラリを一貫して作成できます。.

フォルダ構造とアクセス権は関連する設計上の決定事項ですが、それぞれが解決する課題は異なります。より適切な階層構造を構築したからといって、それだけでSharePointのアクセス権がDynamics 365と整合するわけではありません。.

ユーザーに統合機能を公開する前に、以下の点を確認してください：

• 接続された SharePoint サイトおよびドキュメント ライブラリは、Dynamics 365 ドキュメントの機密性および共同作業の要件に適している。;
• このフォルダ構成は、関係者の承認を得ており、想定されるアカウント数、連絡先数、および文書数に対して検証が完了しています。;
• 代表的なユーザーを対象にテストが行われました；;
• SharePointへの直接アクセスとDynamics 365へのアクセスについて、それぞれテストが行われました；;
• データの保持、外部への共有、およびその他のSharePointガバナンス要件が考慮されています；;
• SharePointによるドキュメントへのアクセスが、Dynamics 365によるレコードへのアクセスに続く必要があるかどうかを決定しました；;
• 権限の整合性が必要な場合、アクセス権の付与と解除の両方についてテストが行われています；;
• 本番稼働後は、誰かが監視とトラブルシューティングを担当する。.