マイクロソフトナレッジナゲットへようこそミルコピーターズです 今日のテーマはよく混同されがちなものですデータバースとは一体何でしょうか データベースなのかアプリなのかあるいは it 担当者だけが知っていれば良いダイナミクス365の隠れたサービスなのでしょうか最もシンプルな定義はこうです データバースは多くのダイナミクス365エクスペリエンスを支える共通のデータ基盤ですダイナミクス365オフィスビルだと考えてみてください 営業やカスタマーサービスなどのアプリは人々が働く部屋であり

ですこのエピソードの終わりにはダイナミクスのデータがどこに存在し 一人の顧客情報の更新がどのように営業活動自動化レポートに反映されるかがわかりますしかし製品名に触れる前にまずはこれが解決するビジネス上の混乱から見ていきましょう 共通の場所別々のコピーを持つ代わりに営業チームサポートチーム経理チームがある会社を創造してください 営業は顧客の詳細をスプレッドシートで管理していますサポートは別のケース管理ツールで作業しています経理は独自のシステムに顧客名を持っています 誰かはメールのやり取りを共有メールボックスに保存しまた別の人は誰にも見つけられないホルダーにメモを保管しています 同じ顧客が今や5つの場所に存在しています各チームは自分の目の前の作業しか見ていないためその設定は最初は普通に感じられます しかし問題はここからです顧客が電話番号住所会社名または主要な連絡先を変更した途端問題が始まります営業がスプレッドシートを更新してもサポートには反映されず 経理は古い住所に書類を送り続けてしまいますすると誰かがリストをエクスポートして手作業で修正しメールで共有した結果 突然3人がそれぞれ自分のコピーこそが正しいと信じ込むことになりますどのリストを信頼すべきでしょうか その疑問が皆さんが考える以上に時間を無駄にしていますスタッフは記録の称号のために作業を止めます 管理職はなぜレポートが営業システムと一致しないのかを尋ねますサポート担当者は別の場所にはすでに少し異なる詳細情報が存在している顧客のために新しい案件を作成してしまいます誰も混乱を起こそうとしているわけではありません 混乱の原因はコピーにあります20年前は別々のシステムは別々のサーバー別々のデータベース そして独自の情報を管理する別々のチームを意味していましたそれらを接続するにはカスタム作業や定期的なインポート そして多大な手作業によるチェックが必要でしたある場所での変更が別のシステムに反映されるのは明日か来週かあるいは永遠に反映されないこともありましたデータバースはビジネスアプリにこの種の情報のための共通の場所を提供します簡単に言えばデータバースはビジネス情報のためのマイクロソフトのクラウドデータプラットフォームです情報を構造化されたテーブルに保存するためデータは断片的なメモやバラバラのファイル分断されたスプレッドシートのタブとしてではなく明確な形で存在しますこれは会社のファイリングキャビネットのようなものですが承認された複数のツールが同時に利用できる点が違います顧客はデータバースに一度だけ登録されます営業担当者が商談を進める際その顧客はダイナミクス365セールスに表示されます

