エンティティの概要

適用対象: Dynamics 365 for Customer Engagement アプリ バージョン 9.x

エンティティ を使用して Dynamics 365 for Customer Engagement アプリのビジネス データをモデル化して管理します。 たとえば、取引先企業、キャンペーン、インシデント (サポート案件) などのエンティティを使用して、営業活動、マーケティング活動、サービス活動を追跡およびサポートできます。 エンティティには一連の属性があり、各属性は特定の種類のデータ アイテムを表します。 たとえば、取引先企業エンティティには Name 属性、Address 属性、および OwnerId 属性があります。 概念上、エンティティはデータベース テーブルに似ており、エンティティ属性はテーブルの列に対応しています。 Dynamics 365 for Customer Engagement アプリのエンティティ レコード (または単にレコード) の作成は、データベース テーブルへの行の追加に似ています。 エンティティは、システム、ビジネス、ユーザー定義の 3 つのカテゴリに分類されます。 ビジネス データを操作する開発者は、ビジネス エンティティとユーザー定義エンティティを使用します。 システム エンティティは Dynamics 365 for Customer Engagement アプリでワークフローや非同期ジョブなどすべての内部プロセスを処理するのに使用されます。 システム エンティティは削除またはカスタマイズできません。

ビジネス エンティティは Dynamics 365 for Customer Engagement アプリの既定のインストールの一部で、カスタマイズ ユーザー インターフェイスに表示されます。 取引先企業、取引先担当者、レターはビジネス エンティティの例です。 組織固有のビジネス ニーズに対処するため、インストール後にユーザー定義エンティティを Dynamics 365 for Customer Engagement アプリに追加できます。 Dynamics 365 for Customer Engagement アプリの ソリューション では、ビジネス エンティティとユーザー定義エンティティ、および属性をカスタマイズ可能またはカスタマイズ不可に設定できます。 名前の変更、新規属性の追加、または重複データ検出設定やキュー サポート設定など各種設定の変更によって、カスタマイズ可能エンティティを変更できます。 カスタマイズ不可のエンティティは変更できません。 カスタマイズ、マネージド ソリューションおよびアンマネージド ソリューション、マネージド プロパティに関する詳細については、Dynamics 365 for Customer Engagement アプリ ソリューションを使用した拡張機能のパッケージ化および配布 を参照してください。

事前バインド プログラミング モデルを使用している場合、エンティティは取引先企業エンティティを表す Account クラスなどのクラスで表されます。 エンティティ属性は、クラスのプロパティで表されます。 このクラスは、CrmSvcUtil ツールによって生成されます。 詳細については、「WCF 事前バインド (厳密に型指定された) プログラミング」を参照してください。 あるいは、動的手法を使用して、エンティティ データを操作するプログラムを作成できます。 詳細については、「WCF 遅延バインド (厳密に型指定されない) プログラミング」を参照してください。

注意

Dynamics 365 Customer Engagement Web サービス では、「エンティティ属性」という用語は、「属性」および「プロパティ (クラスのプロパティ)」という用語と同じ意味で使用されます。

エンティティ メタデータ

Dynamics 365 for Customer Engagement アプリ組織のメタデータには、エンティティの定義、属性、およびエンティティの関連付けが含まれます。 エンティティのカスタマイズ方法の詳細については、Dynamics 365 for Customer Engagement アプリのメタデータ モデルおよびデータ モデル を参照してください。 開発者として、組織のすべてのメタデータを見つけることができるが役立つ、さまざまケースがあります。 メタデータを検索し、参照するいくつかの方法があります:

エンティティ メタデータで使用する名前

エンティティ、属性、および関連付けには数種類の名前があります。 次の表に、メタデータで使用される各種の名前を示します。

