テーブル リレーションシップのカスケード動作を設定する

一対多の関係にカスケード動作を設定することで、データの整合性を保ち、ビジネス プロセスを自動化することができます。 Web API および組織サービスの両方は、カスケード動作の構成をサポートしています。

注意

エンティティとテーブルの違いがわかりませんか? Microsoft Dataverse で「開発者: 用語を理解する」を参照してください。

Web API を使用してカスケード動作の構成

Web API の作業をするときは、OneToManyRelationshipMetadata EntityType を使用して一対多の関連付けを定義することができます。 この定義には、作成される交差テーブルの名前と、AssociatedMenuConfiguration ComplexTypeLabel ComplexTypeLocalizedLabel ComplexType を使用したアプリケーションでの関係の表示方法が含まれます。

詳細については、Web API を使用して一対多の関連付けを作成する を参照してください。

組織サービスを使用してカスケード動作の構成

CreateOneToManyRequest または UpdateRelationshipRequest を使用するときは、OneToManyRelationshipMetadata クラスのインスタンスを要求の本体に含めます。 そのクラスの CascadeConfiguration プロパティでは、CascadeConfiguration クラスを使用します。

CascadeConfiguration (CascadeConfiguration クラスまたは CascadeConfiguration ComplexType) には、一対多の関係で参照されるテーブルに対して実行可能なアクションを表すプロパティが含まれます。 各プロパティには、CascadeType EnumType の値のいずれかを割り当てることができます。

Value アプリケーション ラベル 内容
Active アクティブ レコードのみに伝播 参照されているテーブルレコードに関連するすべてのアクティブな参照テーブル レコードに対してアクションを実行します。
伝播 すべてのレコードに伝播 参照されているテーブル レコードに関連するすべての参照テーブル レコードに対してアクションを実行します。
NoCascade 伝播しない 何もしません。
リンクの解除 記事のリンク解除 参照されているテーブル レコードに関連するすべての参照テーブル レコードの参照列の値を削除します。
制限する 制限する 参照しているテーブルが存在する場合に、参照しているテーブルのレコードが削除されないようにします。
UserOwned 同一所有者のレコードのみに伝播 参照されているテーブル レコードと同じユーザーが所有するすべての参照テーブル レコードに対してアクションを実行します。

カスケード処理の対象となるアクティブなレコード

アクティブなレコードに対するアクションのカスケード処理には、状態コードが "Active" のレコードのみが含まれます。 これらのテーブルの次の状態コードは、アクションのカスケード処理に対してアクティブと見なされます。 異なるテーブルのこの状態コードには、異なるラベル (アクティブ以外) が使用される場合があります。 以下以外の値を持つカスタム状態またはステータス コードは、カスケードの目的でアクティブ レコードとして処理されません。

テーブル名 状態コード 0 状態コード 1 状態コード 2 状態コード 3
アカウント x
BulkOperation x
BulkOperation x
CampaignResponse x
連絡先 x
電子メール x
FAX x
インシデント x
IncidentResolution x
請求書 x
​​リード x
レター x
営業案件​​ x
OpportunityClose x
OrderClose x
PhoneCall x
受注 x
タスク​ x
すべてのカスタム テーブルとカスタム アクティビティ x
見積もり x
契約 x
予定​​ x
ServiceAppointment x
RecurringAppointmentMaster x

CascadeConfiguration (CascadeConfiguration クラスまたは CascadeConfiguration) には、一対多の関係で参照されるテーブルに対して実行可能なアクションを表す、次のプロパティが含まれます。

操作​​ 内容 有効なオプション
割り当てる 参照されるテーブル レコードの所有者および/または部署が変更されます。 アクティブです
伝播
NoCascade
UserOwned
Delete キー 参照されているテーブルのレコードが削除されます。 注: この操作のオプションは制限されます。 伝播
リンクの解除
制限する
結合 レコードが別のレコードと結合されます。 注意: マージ可能な参照テーブルについては、カスケードが唯一の有効な選択肢となります。 それ以外の場合は NoCascade を使用します。 伝播
NoCascade
リペアレント 後で リペアレント操作について を参照してください。 アクティブです
伝播
NoCascade
UserOwned
共有​​ 参照されているテーブルのレコードを他のユーザーと共有している場合。 アクティブです
伝播
NoCascade
UserOwned
共有の解除 参照されたテーブル レコードの共有が解除された場合。 アクティブです
伝播
NoCascade
UserOwned

注意

次の状況では、割り当て、削除、マージ、リペアレントのアクションは実行されません。

  • 元の親レコードと要求されたアクションに同じ値が含まれている場合。 例:割当のトリガーを試行し、すでにレコードの所有者となっている担当者を選択します
  • 縦続する処理が既に実行されている親レコードに対して操作の実行を試行する

注意

割り当てを実行すると、レコードで現在アクティブなワークフローまたはビジネ スルールは、再割り当てが行われた際に自動的に非アクティブになります。 レコードの新たな所有者がワークフローまたはビジネス ルールを引き続き使用する場合は、そのワークフローまたはビジネス ルールを再度有効化する必要があります。