パワーアップを使えば現場担当者やアカウントマネージャーもデータを新しいアプリにコピーすることなく同じ顧客情報を利用できます顧客データは一行参照先も一つですこれはあらゆるチームが全ての情報を自由に見られるようになるという意味ではありませんアクセスにはルールが必要でありそれについては後ほど説明します承認されたアプリは独自の競合するデータを作成するのではなく共通のビジネス情報を元に作業できるということですこれがダイナミクス365とデータバースが非常に自然に適合する理由ですダイナミクス365のセールスやカスタマーサービスなどのアプリはデータバースを使用して業務データを保存保護していますしかしダイナミクス365とデータバースの統合について語る際多くの人は両者の間にコネクタが必要な別々の製品だと想像しがちです多くのダイナミクス365アプリにとってそれは当てはまりませんデータはすでにデータバース内に存在しているからですダイナミクス365から顧客リストを抜き出し別のデータベースにコピーして両方の同期を維持するよう祈る必要はありませんダイナミクス365がすでに使用しているビジネス情報と同じ基盤の上に機能を構築できるのですこれによって議論の焦点が変わりますどうすれば2つの顧客リストを同期できるかと問うのではなくどのユーザーやアプリがこの顧客レコードを扱う必要がありそれぞれに何を許可すべきかを問いかけるようになりますもちろんデータバースが企業内のすべてのシステムを置き換えるわけではありません企業は依然として会計ソフト業界特化ツール倉庫システムウェブサイトあるいは独自のデータを持つ旧来のアプリケーションを使用する可能性がありますデータバースは外部システムを一夜にして消し去る魔法の接着剤ではありませんそれが提供するのは接続されたアプリ間で共有が必要なビジネスデータのための共通の場所です顧客詳細販売活動サポート対応タスクフォローアップなどこれらのレコードは承認されたツールが読み書きできる単一のソースとして共存できますでは私と一緒にそのファイリングキャビネットを開いてみましょうデータバースが内部で情報をどのように整理しているかを知ればダイナミクス365との繋がりがぐっと理解しやすくなりますファイリングキャビネット、テーブル、行、列、そしてリレーションシップですそのキャビネットを開いてみましょうデータバースでは情報はテーブルに格納されます引き出しが分かれた本物のキャビネットを想像してくださいおっと一つの引き出しには企業、もう一つには人物、三つ目にはサポート依頼が整理されていますすべての書類を一つの巨大な引き出しに投げ込み後で誰かが整理してくれることを願うようなことはしないのです引き出しにはそれぞれ役割がありますデータバースにおいても同様にテーブルは特定の種類のビジネス情報を保持します取引先テーブルには通常取引のある企業の情報が入ります連絡先テーブルには個人の情報が入りますリードテーブルには顧客になる前の見込み客の情報が入りますケーステーブルにはサポート依頼がアクティビティテーブルには通話、メール、予定、タスクなどの作業記録が保存されますこれらが標準テーブルです多くの企業が顧客、個人、業務、対話の管理を必要とするためマイクロソフトはこれらを用意しています一般的な用途であれば最初から新しいテーブルを作成する必要はありません標準テーブルがすでに役立つからですしかしどの企業にも独自の業務があります研修会社であればコースや修了証の管理が必要かもしれません不動産会社であれば建物、物件、検査の記録が必要になるでしょう製造業であれば機器の点検やサービス訪問の記録が必要かもしれませんそのような場合、自社の業務内容に合わせたカスタムテーブルを作成できますカスタムテーブルとはキャビネットに新しい引き出しを追加し、そこに分かりやすいラベルを貼るようなものですさて各テーブルに派行、レコードが含まれます行とはその引き出しの中にある一つの項目です例えば、連絡先テーブルの一つの行は、顧客企業の担当者であるマリアゴメスさんを表すことができますその行には、システム内の他の連絡先とは別に彼女自身の詳細情報が保持されます列は、各業に保持したい詳細情報を記述するものですマリアさんの連絡先行には、名、姓、メールアドレス、電話番号、役職、会社、レコード所有者、ステータスなどの列が含まれます列はそこに格納される情報の型を定義するため、メール列にはメールアドレスが、ステータス列には承認済みのステータス選択肢が格納されますこうしてビジネス情報は信頼できる形に整えられます列がなければ、電話番号をメモ欄に入力する人もいれば、名前欄に追加する人もいたり、あるいは全く入力しない人も出てくるでしょう明確な連絡先テーブルがあれば、全員が同じ場所で同じ詳細情報を扱うことができますこの構造は、アプリがデータを理解する助けにもなりますホームは適切な入力ボックスを表示し、レポートはステータス別に連絡先をグループ化し、自動化機能は所有者の変更に反応できます情報は単に保存されるだけでなく、各部分が何を意味するのかを接続されたツールに伝えるラベルを持っていますビジネスニーズに合う場合は、まず標準テーブルから始めましょう企業向け販売であれば、取引先や連絡先の仕組みは多くの人がすでに理解しているパターンですカスタマーサポートを行うなら、ケースがスタート地点となりますその上で、組み込みのパターンに収まらない情報がある場合にのみ、カスタムテーブルを追加してくださいこれにより、顧客を意味するテーブルを5つも作成してしまうという、よくある問題を回避できますあるチームは、クライアント、別のチームは、顧客マスター、3つ目のチームは、パートナー連絡先IOと呼ぶといった具合ですすぐに、どのテーブルを使うべきか誰もわからなくなってしまいます明確な標準テーブルと慎重に命名されたカスタムテーブルがあれば、利用者が増えてもキャビネットは理解しやすくなります次のステップでは、それらの引き出しを連携させていきます連絡先は取引先に属しますマリアはコントソ社で働いていますコントソの住所や電話番号、会社情報をマリアの業に何度も入力する代わりに、データバースを使って連絡先テーブルと取引先テーブルの間にリレーションシップを作成できますマリアとコントソがリンクされます会社情報は会社に紐づくため、このリンクが重要になりますコントソがオフィスを移転した場合、取引先の業を一度更新するだけで、関連するすべての連絡先は古い情報を保持することなく、同じ会社情報を参照できますリレーションシップはサポート案件をそれを起票した顧客と結びつけることもできますまた、営業案件とその商談に関する通話、メール、会議、タスクを紐づけることも可能です営業担当者が案件を開くと、無関係なメモやカレンダーを探し回ることなく、関連する活動をすべて確認できます情報にコンテキスト、文脈が生まれるのです単に案件番号を見るだけでなく、それがどの顧客に属しているのかがわかります単に連絡先を見るだけでなく、その人物に関連する会社も確認できますこれらのリンクによって、同じ事実を何度もあちこちに入力しなくても、データが有用な状態にもたれます古いガイドや動画を見る前に、用語に関する小さな注意点がありますエンティティ、フィールド、レコードという言葉を耳にするかもしれませんこれらはデータバースの古い用語です現在マイクロソフトでは、エンティティの代わりに、テーブル、フィールドの代わりに、列、レコードの代わりに、行という言葉を使用しています意味は何も変わっていません古いガイドで、エンティティを作成する、とあれば、テーブルの作成、フィールド、は、列、レコード、は、行、のことを指しています両方の用語を知っていれば、別の製品だと勘違いせずに済みますつまり、テーブルが情報を整理し、リレーションシップがそれをつなぐということですしかし、うまく整理されたキャビネットにも制御が必要です誰が情報を入力、変更、または安全にアクセスできるかを決定しなければなりませんルールと受付デスクの役割ですデータバースの背後にあるデータは、適切な人が安全に扱えるようになって初めて機能します営業担当者には顧客の詳細が、サポート担当者には案件履歴が、マネージャーには全体像が、そして外部パートナーにはプロセスの一部のみのアクセス権が必要になるかもしれません全員が同じ情報を見るべきではないのです非公開の連絡メモや交渉価格、進行中のサポート案件が含まれる顧客レコードを想像してみてください全てのユーザーにフルアクセス権を与えると、すぐにリスクが生じます全員を厳しく制限して業務に支障が出るのも、別の問題を引き起こしますデータバースは、そのための制御機能を提供しますその最初の制御は、ID、アイデンティティから始まります会社のアカウントでサインインすると、マイクロソフトエントラーIDがあなたを識別しますエントラーIDは、オフィスの入り口にある受付だと考えてください到着してバッジを見せると、受付係が本人確認を行い、入室を許可しますデータバースはそのIDを使って、どのユーザーがデータにアクセスしているかを把握しますこの人は入室してよいか?と問うだけではありません入室した後、この人に何ができるか?

