組み込みテーブルとカスタム テーブル

完了

このユニットでは、構成ですぐに使用できる標準テーブル、およびカスタム テーブルとその目的について説明します。 Microsoft Dataverse には多くの一般的なテーブルがあり、目的に対応する標準テーブルが既に存在する場合はカスタム テーブルを作成しないという原則を遵守するために、この情報が必要になります。 その理由は、多数の冗長テーブルを使用して構成に負荷をかけると、システムのパフォーマンスに悪影響を与える可能性があるため、システムを使用するのが困難になるためです (高度な検索に類似する名前のテーブルが多い場合、ユーザーの混乱を招きます)。 各カスタム テーブルは、特定の目的に使用できます。 また、このトピックでは、最も使用されているテーブルを識別し、テーブルの過負荷リスクがあるかどうかを確認するのにも役立ちます。

標準テーブルをカスタム テーブルで置き換えるかどうかを判断する

コンフィギュレータは、標準機能をカスタム テーブルに置き換えることを検討する場合があります。 たとえば、コンフィギュレータが営業案件において、通常の営業案件フォームよりもシンプルなフォーム、つまりカスタム テーブルが必要であると判断する場合があります。 ただし、標準テーブルの代わりにカスタム テーブルを使用する場合、使用できなくなるオプションについて考慮する必要があります。 標準のテーブルを使用すると、プラットフォームのコア機能とのより優れた連携が保証されます。 追加機能は定期的に追加されているため、標準テーブルを使用すると、新しい機能がリリースされたときに、その機能を簡単に利用できます。 たとえば、標準の営業案件テーブルをカスタム営業案件テーブルに置き換えることにした場合、Sales Insights やその他の AI 機能を利用することはできなくなります。

業界固有のテーブルについては、Common Data Model を使用することを検討してください。 メタデータ システムに加えて、Common Data Model には、Microsoft とそのパートナーが公開した、標準化された拡張可能なデータ スキーマのセットが含まれています。 この定義済みスキーマのコレクションには、テーブル、属性、セマンティック メタデータ、リレーションシップなどが含まれます。 Microsoft はさまざまな業界の代表者と緊密に協力し、業界アクセラレータを作成して Common Data Model をより関連性の高いものにしています。

業界アクセラレータは、Microsoft Power Platform および Dynamics 365 の基本的なコンポーネントで、独立系ソフトウェア ベンダー (ISV) やその他のソリューション プロバイダーは業界別のソリューションを迅速に構築できます。 このアクセラレータには、Common Data Model を拡張して、特定の業界における概念のデータ スキーマをサポートするための新しいテーブルが含まれます。 現在、Microsoft は以下の業界向けアクセラレータの提供に注力しています。

• 自動車産業
• 金融サービス (銀行および保険を含む)
• 教育 (高等教育と K-12 を含む)
• 非営利団体
• 製造
• メディア
• 通信

アカウントと連絡先を再作成しない

Dynamics 365 を展開する際、システム内で複数のタイプの会社、組織、および連絡先を追跡することがよくあります。 それらは、顧客またはクライアント組織であったり、経理や法律関連会社などのサポートおよびアドバイザリー組織であったりします。また、貿易関係などの他のさまざまなタイプの組織である場合もあります。

そのため、会社リレーションシップの複数のカテゴリの管理方法を決める必要があります。 最も一般的な方法は、すべての組織タイプに対して取引先企業テーブルを使用し、列をリレーションシップ タイプまたはカスタム選択列として使用して、タイプまたはカテゴリ別に会社をフラグ設定することです。 ビューは会社のタイプに基づいてフィルター処理でき、ビジネス ルールでは、条件に応じて、列やフォームのコンポーネントをタイプに基づいて表示または非表示にすることができます。

二重書き込み機能を使用して財務と運用アプリとの標準統合のメリットを利用するには、Dataverse 環境に対する二重書き込みコア ソリューションによって追加された既定のテーブルと列を使用することをお勧めします。

もう 1 つの方法は、会社のタイプごとにカスタム テーブルを作成することです。 一般的な理由の 1 つとして挙げられるのは、「将来、別の理由で取引先企業を使用することが考えるため、取引先企業テーブルをカスタマイズしたくない。」ということです。

取引先企業テーブルをカスタム会社テーブルとして再作成する前に、カスタム テーブルを作成することによって使用できなくなる次の機能について十分に検討してください。