割り当てアクションについて

割り当てアクションを使用すると、親レコードが更新されたときに、所有者、所属部署、または所有者と部署の両方の更新をすべての子レコードにカスケードできます。

部署全体のレコードの所有権の許可が有効化されていません

部署全体でレコードの所有権を許可する が有効になっていない場合、レコードの所有者を変更するときに、所属部署列を明示的に更新することはできません。 以下に、親のレコード所有者が更新されたときのカスケード動作を示します。

所有者を更新する場合:

  • 既定のカスケード割り当て動作 (すべてカスケード)
    • レコード所有者が新しい所有者で更新された
    • レコード部署が新しい所有者の部署に更新された
    • 子レコードの所有者が新しい所有者で更新された
    • レコード部署が新しい所有者の部署に更新された
  • カスケード割り当てがなしに設定
    • レコード所有者が新しい所有者で更新された
    • レコード部署が新しい所有者の部署に更新された
    • 子レコードの所有者は更新されません (カスケードなし)
    • 子レコードの部署が更新されていない (カスケードなし)

部署全体のレコードの所有権の許可が有効化されている

部署全体でレコードの所有権を許可する が有効になっている場合、レコードの所有者を変更するときに、所属部署列を明示的に更新することはできません。 以下に、親のレコードおよび / または部署が更新されたときのカスケード動作を示します。

AlwaysMoveRecordToOwnerBusinessUnit環境データベースの設定 で設定でき、Microsoft Dynamics CRM の OrgDBOrgSettings ツール を使用して設定できます。

  1. 所有者を更新する場合:

    AlwaysMoveRecordToOwnerBusinessUnit = true (規定)

    • 既定のカスケード割り当て動作 (すべてカスケード)
      • レコード所有者が新しい所有者で更新された
      • レコード部署が新しい所有者の部署に更新された
      • 子レコードの所有者が新しい所有者で更新された
      • レコード部署が新しい所有者の部署に更新された
    • カスケード割り当てがなしに設定
      • レコード所有者が新しい所有者で更新された
      • レコード部署が新しい所有者の部署に更新された
      • 子レコードの所有者は更新されません (カスケードなし)
      • 子レコードの部署が更新されていない (カスケードなし)
  2. 部署を更新する場合:

    AlwaysMoveRecordToOwnerBusinessUnit = true (規定)

    • 既定のカスケード割り当て動作 (すべてカスケード)
      • レコード所有者は更新されません
      • レコード部署が新しい部署に更新された
      • 子レコードの所有者が更新されていない
      • 子レコードの部署が新しい部署に更新された
    • カスケード割り当てがなしに設定
      • レコード所有者は更新されません
      • レコード部署が新しい部署に更新された
      • 子レコードの所有者が更新されていない
      • 子レコードの部署が更新されていない
  3. 所有者と部署を更新する場合:

    AlwaysMoveRecordToOwnerBusinessUnit = true (規定)

    • 既定のカスケード割り当て動作 (すべてカスケード)
      • レコード所有者が新しい所有者で更新された
      • レコード部署が新しい部署に更新された
      • 子レコードの所有者が新しい所有者で更新された
      • 子レコードの部署が新しい部署に更新された
    • カスケード割り当てがなしに設定
      • レコード所有者が新しい所有者で更新された
      • レコード部署が新しい部署に更新された
      • 子レコードの所有者が更新されていない
      • 子レコードの部署が更新されていない

OrgDBSettings AlwaysMoveRecordToOwnerBusinessUnit でカスケード動作を変更します

AlwaysMoveRecordToOwnerBusinessUnit を偽に設定できます。ユーザー所有のレコードの部署は、新しいユーザーの部署に移動されません。

AlwaysMoveRecordToOwnerBusinessUnit環境データベースの設定 で設定でき、Microsoft Dynamics CRM の OrgDBOrgSettings ツール を使用して設定できます。

  1. 所有者を更新する場合:

    AlwaysMoveRecordToOwnerBusinessUnit = 偽

    • 既定のカスケード割り当て動作 (すべてカスケード)
      • レコード所有者が新しい所有者で更新された
      • レコードの部署が更新されていない
      • 子レコードの所有者が新しい所有者で更新された
      • 子レコードの部署が更新されていない
    • カスケード割り当てがなしに設定
      • レコード所有者が新しい所有者で更新された
      • レコードの部署が更新されていない
      • 子レコードの所有者が更新されていない
      • 子レコードの部署が更新されていない
  2. 部署を更新する場合:

    AlwaysMoveRecordToOwnerBusinessUnit = 偽

    • 既定のカスケード割り当て動作 (すべてカスケード)
      • レコード所有者は更新されません
      • レコード部署が新しい部署に更新された
      • 子レコードの所有者が更新されていない
      • 子レコードの部署が新しい部署に更新された
    • カスケード割り当てがなしに設定
      • レコード所有者は更新されません
      • レコード部署が新しい部署に更新された
      • 子レコードの所有者が更新されていない
      • 子レコードの部署が更新されていない
  3. 所有者と部署を更新する場合:

    AlwaysMoveRecordToOwnerBusinessUnit = 偽

    • 既定のカスケード割り当て動作 (すべてカスケード)
      • レコード所有者が新しい所有者で更新された
      • レコード部署が新しい部署に更新された
      • 子レコードの所有者が新しい所有者で更新された
      • 子レコードの部署が新しい部署に更新された
    • カスケード割り当てがなしに設定
      • レコード所有者が新しい所有者で更新された
      • レコード部署が新しい部署に更新された
      • 子レコードの所有者が更新されていない
      • 子レコードの部署が更新されていない

