自動レコード作成および更新ルールによる一般的な構成問題のトラブルシューティング

この記事では、レコードの作成が失敗したりスキップされたりする可能性があるため、レコードの自動作成と更新ルールを使用する一般的な構成エラー シナリオの解決策について説明します。

シナリオ 1

サンプル: 自動レコード作成と更新ルールの構成

• [不明な送信者の連絡先を作成する] オプションを選択する必要があります。
• すべての受信電子メールに構成条件を設定します。
• ケースを作成するアクションを追加し、 View プロパティを選択し、ビジネス ユース ケースごとにケース フィールドを設定します。

エラー 1 - "ケースが顧客が見つかりません"

CASE DETAILS セクションの Customer フィールドで、Senders Account (Email)の値を次のように設定します。

この設定により、システム ジョブで次のエラーが発生します。

ケースに顧客が不足しています。

エラー 1 の解決

この問題を解決するには、 Customer フィールドを空白のままにするか、 {Sender(Email)}に設定します。 これにより、不明な送信者の連絡先が自動的に作成され、ケースにリンクされます。

エラー 2 - "エラーが発生しました"

Customer フィールドは {Senders Account(Email)}として設定され、Contact フィールドは {Sender(Email)} として設定されます。

この設定により、システム ジョブで次のエラーが発生します。

エラーが発生しました。 このアクションをもう一度試してください。 問題が解決しない場合は、Microsoft Dynamics 365 コミュニティで解決策を確認するか、組織の Microsoft Dynamics 365 管理者にお問い合わせください。 最後に、Microsoft サポートにお問い合わせください。

エラー 2 の解決

この問題を解決するには、 Customer フィールドを空白のままにするか、 {Sender(Email)}に設定します。 これにより、不明な送信者の連絡先が自動的に作成され、ケースにリンクされます。

エラー 3 - "指定した連絡先は、顧客フィールドで指定された連絡先に属していません。"

Customer フィールドと Contact フィールドは、{Sender(Email)}として設定されます。

この設定により、システム ジョブで次のエラーが発生します。

指定した連絡先は、顧客フィールドで指定された連絡先に属していません。 連絡先フィールドから値を削除するか、選択した顧客に関連付けられている連絡先を選択してから、もう一度やり直してください。

エラー 3 の解決方法

この問題を解決するには、 Contact フィールドを空白のままにし、 Customer フィールドを空白または {Sender(Email)}に設定します。

検証ステップ

次の表に示す構成と検証の手順を検証して、問題の主な原因を理解し、解決する必要があります。

シナリオ 2 - レガシ エクスペリエンスで {Regarding(Email)} を使用しても、フロー内の正しいデータが提供されない

Customer Service の従来の "レコードの自動作成と更新ルール" 項目では、電子メールを送信するエンティティ (連絡先またはアカウント) を検索するために、 Sender (Email) ポリモーフィックなルックアップを使用できます。この検索では、適切なエンティティが自動的にフェッチされ、エンティティの名前が表示されます。 ポリモーフィック ルックアップは、ルックアップのターゲットが複数の種類のエンティティであるルックアップです。 たとえば、取引先担当者またはアカウントのいずれかを指すことができます。 ただし、最新の "自動レコード作成および更新ルール" では、この自動表示はサポートされていないため、取得するエンティティの種類と、そのエンティティから表示するフィールドを指定する必要があります。

原因

フロー式は、前のフロー ステップのペイロードの 1 つからのデータ値を参照するため、フローは従来のワークフローのような {関連(電子メール)} 値を使用しません。 たとえば、フローの開始時に {Regarding(Email)} 値が空の場合、{Regarding(Email)} のトリガー ステップ ペイロードの値は空のままになります。 ケースの作成後に {Regarding(Email)} 値が更新された場合でも、電子メール レコード データは更新されますが、フロー内のペイロードは更新されません。 したがって、ペイロードからの値が後続のフロー ステップで参照されるとき、値は空のままになります。

解決方法

{Regarding(Email)}値がレガシ ルール項目で使用されている場合は、移行されたフローを手動で更新して"インシデント ID" または "OData ID" を使用する必要があります。エンティティ参照または参照を必要とするフィールドには、"OData ID" を使用します。 GUID を必要とするフィールドには、大文字と小文字の一意の識別子を使用します。

シナリオ 3 - レガシから最新の "自動レコード作成および更新ルール" への移行中に、非ルックアップ フィールドにポリモーフィックなルックアップをレンダリングする際の問題

Sender などのポリモーフィックなルックアップを使用する従来の "レコードの自動作成と更新ルール" アイテムは、テキスト フィールドに割り当てられると無効な参照になります。

Customer Service の従来の "レコードの自動作成と更新ルール" 項目では、電子メールを送信したエンティティ (連絡先またはアカウント) を検索するために、 Sender (Email) ポリモーフィックな検索を使用できます。この検索では、適切なエンティティが自動的にフェッチされ、エンティティの名前が表示されます。 ポリモーフィック ルックアップは、ルックアップのターゲットが複数の種類のエンティティであるルックアップです。 たとえば、取引先担当者またはアカウントのいずれかを指すことができます。 ただし、最新の "自動レコード作成と更新ルール" では、この自動表示はサポートされていません。 そのため、取得するエンティティの種類と、そのエンティティから表示するフィールドを指定する必要があります。

原因

従来の "レコードの自動作成と更新ルール" で使用される従来のワークフロー動作には、多くの非表示の動作があります。 たとえば、エンティティの種類を自動的に決定し、パラメーターが文字列で使用されている場合は表示名としてフィールドをフェッチし、ルックアップ フィールドに割り当てられている場合は ID を返します。 従来のワークフローから最新のワークフローに変換するときに "レコードの自動作成と更新ルール" で使用されるプラットフォーム移行コードでは、必要な手順とフィールドは追加されません。

解決方法

この問題を解決するには、

• ルックアップを特定のタイプに更新します。
• 目的のテキストを含む受信エンティティで別のフィールドを使用します。