• 複数の住所 - 取引先企業テーブルには、複数の住所をサポートする固有の住所機能があります。 最初の 2 つの住所は、会社フォームに表示されますが、これらの住所レコードは関連する顧客住所テーブルに存在します。 カスタム会社テーブルに関連付けられたカスタム住所テーブルを作成することもできますが、関連するテーブルにアドレスが保存され、フォームに表示される一意のロジックを作り直すには、テーブル ビューの開発が必要になります。 複数の住所が必要な場合は、取引先企業テーブルを使用します。

• 取引先担当者の階層 - 取引先企業は連絡先の親です。 連絡先に関連する活動は、取引先企業の親会社のレコードにロールアップされます。 この階層は、カスタム会社レコードによって置き換えることはできません。 カスタム会社テーブルで追加のリレーションシップを作成できますが、標準の取引先企業や連絡先のリレーションシップを置き換えることはできません。 このタイプの会社との主要な会社リレーションシップを持つ連絡先が会社に存在する場合、または連絡先から会社に活動をロールアップする場合は、取引先企業テーブルを使用します。

• 会社テーブル - モデル駆動型アプリの標準マップ コントロールでは、カスタム会社テーブルはサポートされません。

• 階層リレーションシップ - 親/子取引先企業間のリレーションシップと、取引先企業の親会社に対する子取引先企業活動の標準階層のビジュアル化とロールアップは、標準の取引先企業テーブルに対してのみ使用できます。

• 顧客列 - Dynamics 365 には、顧客列と呼ばれる特別なタイプのポリモーフィックなルックアップ列が含まれています。 この列を使用すると、レコードを会社/取引先企業または連絡先にリンクすることができます。 Dynamics 365 では、ポリモーフィックなルックアップ列からカスタム テーブルを選択することはできません。

• マーケティング - マーケティング リストを使用できるのは、連絡先、取引先企業、およびリードのみです。カスタム テーブルは使用できません。 Microsoft Dynamics 365 Marketing は、取引先企業および連絡先に送信できますが、カスタム会社テーブルには送信できません。

ほとんどすべての状況で、取引先企業テーブルは、すべてのタイプの会社レコードに使用する必要があります。ただし、次の例外があります。

• リレーショナルではなく、最小限の属性を持つ小規模な会社。 連絡先や住所がなく、ルックアップの目的でのみ存在する組織のタイプがこれに該当します。

• 取引先企業テーブルを損なうべきでない、名刺や Web フォームからインポートされた未確定の会社または未検証の会社。 このような場合は、リード テーブルを使用できます。

システム テーブルを転用するかどうかを判断する

営業案件と似ているが、販売機会ではないビジネス要件があるシナリオを考えてみます。 このシナリオでは、システム テーブルを転用するか、または新しいテーブルを作成するかどうかを決定する必要があります。

次のセクションでは、システム テーブルを転用する前に考慮すべき状況について説明します。

未来について検討する

Dynamics 365 はこれまでよりもはるかに速く進化しているため、標準以外の方法でテーブルを使用すると、使用しているテーブルに Microsoft が変更を行った場合に問題が発生する可能性があります。 また、契約のようなほとんど使用されていないシステム テーブルを転用する場合、Microsoft によってそのテーブルが将来廃止される可能性があります。 カスタム テーブルは廃止されません。 また、システム テーブルを転用する場合、後でそのテーブルを本来の目的に使用する必要がある場合に問題が発生する可能性があります。 ある顧客では、サポート案件テーブルを転用した後でサポート案件管理が必要となり、標準のサポート案件テーブルが大幅に異なる目的で既に使用されていたために、カスタム テーブルを使用して対処する必要がありました。

オーバーヘッドについて検討する

多くのシステム テーブルには、フォームから削除できない特定の列が含まれています。 たとえば、営業案件テーブル、サポート案件テーブル、キャンペーン テーブルなどの一部の列は、フォームから削除することはできません。 これらの列を非表示にすることもできますが、フォーム上にロックされた列が複数存在すると、環境構成のオーバーヘッドが増える可能性があります。 

ユーザー エクスペリエンスについて検討する

標準テーブル機能に沿ったユース ケースが 50% 未満の場合、カスタム テーブルを使用すると、通常、より複雑なシステム テーブルをスケーリング ダウンするよりもユーザー エクスペリエンスを簡素化できます。 また、カスタム テーブルを含む任意のテーブルにビジネス プロセス フローを追加することもできます。これにより、カスタム テーブルのユーザー エクスペリエンスを少なくとも同じくらいのものにするか、システム テーブルを転用するよりも優れたカスタム テーブルを作成できます。