注意

AlwaysMoveRecordToOwnerBusinessUnit = 偽 の場合

必要な特権

  • 親レコードの所有者特権が検証されます。 所有者や部署を更新すると、更新を許可する前に、所有者が部署の権限を持っていることを確認します。
  • ただし、子レコードに対するレコードの所有者特権は検証されません。 親レコードの部署を更新し、部署が子レコードにカスケードされている状況に遭遇する可能性があります。子レコードの所有者は自分のレコードにアクセスできなくなる可能性があります。

例 1

親レコードは部署 A の所有者1に属し、部署 B の所有者2に属する子レコードがあります。所有者 1 には部署 A および B からセキュリティ ロールが割り当てられているため、子レコードにアクセスできます。 親レコードが所有者 3 に更新されると、子レコードの所有者も所有者 3 に変更されますが、子レコードは引き続き部署 B に属します。所有者がビジネスユニット B でセキュリティ ロールを持っていない限り、所有者3はこれらの子レコードにアクセスできません。

例 2

親レコードは部署 A の所有者 1 に属し、部署 B の所有者 2 に属する子レコードがあります。所有者 1 には部署 A、B、および C からセキュリティ ロールが割り当てられているため、子レコードにアクセスできます。 所有する部署が部署 C に変更されると、子レコードの部署は部署 C に変更されます。これらの子レコードの所有者 2 は、ユニット C からセキュリティ ロールが割り当てられていない限り、レコードにアクセスできません。

リペアレント操作について

リペアレント アクションは、明示的なアクセス権ではなく継承されたアクセス権を扱うという点を除いて、共有 アクションと非常に類似しています。 リペアレント アクションは、親関係にある参照列の値を変更する場合です。 リペアレント アクションが発生すると、関連するテーブルの ReadAccess、WriteAccess、DeleteAccess、AssignAccess、ShareAccess、AppendAccess、AppendToAccess について、継承されるアクセス権に要求する範囲が変更される場合があります。 CreateAccess では変更されません。 リペアレント アクションに関連するカスケード アクションは、テーブル レコードとそれに関連するテーブル レコードに対して上記アクセス権の変更を参照します。

マージ操作について

マージ システム ジョブの実行中に操作セットの一部であるレコードが削除された場合、マージ アクションが完了する際に問題が発生することがあります。 多くの場合、これは、レコードが「異なる親子関係」を示すエラーになるか、子レコードが「親子関係を失う」ことを示すエラーになります。 これが発生し、レコードが見つからなくてもマージを続行する場合は、マージする列を選択する際に親のチェックを無効にすることができます。

注意

2 つのカスタム テーブル間でマージを実行すると、DateTime 値がマージされませんでした。 ターゲット レコードの DateTime は変更されません。

伝播通知

2 つのカスケード非同期通知ヘルパー メッセージを使用して、カスケード非同期ジョブが失敗や成功したときに、ユーザーやログに通知を提供します。 これはカスタム プラグインを作成し、登録することで実現します。このプラグインはメッセージを処理する際に実行され、成功または失敗の通知を提供します。

2 つの通知メッセージは次のとおりです。

  • cascadeAsync_FailureAPI
    非同期カスケード ジョブが複数の障害が原因で一時停止した場合、このメッセージが処理 (実行) されます。 既存のプラグインの問題、データの問題、ワークフローの問題についてデータセットを確認すべきことを、これを使用してユーザーに通知できます。
  • cascadeAsync_SuccessAPI
    非同期カスケードジョブが正常に完了した場合、このメッセージが処理 (実行) されます。 これは実行時間の長いジョブが終了したときにユーザーに通知する際に便利です。

カスタム プラグインは、操作後のステージで登録し、非同期モードに設定する必要があります。 プラグイン登録ツールを使用したプラグイン登録の例を、次の図に示します。

カスケード通知用のプラグインを登録する

カスタム プラグインが提供できる通知の種類の例を次に示します。

  • 成功時にエントリをランタイム ログに追加する
  • 失敗時にはランタイム ログにエントリを追加してから、障害の日時と性質を示すメール (またはその他の通信) を管理者に送信します
  • インタラクティブ ユーザーにメッセージを表示する

詳細情報: カスタム API の作成と使用; カスタム API 用のプラグインを作成する

関連情報

テーブルの関係を定義する

注意

ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。