もう問いかけますそこで登場するのがセキュリティロールですセキュリティロールとは、業務や責任に紐づいた権限のセットです営業担当者用、カスタマーサービス担当者用、そして管理者用といったロールを作成できます各ロールで、テーブルへのアクセスを制御できます例えば、営業担当者には、アカウント、連絡先、リード、商談の閲覧、作成、更新を許可できます重要な顧客情報の削除は許可しない、といった設定も可能ですサポート担当者はケースの作成や更新はできても、商談の変更はできないように設定できます権限には、行の読み取り、作成、変更、削除が含まれますつまり、アプリごとにどのボタンを隠すべきか覚えておく必要はありません権限はデータそのものに設定されるからですそのため、そのデータバースデータが表示される場所ならどこでも、同じガードレールが適用されますさらに、アクセスをより詳細に絞り込むことも可能です業レベルのセキュリティにより、どの個別の業を操作できるかを決定します営業担当者は自分が担当する顧客のみを見ることができますが、マネージャーはチーム全員の顧客業を見ることができますどちらも同じアカウントテーブルを使用しています単に見ている範囲が異なるだけですこの仕組みにより、担当者は自分の業務に集中でき、管理者は必要な全体像を把握できますまた、アクセス権のない顧客情報を誰かが開いてしまうリスクも軽減されますさらに厳重な保護が必要な情報もあります列レベルのセキュリティでは、テーブル内の個々の列を保護できます顧客業を開くことはできても、個人識別し、給与、銀行口座、財務メモなどは見せないといった制限が可能です顧客行きそのものは、必要な業務のために利用できます保護された列だけが制限された状態になります大規模な企業では、ビジネスユニットを使って組織間の境界線を作成できます企業は、異なる顧客グループを担当する地域、部門、子会社を分けることができますビジネスユニットは、そうした境界を超えたアクセス権の管理に役立ちますだからといって、全てのビジネスに複雑なセキュリティマップが必要なわけではありません小さなチームであれば、明確な役割がいくつかあれば十分かもしれません

