次の方法で共有

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

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

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

Web API を使用する場合は、 OneToManyRelationshipMetadata エンティティ型を使用して一対多リレーションシップを定義します。 この定義には、作成する交差テーブルの名称と、AssociatedMenuConfiguration 複合型、Label 複合型、LocalizedLabel 複合型を使用して、アプリケーションにリレーションシップを表示する方法が示されています。

詳細については、「 Web API を使用して一対多リレーションシップを作成する」を参照してください。

SDK for .NET を使用してカスケード動作を構成する

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

CascadeConfiguration クラスまたは CascadeConfiguration 複合型には、一対多リレーションシップの参照先テーブルに対して実行される可能性があるアクションを表すプロパティが含まれています。 各プロパティには、CascadeType 列挙型の値のいずれかを割り当てることができます。

価値 アプリケーション ラベル 説明
アクティブです カスケードがアクティブ 参照されているテーブルレコードに関連するすべてのアクティブな参照テーブル レコードに対してアクションを実行します。
カスケード すべてをカスケードする 参照されているテーブル レコードに関連するすべての参照テーブル レコードに対してアクションを実行します。
NoCascade カスケードなし 何もしません。
リンクの解除 リンクを解除 参照されているテーブル レコードに関連するすべての参照テーブル レコードの参照列の値を削除します。
制限する 制限する 参照テーブルが存在する場合、参照先のテーブル レコードが削除されないようにします。
ユーザー所有 ユーザー所有のレコードにカスケードする 参照されているテーブル レコードと同じユーザーが所有するすべての参照テーブル レコードに対してアクションを実行します。

連鎖アクションと見なされるアクティブ なレコード

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

テーブル名 状態コード 0 状態コード 1 状態コード 2 状態コード 3
アカウント x
一括操作 x
一括操作 x
CampaignResponse x
連絡先 x
Email x
ファクス x
インシデント x
インシデント解決 x
請求書 x
​​リード x
レター x
機会 x
商談終了 x
オーダークローズ (OrderClose) x
電話 x
受注書 x
タスク​ x
すべてのカスタム テーブルとカスタム アクティビティ x
引用 x
契約 x
予約 x
サービス予約 x
RecurringAppointmentMaster x

SDK for .NET CascadeConfiguration クラス または Web API CascadeConfiguration 複合型 には、一対多リレーションシップの参照先テーブルに対して実行できるアクションを表す次のプロパティが含まれています。

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

注意

割り当て、削除、マージ、および親の再指定アクションは、以下の状況では実行されません。

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

注意

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

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

親レコードを更新すると、割り当てアクションによって、所有者、ビジネス単位、または所有者とビジネス単位の両方に対する更新がすべての子レコードに伝播されます。

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

ビジネス ユニット間のレコード所有権の許可が有効になっていない場合、レコードの所有者を変更するときに、所有する部署の列を明示的に更新することはできません。 次の一覧は、親のデータ所有者を更新するときのカスケード動作を示しています。

所有者を更新する場合:

  • 既定のカスケード割り当て動作 (全てカスケードする)
    • 新しい所有者に対するレコード所有者の更新
    • ビジネスユニットの更新を新しい所有者の部署に記録する
    • 子レコードの所有者が新しい所有者に更新される
    • 子レコードのビジネスユニットが新しい所有者のビジネスユニットに更新される
  • カスケード割り当てが「なし」に設定されている
    • 新しい所有者に対するレコード所有者の更新
    • ビジネスユニットの更新を新しい所有者の部署に記録する
    • 子レコードの所有者が更新されない (カスケードなし)
    • 子レコードの事業単位が更新されない (カスケードは適用されていません)

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

ビジネス ユニット間でレコードの所有権を許可するが有効になっている場合は、レコードの所有者を変更するときに、所有する部署の列を明示的に更新できます。 次の一覧は、親のレコード所有者と部署を更新するときのカスケード動作を示しています。

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

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

    AlwaysMoveRecordToOwnerBusinessUnit = true（規定設定）

    • 既定のカスケード割り当て動作 (全てカスケードする)
      • 新しい所有者に対するレコード所有者の更新
      • ビジネスユニットの更新を新しい所有者の部署に記録する
      • 子レコードの所有者が新しい所有者に更新される
      • 子レコードのビジネスユニットが新しい所有者のビジネスユニットに変更される
    • カスケード割り当てが「なし」に設定されました。
      • 新しい所有者に対するレコード所有者の更新
      • ビジネスユニットの更新を新しい所有者の部署に記録する
      • 子レコードの所有者が更新されない (カスケードなし)
      • 子レコードの事業単位が自動更新されません (カスケードの適用なし)

  2. 事業部を更新する場合:

    AlwaysMoveRecordToOwnerBusinessUnit = true（既定値）

    • 既定のカスケード割り当て動作 (全てカスケードする)
      • レコード所有者が更新されない
      • ビジネス ユニットの更新を新しい部署に記録する
      • 子レコードの所有者が更新されない
      • 子レコードの事業単位が新しい事業単位に更新される
    • カスケードの割り当てが「なし」に設定されました
      • レコード所有者が更新されない
      • ビジネスユニットの更新を新しいビジネスユニットに記録する
      • 子レコードの所有者が更新されない
      • 子レコードの事業単位が更新されない

  3. 所有者と部署を更新する場合:

    AlwaysMoveRecordToOwnerBusinessUnit = 真 (規定)

    • 既定のカスケード割り当て動作 (全てカスケードする)
      • 新しい所有者に対するレコード所有者の更新
      • レコード部署を新しい部署に更新する
      • 子レコードの所有者が新しい所有者に更新される
      • 子レコードのビジネスユニットを新しいビジネスユニットに更新する
    • カスケードの割り当てが「なし」に設定されています。
      • 新しい所有者に対するレコード所有者の更新
      • レコードの事業部を新しい事業部に更新する
      • 子レコードの所有者を更新しない
      • 子レコードのビジネスユニットを更新しない