名前 説明
表示名 ユーザーに表示される名前。
表示コレクション名 表示名の複数形。 この名前はエンティティのみに適用されます。
論理名 エンティティまたは属性の一意の名前。 この名前はすべて小文字です。
スキーマ名 スキーマ名は作成時に指定します。 この名前は一意である必要があります。 論理名の作成に使用します。 この名前は Pascal 形式にする必要があります。 スキーマ名は、事前バインド プログラミング使用時に、エンティティのクラスの作成に使用します。

注意

ソリューションのコンテキストで作成されたユーザー定義エンティティ、属性、および関連付けでは、論理およびスキーマ名のカスタマイズの接頭辞は、Publisher.CustomizationPrefix 属性で定義されます。 ユーザー定義エンティティがプログラム的に作成される場合、カスタマイズの接頭辞は、長さが 2 文字から 8 文字の間の文字列で、すべて英数文字であり、最初の 1 文字を英字にします。 接頭辞を "mscrm" で始めることはできません。 エンティティ メタデータの命名規則、およびカスタマイズについての詳細については、「エンティティ メタデータのカスタマイズ」を参照してください。

エンティティ レコードに対する操作

各エンティティは、レコードの作成または削除や、別のユーザーまたはチームへのレコードの割り当てなど、複数の異なる操作をサポートします。 すべての操作がすべてのエンティティの種類や属性に対して許可されるとは限りません。 メタデータにより、それぞれの属性に対して特定の操作がサポートされるかどうかが定義されています。 たとえば、IsValidForCreateIsValidForRead、および IsValidForUpdate などの属性のプロパティが、属性を作成、取得、または更新できるかどうかを示します。 詳細: 属性に対する有効な操作

操作を実行するには、IOrganizationService のいずれかのメソッドを呼び出します。 たとえば Dynamics 365 for Customer Engagement アプリでレコードを作成するために IOrganizationService.Create を使用できます。 メソッドまたは IOrganizationService.Execute メソッドを対応する CreateRequest メッセージとともに使用することができます。 これらの操作を実行するには、必要な特権とアクセス権が必要です。 詳細については Dynamics 365 for Customer Engagement アプリのセキュリティ モデル を参照してください。

次の表では、ビジネスおよびユーザー定義エンティティ レコードに対して許可されている操作と、これらの操作を実行するために使用できるメソッドおよびメッセージを一覧表示しています。

操作​​ 内容 メソッド/メッセージ
作成​​ ユーザー定義エンティティを含む、特定のエンティティの種類のレコードを作成します。 IOrganizationService.Create

CreateRequest
更新 レコードの内容を変更します。 IOrganizationService.Update

UpdateRequest
[削除] レコードを削除します。 IOrganizationService.Delete

DeleteRequest
取得 レコードを取得します。 IOrganizationService.Retrieve

RetrieveRequest
複数取得 レコードのコレクションを取得します。 IOrganizationService.RetrieveMultiple

RetrieveMultipleRequest
割り当て レコードの所有権を変更します。 ユーザーによって所有されるか、チームによって所有されるエンティティに対して有効。 AssignRequest
共有 別のユーザーまたはチームに対して、レコードへのアクセスを許可したり、変更したり、取り消したりします。 ユーザーによって所有されるか、チームによって所有されるエンティティに対して有効。 GrantAccessRequest

ModifyAccessRequest

RevokeAccessRequest
関連付け レコードと、エンティティ間に関連付けがあるレコードのコレクションの間にリンクを作成します。 AssociateRequest
関連付け解除 レコードと、エンティティ間に関連付けがあるレコードのコレクションの間のリンクを解除します。 DisassociateRequest
状態の設定 レコードの状態を設定します。 SetStateRequest

作成​​

この操作を実行するには、作成特権が必要です。 アクセス権は作成操作には適用されませんが、作成後のレコードには適用されます。

レコードを所有する、または新規作成されたレコードを取得するには、ユーザーまたはチームに新規レコードに対する読み取り特権とアクセス権も必要です。 たとえば、取引先企業の作成特権がある場合は、取引先企業レコードを作成して、それを別のユーザーまたはチームに割り当てることができます。 ただし、取引先企業に対する読み取り特権および新規レコードに対するアクセス権がない場合は、取引先企業を作成して、その新しい取引先企業の所有者になることはできません。

