Dynamics 365とSharePointを管理している方なら、この2つを接続する方法について、わざわざ別のガイドを参照する必要はないでしょう。.
基本的な考え方は、もうお分かりですね。.
各チームは、顧客、アカウント、ケース、商談、その他の Dynamics 365 レコードを扱います。関連文書は SharePoint に保存されており、ユーザーは Dynamics 365 の画面内から、文書の共同編集やバージョン管理、操作を行うことができます。.
マイクロソフトは、この目的のために SharePoint とのネイティブ統合機能を提供しています。.
問題はたいていそこから始まる 統合が正常に動作した後.
ユーザーはDynamics 365レコードにはアクセスできるものの、そのSharePointドキュメントに予期せぬ形でアクセスできてしまう可能性があります。その結果、SharePointライブラリの管理が困難になる恐れがあります。メタデータに不整合が生じる可能性もあります。また、ユーザー、チーム、事業部門、ドキュメントの数が増えるにつれて、2つの環境の手動での整合性を維持することがますます難しくなります。.
だからこそ、良い Dynamics 365、SharePoint のベストプラクティス 初期設定の段階を超えていく必要があります。.
セキュリティモデル、ユーザー、文書、およびビジネスプロセスが変更された場合にどうなるかを検討する必要があります。.
ここでは、注意すべき5つのよくある落とし穴をご紹介します。.
Dynamics 365～SharePointで最もよくある落とし穴は何ですか？
注目すべき5つの課題は以下の通りです：
- Dynamics 365の権限が自動的にSharePointにも適用されると仮定する
- セキュリティとガバナンスを考慮せずにSharePointアーキテクチャを設計する
- 文書のメタデータを後回しに扱うこと
- 今日正常に動作している統合システムが、規模が拡大しても引き続き管理可能であると仮定する
- セキュリティモデルの同期ではなく、権限の不整合を手動で修正する
それぞれについて見ていきましょう。.
1. Dynamics 365の権限が自動的にSharePointにも適用されると仮定する
まず最初に、この前提に疑問を投げかけるべきです。.
Dynamics 365のセキュリティとSharePointの権限は、同じものではありません。.
Dynamics 365のレコードへのアクセス権を誰かに付与しても、それによってSharePointが対応するドキュメントに対して自動的に同じセキュリティ設定を適用するとは限りません。.
マイクロソフトのドキュメントでは、文書管理タスクに関する Dynamics 365 セキュリティロールと併せて、SharePoint の権限が明示的に記載されています。Dynamics 365 から SharePoint のコンテンツにアクセスするユーザーは、関連する SharePoint サイトおよび文書の保存場所に対して適切な権限を持っている必要があります。.
さて、こんな状況を想像してみてください。.
営業担当者は、Dynamics 365内のアカウントにアクセスできます。.
このアカウントには、SharePointに契約書、価格表、提案書、その他のファイルが保存されています。.
これで、営業担当者のDynamics 365へのアクセス権限が変更されます。.
SharePointの文書はどうなるのでしょうか？
もし「SharePointが自動的に把握しているはずだ」という答えなら、まさにその前提を検証する必要があるのです。.
この問題を回避する方法
Dynamics 365のセキュリティとSharePointの権限については、以下のように扱う 相互に関連しつつも区別される2つの層.
本番運用を開始する前に、次のようなテストシナリオを実施してください：
- ユーザーがレコードにアクセスする
- ユーザーのアクセス権が削除されました
- ユーザーがチームを変更する
- 記録の所有者が変わる
- ユーザーの事業部門へのアクセス権限の変更
- 特定のユーザーやチームとドキュメントを共有する必要があります
ドキュメントが開くかどうかだけをテストしてはいけません。.
次の条件を満たすかどうかをテストする 適切な人物なら開けるが、不適切な人物には開けられない.
Dynamics 365環境が拡大するにつれて、その区別はますます重要になっていきます。.
2. セキュリティやガバナンスを考慮せずにSharePoint構造を設計すること
SharePointアーキテクチャは、一見完璧に整理されているように見えても、後々問題を引き起こす可能性があります。.
まずはシンプルな構造から始めてみてはいかがでしょうか：
顧客 → アカウント → 書類
そうすれば、組織は成長していきます。.
事業部門ごとに必要なアクセス権限は異なります。チームは変化します。新しいドキュメントの種類が導入されます。SharePointに連携されるレコードが増えます。管理者は例外設定の作成を始めます。.
実装中は単純に見えた構造が、突然、管理しづらくなってしまう。.
SharePoint自体には、さまざまなスコープでの権限や権限の継承などを含む、詳細な権限モデルが備わっています。.
だからこそ、ドキュメントのアーキテクチャとセキュリティのアーキテクチャは、それぞれ独立して設計すべきではないのです。.
この問題を回避する方法
SharePoint 構造体を作成する前に、以下を定義してください：
- Dynamics 365のどのレコードに文書管理が必要か
- どのSharePointサイトおよびライブラリがそれらの文書を保管するのでしょうか
- どのユーザーやチームがそれらにアクセスすべきか
- 権限を継承すべき場所
- 例外が真に必要とされる場合
- どの管理者がこの構造を所有しているか
- アクセス変更が今後どのように扱われていくか
あなたの目標は、最も複雑な権限モデルを作成することではありません。.
これは、環境がもはや小規模ではなくなった場合でも、理解しやすく、管理しやすいものを作るためです。.
SharePoint Structure Creator Connecting Software では、ユーザーが定義したルールに基づいて、SharePoint のドキュメント ライブラリを自動的に作成または選択します。ライブラリは、レコード、期間、レコード名または ID の先頭文字、あるいはこれらのルールの組み合わせに基づいて構成することができます。.
これにより、すべてのドキュメントを1つのライブラリに蓄積させるのではなく、管理しやすいSharePoint構造に分散させることが可能になります。.
特に、CB Dynamics 365 to SharePoint Permissions Replicatorも併用している場合にはこれが重要になります。というのも、この2つのソリューションは互いに補完し合う課題に対処しているからです：
- Permissions Replicator → Dynamics 365のセキュリティ設定を、SharePointの権限設定と整合させたままにします。.
- SharePoint Structure Creator → SharePoint側の構造を、規模が拡大しても管理しやすいように設計されたルールに従って整理します。.
この区別は重要です。フォルダやライブラリの構造を改善しただけでは、それだけではアクセス権限は同期されません。構造とセキュリティは、同じスケーラビリティの問題の異なる側面を解決するものです。.
3. 文書のメタデータを後回しに扱うこと
ここにも、皆さんも心当たりがあるかもしれない問題がもう一つあります。.
お客様の書類は、SharePointに安全に保管されています。.
しかし、6か月後、ある人がこう尋ねた。
"「今四半期に期限が切れる、この地域の顧客との契約をすべて見つけていただけますか？」"
その文書は存在します。.
それらを見つけるのが難しいのです。.
ユーザーが手動でメタデータを入力する場合、同じ種類の文書であっても、人によって分類の仕方が異なることがあります。ある人は「契約書」と入力し、別の人は「顧客契約書」と入力し、また別の人はその欄を空白のままにしておくといった具合です。.
規模が大きくなるにつれて、SharePointライブラリの検索、フィルタリング、および管理はますます困難になる可能性があります。.
だからこそ、ドキュメントのメタデータは Dynamics 365 文書管理戦略, 、後付けではなく。.
この問題を回避する方法
どの Dynamics 365 フィールドが、対応する SharePoint 文書に対するコンテキストを提供すべきかを決定してください。.
例えば、こうだ：
Dynamics 365の記録
顧客：ABC株式会社.
地域：APAC
アカウント所有者：ジェーン・スミス
文書の種類：契約書
↓
SharePoint ドキュメントのメタデータ
顧客：ABC株式会社.
地域：APAC
所有者：ジェーン・スミス
文書の種類：契約書
その目的は、不必要な手作業による入力を減らし、文書に関する有用な文脈情報を維持することにあります。.
Connecting Softwareは、この分野に対して次のような対応を行っています。 Dynamics 365 CE用ドラッグ＆ドロップとメタデータ, これは、ドキュメントがアップロードされた際に、Dynamics 365フィールドの値をSharePointメタデータにマッピングするものだと説明されています。.
管理者であるあなたにとって、その価値は明白です。ユーザーは文書を手作業で分類する時間を削減できる一方で、SharePointのコンテンツには、Dynamics 365にすでに含まれているビジネス上の文脈がより多く保持されることになります。.
4. 現在正常に動作している統合システムが、規模が拡大しても引き続き管理可能であると仮定する
導入時には、その統合が完璧に機能するかもしれません。.
だからといって、環境が拡大した際に実際にどのように動作するかが必ずしもわかるわけではありません。.
今日は、こんなものが含まれているかもしれません：
- 管理しやすいユーザー数
- ごく少数のチーム
- いくつかの事業部門
- 限定されたドキュメントライブラリ
- 比較的シンプルなセキュリティ要件
時間が経つにつれて、ユーザー数が数千人に達したり、複数のチームが形成されたり、所有権の構造がより複雑になったり、文書数が大幅に増えたりする可能性があります。.
どんな変化にも、必ず結果が伴うものです。.
- ユーザーがチームを変更しました。.
- 事業部門が変更されます。.
- レコードの所有者が変わる。.
- 新たなセキュリティ要件が導入されました。.
- 統合体制もそれに追いつく必要があります。.
この問題を回避する方法
環境の管理が難しくなる前に、アーキテクチャに関する質問をしておきましょう：
- Dynamics 365とSharePointの間で、どのような情報をやり取りする必要があるのでしょうか？
- 一方向だけ動かす必要があるのか、それとも両方向とも動かす必要があるのか？
- Dynamics 365レコードが変更されると、どうなりますか？
- ユーザーやチームに変更があった場合はどうなりますか？
- 権限はどのように同期されるのですか？
- 不具合はどのように特定されるのでしょうか？
- 導入後の統合業務は誰が担当するのでしょうか？
ここで、専用の統合レイヤーが重要になってくるのです。.
Connecting Softwareの Connect Bridge Dynamics 365やSharePointなど、ビジネスアプリケーションを連携させ、それらの間で情報を同期させるように設計されています。.
重要な違いは、Connect Bridgeが以下の点に対応しているという点です。 より広範な統合および同期の要件. だからといって、Microsoftの標準的な文書管理機能を置き換える必要があるというわけではありません。.
5. セキュリティモデルの同期ではなく、権限の不整合を手動で修正する
こうした状況では、些細な管理上の問題がアーキテクチャ上の問題へと発展する可能性があります。.
チケットを受け取ります：
"「このユーザーは、アクセスすべきではない文書にアクセスできています。」"
SharePointの権限を修正してください。.
それから数週間後：
"「別のユーザーのアクセス権限が間違っています。」"
それも直しておいて。.
- そうして、チームは変わっていく。.
- ユーザーが所属部署を変更します。.
- レコードの所有者が変わる。.
また手動で権限を確認する羽目になっています。この状況に心当たりがあるなら、問題は単に：
"「SharePointのどの権限を変更すればよいですか？」"
むしろこう問うべきでしょう：
"「私のDynamics 365セキュリティモデルは、SharePointにどのように反映されるべきでしょうか？」"
それは根本的に異なる問題です。.
Connecting Softwareは、その機能により、このシナリオに特に焦点を当てています。 CB Dynamics 365 to SharePoint Permissions Replicator. 同社は、このソリューションについて、Dynamics 365のセキュリティモデルとSharePointの権限を同期させるものであり、ユーザー、チーム、事業部門、および各レベルでのアクセス権限といったセキュリティ情報を含むと説明している。.
ここで、統合戦略は、単に2つのアプリケーションを連携させるという段階を超えて、さらなる段階へと進むことができます。.
あなたは、以下の間により一貫性のある関係を作り出しています。 Dynamics 365のレコードにアクセスできるのは誰か そして SharePointの該当コンテンツへのアクセス権限を持つべき対象者.
Connecting SoftwareがDynamics 365～SharePointアーキテクチャにおいてどのような位置づけになるか
3つの異なる要件を区別することが重要です。.
1. 文書管理が必要です
Dynamics 365レコードに関連するドキュメントを単に保存・管理するだけでよいという場合は、MicrosoftのネイティブSharePoint統合機能で既に要件を満たせる可能性があります。Microsoftは、ユーザーがDynamics 365およびDataverseアプリケーションからSharePointドキュメントを操作できるドキュメント管理機能を提供しています。.
2. Dynamics 365のセキュリティ設定がSharePointに反映されている必要があります。
そこで CB Dynamics 365 to SharePoint Permissions Replicator 特に重要になってきます。.
管理者に2つの別々の権限モデルを継続的に維持するよう求めるのではなく、このソリューションはDynamics 365のセキュリティ設定とSharePointの権限設定を同期させるように設計されています。.
3. Dynamics 365～SharePointの同期範囲を広げる必要があります
文書管理にとどまらず、より広範なアプリケーション間の同期も必要となる場合は、, Connect Bridge 統合レイヤーを提供します。.
この区別は重要です。.
Connecting Softwareは、お客様がすでに利用しているシステムに取って代わるものではありません。.
そこで、生じうるギャップに対処しているのです それらのシステムの間で.
実用的なDynamics 365～SharePointチェックリスト
実装が完了したとみなす前に、次のことを自問してみてください：
セキュリティ
- Dynamics 365およびSharePointには、明確に定義された権限の責任範囲がありますか？
- ユーザーの Dynamics 365 アクセス権に変更があった場合、どうなりますか？
- ユーザーがチームや事業部を異動した場合はどうなりますか？
- ユーザーは、Dynamics 365のアクセス権限を持たない場合でも、SharePointのドキュメントにアクセスできますか？
文書の構成
- 御社のSharePointアーキテクチャは、現在および将来の事業構造に合わせて設計されていますか？
- 権限やドキュメントの保存場所は分かりやすいですか？
- 不要な権限例外は最小限に抑えていますか？
メタデータ
- Dynamics 365のどのフィールドをSharePointのメタデータにするべきでしょうか？
- ユーザーは、Dynamics 365にすでに存在する情報を手動で入力しているのでしょうか？
- ユーザーは、ドキュメントを簡単に検索・絞り込みできますか？
統合
- 2つのプラットフォーム間で、どのような情報を同期させる必要がありますか？
- その要件は一方向のものですか、それとも双方向のものですか？
- 変更や統合の失敗には、どのように対処しますか？
スケール
- ユーザー数、チーム数、レコード数、およびドキュメント数が増加しても、このアプローチは引き続き有効でしょうか？
- 手作業による管理はどの程度必要になるでしょうか？
複数の回答が不明確な場合、その統合は技術的には機能しているものの、完全にガバナンスが確立されていない可能性があります。.
CB Dynamics 365 から SharePoint への権限レプリケーターの動作を確認する
よくある質問
Dynamics 365は、SharePointと権限を自動的に同期しますか？
Dynamics 365～SharePointの文書管理には、どのような権限が必要ですか？
Dynamics 365およびSharePointの統合において、最もよく見られる課題は何ですか？
Dynamics 365でSharePointの権限に関する問題を回避するにはどうすればよいですか？
Dynamics 365およびSharePointでは、どのような場合に統合プラットフォームを使用すべきでしょうか？
メタデータは、Dynamics 365～SharePointの文書管理をどのように改善するのでしょうか？
結論として
Dynamics 365–SharePointの統合は、設定どおりに正常に動作していても、ガバナンス上の問題が残る可能性があります。.
本当の疑問は、単に次のようなものではない：
"「ユーザーは自分のドキュメントにアクセスできますか？」"
それは：
"「アクセス権限を管理し、文書の文脈をそのまま維持しつつ、Dynamics 365環境の変化に合わせてその関係を維持することは可能でしょうか？」"
そのためには、初期の統合段階にとどまらず、さらに先を見据えて考える必要があります。.
要件を満たす場合は、ネイティブの Dynamics 365–SharePoint 文書管理システムをご利用ください。その後、以下の点に関する不足部分について検討してください。 セキュリティの同期、メタデータ、およびより広範な統合.
セキュリティの整合性を図るため、Connecting Softwareの CB Dynamics 365 to SharePoint Permissions Replicator Dynamics 365のセキュリティモデルとSharePointの権限を同期させるという具体的な課題に対処しています。より広範なアプリケーションの同期については、, Connect Bridge 統合レイヤーを提供します。.
目的は、チームがすでに使用しているシステムを置き換えることではありません。.
その目的は、それら間の連携を管理・統制し、拡張しやすくすることにあります。.
ご自身の環境でこれがどのように機能するか確認してみませんか？
Connecting Softwareが、組織においてDynamics 365のセキュリティとSharePointの権限を整合させ、大規模な文書管理を簡素化する仕組みについてご紹介します。.
ソリューションの詳細を見る → Connecting Software