OrgDBSettings AlwaysMoveRecordToOwnerBusinessUnit を使用してカスケード動作を変更する

AlwaysMoveRecordToOwnerBusinessUnit を false に設定した場合、ユーザー所有レコードの部署は新しいユーザーの部署に移動されません。

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

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

    AlwaysMoveRecordToOwnerBusinessUnit = 偽

    • 既定のカスケード割り当て動作 (全てカスケードする)
      • 新しい所有者に対するレコード所有者の更新
      • レコードの事業単位を更新しない
      • 子レコードの所有者が新しい所有者に更新される
      • 子レコードのビジネスユニットを更新しない
    • カスケードの割り当てが「なし」に設定されています。
      • 新しい所有者に対するレコード所有者の更新
      • レコードビジネスユニットを更新しない
      • 子レコードの所有者を更新しない
      • 子レコードのビジネスユニットを更新しない

  2. 事業部を更新する場合:

    AlwaysMoveRecordToOwnerBusinessUnit = 偽

    • 既定のカスケード割り当て動作 (全てカスケードする)
      • レコード所有者が更新されない
      • ビジネスユニットの更新を新しいビジネスユニットに記録する
      • 子レコードの所有者が更新されない
      • 子レコードの事業単位が新しい事業単位に更新される
    • カスケードの割り当てが「なし」に設定されています。
      • レコード所有者が更新されない
      • ビジネスユニットの更新を新しいビジネスユニットに記録する
      • 子レコードの所有者が更新されない
      • 子レコードの事業単位が更新されない

  3. 所有者と部署を更新する場合:

    AlwaysMoveRecordToOwnerBusinessUnit = 偽

    • 既定のカスケード割り当て動作 (全てカスケードする)
      • 新しい所有者に対するレコード所有者の更新
      • レコードの事業部を新しい事業部に更新する
      • 子レコードの所有者が新しい所有者に更新される
      • 子レコードのビジネスユニットを新しいビジネスユニットに更新する
    • カスケードの割り当てが「なし」に設定されています。
      • 新しい所有者に対するレコード所有者の更新
      • レコードの事業部を新しい事業部に更新する
      • 子レコードの所有者を更新しない
      • 子レコードのビジネスユニットを更新しない

注意

AlwaysMoveRecordToOwnerBusinessUnit = 偽 の場合

必要な特権

  • 親レコードの所有者権限が検証されます。 所有者または部署を更新すると、検証によって、更新が許可される前に、その所有者が部署の権限を持っているかどうかが確認されます。
  • ただし、子レコードに対する所有者特権の検証は行われません。 親レコードのビジネスユニットを更新すると、それが子レコードに連鎖され、結果的に子レコードの所有者がそのレコードへのアクセスを失う可能性がある場合があります。

例 1

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

例 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 このメッセージは、複数の障害が原因で非同期カスケード ジョブが一時停止したときに処理 (実行) されます。 このメッセージを使用して、既存のプラグイン、データの問題、またはワークフローの問題についてデータセットを確認する必要があることをユーザーに通知します。
InputParameters:
casadeAsyncExceptionDetails: カスケード非同期ジョブの失敗を引き起こした例外の詳細。
casadeAsyncJobName:カスケード非同期ジョブの名前です。
cascadeAsync_SuccessAPI 非同期カスケードジョブが正常に完了した場合、このメッセージが処理 (実行) されます。
InputParameters:
casadeAsync_JobName: カスケード非同期ジョブの名前です。

操作後の段階でカスタム プラグインを登録し、非同期モードに設定します。 次の図は、プラグイン登録ツールを使用したプラグイン登録の例を示しています。

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

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

  • 成功したら、実行時ログにエントリを追加します。
  • 失敗した場合は、実行時ログにエントリを追加し、エラーの日時と性質を示す電子メール (またはその他の通信) を管理者に送信します。
  • 対話型ユーザーにメッセージを表示します。

継承されたアクセス修復

再親アクションまたは共有アクションのテーブル リレーションシップの連鎖動作を No Cascade に変更した後、システムは、現在のテーブル リレーションシップのカスケード動作に一致するようにユーザーの継承されたアクセス権を調整しようとします。 継承されたアクセス権のクリーンアップについて詳しくは、こちらをご覧ください。

ただし、この方法が成功しなかった場合、ユーザーは削除する必要がある関連レコードへのアクセスを保持する可能性があります。 この問題に対処する手順については、「 継承されたアクセスをクリーンアップする」を参照してください。

参照

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

  • Last updated on