更新プログラム

この操作を実行するには、更新するエンティティ レコードに対する Update Privileges およびアクセス権が必要です。

レコードを更新すると、データまたは NULL の指定対象となる属性だけが更新されます。 それ以外の値はすべて元のまま維持されます。 また、更新が有効ではない属性のデータを指定した場合は無視されます。

削除​​

この操作を実行するには、削除するエンティティ レコードに対する削除の権限およびアクセス権が必要です。

関連レコードが同時に削除されるかどうかは伝播規則に依存します。 詳細については、「エンティティの関連付けの動作」を参照してください。

通常、レコードを削除するのは、誤ってレコードを入力した場合のみとしてください。 レコードの種類によっては、削除する代わりにレコードを非アクティブ化する、または閉じることができます。 レコードの種類によっては削除できないものがあります。

取得

この操作を実行するには、取得するエンティティ レコードに対する Retrieve Privileges およびアクセス権が必要です。

複数取得

この操作を実行するには、取得するエンティティ レコードに対する Retrieve Privileges およびアクセス権が必要です。

特定のクエリ パラメーターに基づいてレコードのコレクションを取得するには、クエリ式または FetchXML クエリ言語を使用します。 クエリ式では、クラス階層を使ってクエリ ツリーを作成できます。 クエリ式を使用した方法では、厳密に型指定されたレコードのコレクションが返されます。 FetchXML では、XML 言語を使用してクエリを作成できます。 FetchXML では XML 文字列が返されます。 そのため、クエリの結果を使用するには、別途、データの操作が必要になります。 詳細については、「データを取得するクエリの作成」を参照してください。

割り当て​​

ユーザー所有またはチーム所有のエンティティについて、新しい所有者にレコードを割り当てます。 詳細については、エンティティの所有権 を参照してください。 この操作を実行するには、エンティティ レコードに対する割り当て特権およびアクセス権が必要です。

関連レコードが同時に別のユーザーに割り当てられるかどうかは伝播規則に依存します。 詳細については、「エンティティの関連付けの動作」を参照してください。

ShareToPreviousOwnerOnAssign 属性が true に設定されている場合、レコードが別のユーザーまたはチームに割り当てられても、以前の所有者は引き続きこのレコードにアクセスできます。 ただし、そのレコードの所有権は、以前の所有者から失われます。

注意

レコードの所有権を他のユーザーに変更すると、そのユーザーがそのレコードの "ユーザー" レベル レコード特権しか持っていない場合、そのレコードにアクセスするとき "アクセスが拒否されました" エラーが表示されます。

共有

ユーザー所有またはチーム所有のエンティティでは、他のユーザーまたはチームとそのレコードを共有できます。 この操作を実行するには、エンティティ レコードに対する GrantAccess Privileges、ModifyAccess Privileges、およびRevokeAccess Privileges およびアクセス権が必要です。

関連レコードが同時に共有されるかどうかは伝播規則に依存します。 詳細については、「エンティティの関連付けの動作」を参照してください。

共有は、Dynamics 365 for Customer Engagement アプリ ユーザーが必要に応じて顧客情報へのアクセス権を他のユーザーに与える方法です。 たとえば、営業担当者は、営業案件を他の営業担当者と共有して、重要な営業の進行状況を両方の担当者が追跡できるようにすることができます。

レコードを共有するには、GrantAccessRequest を使用します。 レコードの共有方法を変更するには、ModifyAccessRequest を使用します。 レコードのすべての共有を解除するには、RevokeAccessRequest を使用します。

取引先担当者、取引先企業、営業案件、サポート案件、受注などの顧客関連レコードを、Dynamics 365 for Customer Engagement アプリで他のユーザーと共有するためには共有権限が必要です。 レコードが共有されている場合、その共有レコードに対して許可する権限を指定できます。