アクセス制御は誰がデータにアクセスできるかを保護しますが、ルールはデータ自体の品質を保護しますビジネスルールを使用すれば、新しい連絡先を保存する前に電話番号の入力を必須にすることができますまた、ケースをクローズする際に理由の入力を求めるなど、条件のチェックも可能です入力された情報に基づいて、ユーザーに表示される内容を変更することもできます同じルールが、そのテーブルを使用するすべてのアプリに適用されますこれは重要ですなぜなら、あるアプリでは不完全なデータを受け入れ、別のアプリでは拒否するといった事態は避けたいからですルールは特定の画面ではなく、ビジネス情報そのものに付随するものですデータバースはバックグラウンドでロジックを実行し、ビジネスプロセスの一貫性を保つのにも役立ちます覚えておくべきポイントは単純ですデータには単なる保存場所だけでなく、ルールも付随しているということですつまり、基盤には情報だけでなく、それを扱う権限を持つ人々、そしてデータを活用可能にするルールも含まれるのですダイナミクス365が同じ基盤上で動作すれば、独自のビジネスデータにアクセスするために従来のブリッジは不要になりますダイナミクス365の統合、とは実際には何を意味するのか多くの人は、ダイナミクス365とデータバースの統合、と聞くと、コネクタで結ばれた2つの別々のシステムを想像します一方のシステムにある顧客データを他方のシステムでも必要とするため、同期を設定し、実行を待ち、途中でエラーが起きないことを祈る、というものです多くのビジネスツールにとって、そのイメージは理にかなっていますしかし、ダイナミクス365セールスとダイナミクス365カスタマーサービスに関しては、その繋がりはもっと密接なものですこれらのアプリは、データバースを共通のデータ基盤として使用しています互いを理解するために、顧客データをやり取りする別々のデータベースが2つ存在するわけではありません最初から同じビジネス情報に基づいて作業が行われます具体的に見てみましょうあなたが営業担当者で、ダイナミクス365セールスで新しい会社を作成したと想像してくださいメインの連絡先を追加し、商談を開始しますそれらの詳細は直ちに、アプリが使用する共有データの一部となりますその後、その顧客からサポートに連絡が入りますサポートエージェントは、全く同じ会社と連絡先の詳細情報を使って対応できます営業からリストをエクスポートしたり、別のサポートツールで顧客を再度作成したりする必要はありませんエージェントはサポートケースをその顧客に紐付けるだけで、状況を把握するために役立つ履歴を即座に確認できます営業担当は商談を、サポート担当は問い合わせ案件を確認し、両チームが同じ顧客を軸に業務を進めますもちろん、これは全ての画面が同じ見た目であることや、全てのチームが同じプロセスに従うことを意味するわけではありません営業には、リード、案件、通話、そして会議が必要ですカスタマーサービスには、問い合わせ、Q、そしてサービス履歴が必要ですダイナミクス365の各アプリは、その人の職務に合わせて構築されたツールを提供します基盤となるビジネス情報は必要な場所で連携可能であり、この共有基盤こそが、ダイナミクス365とデータバースの連携について語る際に人々がしばしば意図するものですこれは単にデータをA地点からB地点へ移動させることではありません全てのアプリが最初から同じ業、関係性、ルール、アクセス制御に基づいて機能することなのですシンプルな営業ジャーニーを例に見ていきましょうウェブサイトやイベントからリードが取り込まれます営業担当者がそのリードに対応し、相手について理解を深め、リードを顧客関係や商談へと育てていきます通話、メール、予定、タスクといったすべてがその業務に関連付けられますそのため、チームはバラバラのツールを探し回って情報をつなぎ合わせる必要がありません顧客が後に助けを必要とした場合、サポート案件をその同じ顧客に紐付けることができますサポート担当者は、単なる名前やメールアドレスを確認するだけではありませんすでに特定された顧客関係に基づき、状況を把握しながら対応できるのですその間、営業チームは顧客が現在サービス上の問題を抱えていることを把握できるため、問題を知らずに更新の交渉に臨む事態を避けられます単に2つのシステムで顧客名を一致させておくよりも、1つの顧客関係が様々な業務を支えることの方が遥かに有用ですコモンデータモデル、略してCDMという言葉を耳にすることもあるでしょうその名前から、必要以上に難しく考えることはありませんこれは単に、企業が管理する取引先企業、取引先担当者、活動、問い合わせ案件といった項目について、マイクロソフトが標準的なテーブルパターンを提供していることを意味しますこれらのパターンにより、ダイナミクス365とデータバースベースのアプリは、共通の言語を最初から備えることになります取引先企業は、会社を意味します取引先担当者は、個人を意味します活動は、ビジネス関係における業務を記録します自社に合わせて設定を調整したり、必要に応じて独自のテーブルを追加したりすることは可能ですが、毎回ゼロから始める必要はありませんあるアプリが取引先企業テーブルを理解し、別のアプリも同じテーブルを使用すれば、両方のアプリが同じ種類のビジネス情報を参照することになりますこれにより、構築できるものの可能性も広がります例えば、現場チームが顧客を検索し、訪問を確認し、面談後にメモを残すためのシンプルなアプリが必要だとしましょうダイナミクス365が既に使用している同じデータバーステーブルを活用するパワーアップスアプリを構築できるのですそのアプリのためだけに、顧客データを新しいリストへエクスポートする必要はありません現場の作業員がアプリを開いて顧客を検索し、訪問情報を更新するだけですデータは、前述したセキュリティ規則に従い、営業や顧客サービスが既に使用している顧客関係と接続されたままになりますより構造化された業務には、モデル駆動型アプリを構築できますモデル駆動型アプリは、データモデルから始まりますデータバースのテーブルを選択し、その関係を定義して、フォームやビューを設定し、セキュリティロールを適用しますするとパワーアップスがその構造を利用して、実用的なビジネスアプリ体験を作成しますチームが実際に使用するツールや素材に合わせて、作業台を整理するようなものだと考えてくださいテーブルが作業内容を記述し、リレーションシップが各要素を結びつけますフォームにより、詳細情報の入力や確認が可能になりますリューは、対応が必要な業を見つけるのに役立ちますセキュリティによって、各ユーザーが開けるデータや変更できる内容が決定されますモデル駆動型アプリは、ダイナミクス365と並行して利用できますどちらもデータバースで動作するためです例えば、ダイナミクス365セールスが販売プロセス全体を扱い、小規模なモデル駆動型アプリが契約マネージャー専用の顧客契約管理の場を提供する、といった形ですどちらも、顧客データベースを二重に作成することなく、関連する顧客データを共有できますもちろん、アクセスには引き続き注意が必要ですアプリがデータバースのテーブルを扱えるからといって、すべてのユーザーがすべての行を編集したり、すべての列を表示したりできるべきではありませんロール、行いのアクセス権、ビジネスルールによって操作できる範囲が制御されます現場用アプリを使えば、会社や他のデータの情報を公開することなく、必要な顧客詳細情報やアクションだけを適切に提供できますつまり、データバースとダイナミクス365の統合は、離れた2つの部屋をつなぐケーブルのような役割を果たすのですダイナミクス365アプリ、カスタムアプリ、そしてビジネスプロセスはすべて、同じ共有基盤の上で動作しますそれが理解できれば、次の疑問が明確になりますマイクロソフトの接続されたプラットフォーム全体で、その同じ顧客更新情報を他に何に活用できるでしょうか接続されたプラットフォームが実際の業務でどのように機能するかを見ていきましょう共有された顧客更新情報は、周囲のツールがそれに応答して初めて価値を発揮しますパワーオートメイトは、データバースの業の変更を監視し、変化があった際にアクションを開始することで、後続の業務を処理します例えば、ダイナミクス365セールスに新しいリードが登録されたとしますフローによって、担当営業担当者への通知、チームへのメッセージ投稿、フォローアップタスクの作成などが行えますもう共有トレイを1日中監視する必要はありませんリードが変更されると、次のステップが自動的に開始されますパワーオートメイトは、その作業を行うためだけにリードのコピーを別途必要とすることはありませんセールスアプリが使用するのと同じ顧客情報や所有権の詳細を利用して、データバースの業に直接反応できるからですこれにより、誰かがファイルを出力して手作業でメールのやり取りを開始する代わりに、ビジネスプロセスに密着した自動化が維持されます次にパワーBIがあります営業マネージャーは、現在のパイプラインを確認したいと思うでしょうカスタマーサービスマネージャーは、今週届いた案件数、未解決の案件、または最も頻繁にサポートに連絡してくる顧客を確認する必要があるかもしれませんパワーBIはデータバースのビジネスデータをレポートできるため、チームは毎週金曜の午後に新しいスプレッドシートを作成しなくても、進行中の業務を把握できますレポートは、すでに現場で使用されているビジネスデータに基づいて作成されますつまり、案件が進むにつれてパイプラインのグラフも変化するのですケースダッシュボードでは、エージェントがケースを更新するたびに現在の負荷状況を表示できます重要なのは、ダッシュボードが人の手による詳細確認を代替するということです何に注目すべきかを判断する前に、作業の全体像がより明確になりますパワーアップスは、同じプロセスへの別の入り口を提供します現場の作業員が顧客先に到着した場面を想像してみてください彼らには、ダイナミクス365の販売機能のすべては必要ありません顧客を検索し、訪問の詳細を確認し、何があったかを記録し、メモや写真を加えるだけでいいかもしれません目的に特化したパワーアップなら、そうした最小限の機能を提供できますアカウントチームには、顧客との契約を確認するためのアプリが必要かもしれませんマネージャーには、申請を承認するためのシンプルなアプリが必要かもしれません各アプリは特定のタスクに集中しながら、裏側では同じ管理されたデータバースの情報と連携します担当者は、自分の1日に適したツールを使うことになります企業側は、接続された情報を一元管理できます時には、その情報がデータバースの外から始まることもあります企業がオンラインソースから得たリストを、ビジネスデータの一部として取り込む必要がある場合などがそうですパワークエリを使えば、サポートされているオンラインソースからデータを取り込み、インポート中に整理し、適切なデータバーステーブルに読み込むことができますこれは、ダイナミクスやパワープラットフォームのツールで使用する必要がある情報が外部ソースにある場合に役立ちます何がデータバースに属し、既存のテーブルとどう関連付けるべきかを決める必要がありますそれを考えずにデータをインポートしても、混乱を新しい場所に移動させるだけですオータムが各ピースを日々のフローに組み込む様子を見てみましょう新しいリードがダイナミクス365に入ると、割り当てルールが地域や製品に基づいて担当者をチェックします担当者はパワーオートメイトフローを通じてチームメッセージを受け取り、作業が待機していることを知ります営業担当者がリードを更新し、販売プロセスを進めると、パワーBIダッシュボードが変化し、オータムチームの現在のパイプライン状況がチームに共有されますたった一つの更新が、複数の場所で有益な作業を開始させますパワーオートメイトは作業を次のステップへと進めますパワーBIは、人々の作業状況の可視化を助けますパワーアップスは、特定のチームが参加するための集中的な手段を提供しますデータバースは、そうしたツールが機能する間、ビジネス情報を整理し保護しますその違いが重要なのです自動化はファイリングシステムではなく、ダッシュボードは顧客データベースではありません各ツールには個別の役割がありますが、すべて同じソースから機能できますそれを知ることで、すべてのスプレッドシートやリストがビジネスプロセス全体を担うべきかのように扱うのではなく、適切なツールを選択できるようになりますデータバースが適している場面と、それが置き換えないものについて、重要なのは以下の点です複数のユーザーやアプリが、相互接続されたビジネスデータを操作する必要がある場合にデータバースを選びます明確なアクセスルールと反復可能なプロセスが必要ですデータバースはそれを処理しますが、他のすべてを置き換えるわけではありませんExcelは依然として、個人的な分析や簡易リスト作成に適していますシェアポイントリストは、チーム内の単純な追跡にうまく機能しますまた、詳細な制御が必要な開発者であれば、SQLが強力な選択肢となりますでは、データバースはいつ進化を発揮するのでしょうかデータのコピーを作成せずに、ダイナミクス365アプリ、自動化、レポート間でデータを接続する必要がある場合ですそこが最大の強みですでは、結論です一つの基盤、多数のビジネスツールつまり、結論はこうですダイナミクス365とデータバースは、データ、ルール、セキュリティ、アプリ、自動化、レポートのすべてが共通の基盤を共有するときに最も効果を発揮しますM365FMのMicrosoft Knowledge Nuggetsを公読して、Dynamics 365 Power Platform Microsoft 365に関するわかりやすいガイドをご覧ください続いて、データバースのテーブルがどのように実用的なビジネスアプリに変わるのか、モデル駆動型アプリのエピソードをご覧ください