次に、レコードの共有に関するルールを示します。

  • レコードに対する共有特権を持つユーザーは、他のユーザーまたはチームとそのレコードを共有できます。

  • レコードに対する共有特権を持つユーザーは、そのレコードに対するアクセス権を設定できます。 これらのアクセス権は、レコードを共有しているユーザーがそのレコードにどのようにアクセスできるかを制御します。

  • 共有レコードに対するアクセス権は、読み取りや書き込みなど、どのアクセス権限にも設定できます。

  • 共有レコードに対するアクセス権は、そのレコードを共有しているユーザーごとに異なる場合があります。

  • 1 つのレコードは同じセキュリティ主体と一度だけ共有できます。 ユーザーは、レコードに対する共有特権がある場合にそのレコードを共有できます。

  • ビジネス レコードに対する共有特権を持つユーザーは、レコードを共有しているユーザーのアクセス権を変更できます。

  • ビジネス レコードに対する共有特権を持つユーザーは、そのレコードを共有している特定のユーザーの共有を削除できます。

  • ビジネス レコードに対する共有特権を持つユーザーは、レコードを以前共有していたすべてのユーザーの共有を削除できます。

関連付け

この操作を実行するには、更新するエンティティ レコードに対する関連付け特権およびアクセス権が必要です。

関連付けは、指定したレコードと、指定した関連付けの指定したコレクション内の各レコード間に、1 回のトランザクションで複数の関連付けを作成します。

一対多の関連付けでは、この方法によって、関連レコードの ReferencingAttribute が指定したレコードの ID に設定されます。

多対多の関連付けでは、この方法によって、関連付けの交差テーブルにレコードが作成され、参照されているレコードと参照しているレコードの両方の ID が格納されます。 交差テーブル名は、関連付けの IntersectEntityName プロパティで定義されます。

関連付け解除

この操作を実行するには、更新するエンティティ レコードに対する関連付け解除特権およびアクセス権が必要です。

関連付け解除は、参照されているレコードと参照しているレコードを更新し、該当する交差レコードを削除することによって、関連付け操作の逆を行います。 詳細については、「関連付け」を参照してください。

状態の設定

この操作を実行するには、更新するエンティティ レコードに対する SetState Privileges およびアクセス権が必要です。 SetStateRequest メッセージは、エンティティ レコードの StateCodeStatusCode 属性を更新します。

エンティティの所有権

エンティティの所有権には複数の種類があります。 ユーザー定義エンティティを含む大部分のエンティティは、組織、ユーザー、またはチームによって所有されます。 値引きの種類 (値引き表) のように、所有者を持たず、所有権がその親エンティティの値引きによって決まるビジネス エンティティもあります。 所有権の種類により、レコードに対して実行できる操作の一部が決まります。 エンティティの所有権は、メタデータ プロパティOwnershipTypeで定義されます。 次の表に、所有権のプロパティを示します。

所有権の種類 説明
組織による所有 組織全体に属する事項または組織全体で参照可能な事項に関連するデータを含んでいます。 組織によって所有されているエンティティは、割り当ても共有もできません。 たとえば、製品は組織によって所有されます。 これらのエンティティには、organizationid という属性があります。
部署が所有 部署に帰属するエンティティ。 これらのエンティティには、owningbusinessunit という属性があります。
ユーザーまたはチームが所有 ユーザーまたはチームに割り当てられています。 これらのエンティティは、取引先企業や取引先担当者など、顧客に関連するデータを含んでいます。 ユーザーまたはチームの部署に応じてセキュリティを定義できます。 これらのエンティティには、owningteam および owninguser という属性があります。
なし これらのエンティティは別のエンティティによって所有されません。

ユーザーまたはチーム所有権に関する追加情報

AssignRequest メッセージを使用して、レコードの所有権を変更することができます。 詳細については、「割り当て​​」を参照してください。 ReassignObjectsOwnerRequest メッセージまたは ReassignObjectsSystemUserRequest メッセージを使用して、所有者のすべてのレコードの一括再割り当てを実行できます。

注意

所有権をユーザーまたはチームに制限することにより、データへのアクセスを組織内の承認済みユーザーに制限できます。 ただし、エンティティ レコードを承認済みユーザーと共有することにより、データ アクセスをその他のユーザーおよびチームに拡張できます。 レコードを別のユーザーまたはチームに割り当てることもできます。 ユーザーまたはチームが所有するエンティティのセキュリティを構成することにより、セキュリティ ロールのアクセス レベルは組織が所有するエンティティより多くなります。 組織が所有するエンティティのセキュリティ ロールには、なしとグローバルの 2 つのアクセス レベルがあります。 ユーザーまたはチームが所有するエンティティには、グローバル、ディープ、ローカル、ベーシック、なしの 5 つのアクセス レベルがあります。

レコードの状態とステータス

大部分のビジネス エンティティには、レコードの状態を追跡するための 2 つのプロパティがあります。 Web アプリケーションの状態である StateCode と、Web アプリケーションのステータスである StatusCode です。 StateCodeStatusCode の属性値はリンクしています。 StateCode 属性は、エンティティの状態を表すために内部で使用されます。 StatusCode 属性は、エンド ユーザーにこの値を表示するために使用されます。 エンティティの有効な状態コードのセットはカスタマイズできませんが、状態コードはカスタマイズ可能です。 サポート案件エンティティとユーザー定義エンティティでは、ステータス間の有効な遷移に関する追加条件を定義できます。 詳細については、「エンティティ属性メタデータのカスタマイズ」および「カスタムの状態モデルの遷移の定義」を参照してください。

エンティティ イメージ

特定のシステム エンティティにはイメージの属性があります。 イメージ属性をカスタム エンティティに追加することができます。 属性がイメージ エンティティを持つ場合、イメージがアプリケーションに表示するかどうかをコントロールする PrimaryImageAttribute のプロパティを設定できます。 イメージが web アプリケーションに表示されると、アプリケーションのユーザーはエンティティ レコードの画像をアップロードできます。 次のシステム エンティティには、イメージ属性があります。 アスタリスクでマークされたものは、アプリケーションに表示することが既定で有効です。

取引先企業 \* KbArticle キャンペーン
インシデント 競合企業 \* つながり
取引先担当者 \* 契約 TransactionCurrency
EmailServerProfile 目標 請求書
潜在顧客 \* メールボックス OpportunityProduct
受注 組織全体 製品 \*
発行者 \* キュー リソース \*
SalesLiterature 担当地域 SystemUser \*

詳細: イメージ データの属性

関連項目

管理およびセキュリティ エンティティ
Dynamics 365 for Customer Engagement アプリでのエンティティのグラフ生成にメタデータを使用する
カスタムの状態モデルの遷移の定義
エンティティ図の要点
ビジネス データのモデル化と Dynamics 365 for Customer Engagement アプリ
エンティティの関連付けのメタデータ
エンティティ関係の動作
Dynamics 365 for Customer Engagement アプリのメタデータ モデルおよびデータ モデル
Dynamics 365 for Customer Engagement アプリのメタデータ モデルの拡張
Dynamics 365 for Customer Engagement アプリのソリューションを使用した拡張機能のパッケージ化および配布
IOrganizationService エンティティ
Dynamics 365 for Customer Engagement アプリのセキュリティ モデル
サンプル: エンティティ イメージを設定および取得する
サンプル: チームへのレコードの割り当て
サンプル: GrantAccess、ModifyAccess、および RevokeAccess メッセージを使用したレコードの共有
サンプル: 2 つのレコードの統合
サンプル: レコードの状態の検証とレコードの状態の設定
サンプル: 特定のレコードに関連付けられているロールアップ レコード