リアルタイム体験では、 連絡先ポイント レベル (メール アドレス、電話番号、またはカスタム チャネル アドレス) で同意が収集、管理、適用されます。 メッセージが連絡先、潜在顧客、または Customer Insights - データ プロファイルに送信されると、Customer Insights - Journeys アプリは、メッセージが送信される特定の連絡先ポイントと、メッセージを送信する前にメッセージの特定の目的またはトピックの 同意を確認 します。
Customer Insights - Journeys フォームを使用して同意を収集している場合は、連絡先ポイントの同意レコードが自動的に作成されます。 ただし、外部システムで同意を管理している場合、または顧客からの同意を収集するカスタム構築ユーザー エクスペリエンス (ランディング ページや基本設定センターなど) がある場合は、同意センター ( msdynmkt_contactpointconsent4
テーブル) で連絡先ポイントの同意レコードを作成または更新して、システムからメッセージを送信することが必要になる場合があります。
システムで連絡先ポイントの同意レコードが必要なシナリオはどれですか?
適切な監査を行うには、常に同意をシステムに記録する必要があります。 場合によっては、システムに明示的なオプトイン同意レコードを含めなくても、体験 (たとえば、非応答の目的で電子メールを送信する体験) を実行できます。 ただし、同意レコードが常にシステムに存在する必要がある場合があります。
- 制限付き適用モデルで送信された電子メール: 電子メールの同意適用モデル が 制限に設定されている場合、システムでは、電子メール メッセージを送信する同意センターで明示的なオプトイン レコードが必要です。 明示的なオプトイン レコードが見つからない場合、電子メール メッセージは送信されません。
- 非制限の適用モデルベースの目的でオプトアウトを更新する: 電子メール強制モデルを 非制限に設定した場合は、外部システム ( Customer Insights - Journeys フォーム または 基本設定センター エクスペリエンスから収集されたもの以外) に記録されたオプトアウトが同意センターに適切に反映されるようにして、リアルタイムの体験でその連絡先ポイントへのメッセージの送信を停止できるようにする必要があります。
- 商用目的での SMS またはカスタム チャネル体験: 適用モデルの柔軟性は、SMS またはカスタム チャネルにはまだ拡張されていません。 そのため、商用の種類の SMS またはカスタム チャネルの体験が作成された場合、システムはメッセージを送信するために明示的なオプトイン同意レコードを必要とします。
クラウド フローを使用する必要がある場合
読み込み同意 は、連絡先、潜在顧客、サブスクリプションまたはマーケティング リストから同意センターに簡単に同意レコードを読み込むのに役立ちます。 ただし、新しい連絡先または潜在顧客レコードを作成する自動化またはプロセスを継続的に実行している場合、負荷の同意を手動で実行すると、運用上の負担になる可能性があります。
このような場合は、クラウド フローを使用して、同意センターでの連絡先ポイントの同意レコードの作成と更新を自動化できます。
クラウド フローが連絡先ポイントの同意レコードの作成に役立つ一般的なシナリオを次に示します。
- 一括インポート、Dataverse API、またはカスタム フローを通じて継続的に作成された連絡先または潜在顧客: Customer Insights - Journeys フォーム以外の方法を使用して連絡先と潜在顧客を定期的に作成する場合は、同意センターで連絡先ポイントの同意レコードを作成または更新することが必要になる場合があります。 ユーザーがシステムで連絡先や潜在顧客を作成する最も一般的な方法は、Excel インポート機能を使用することです。 Dataverse API またはカスタム クラウド フローを使用して作成された連絡先または潜在顧客にも、同じガイダンスが適用されます。
- Customer Insights - Customer Insights のデータ プロファイルとセグメントを使用する場合 - 体験: システム内の他のすべての体験と同様に、Customer Insights を使用する場合 、 Customer Insights のデータ プロファイルとセグメント – 体験では、メッセージが送信される連絡先ポイントに対して常に同意が確認されます。 そのため、これらの体験を使用してメッセージを送信するには、同意センターで連絡先ポイントの同意レコードが必要になる場合があります。
- 外部の同意管理システムの使用: 外部システムで同意を管理している場合、制限付きまたは非制限的な適用モデル、および前述の SMS またはカスタム チャネル体験のさまざまなケースで、同意センターで同意レコードを作成または更新する必要があります。
クラウド フローの構築
次に、サンプル クラウド フローを見て、連絡先ポイントの同意レコードを作成および更新するためのクラウド フローを構築するために必要なさまざまな手順を理解します。
この例では、Contoso の Web サイトにランディング ページがあり、顧客が Contoso のサービスを受け取るためにサインアップするために入力します。 顧客がフォームに入力すると、Contoso はクラウド フローを使用して、Dataverse 環境で連絡先レコードを自動的に作成します。 Contoso はリアルタイムの体験を使用し、ランディング ページの申請から作成された各連絡先の同意を取得したいと考えています。
連絡先のメール アドレスを取得し、同じメール アドレスを持つ連絡先ポイントの同意レコードが連絡先ポイントの同意 (msdynmkt_contactpointconsent4) テーブルに存在するかどうかを確認します。
電子メール アドレスの連絡先ポイントの同意レコードが見つからない場合、フローによって、"オプトイン" 状態の電子メール アドレスの新しい連絡先ポイントの同意レコードが作成されます。 既存の同意レコードが見つかると、フローによって最新の同意値で更新されます。
フローに含まれる手順の概要を次に示します。
アクション トリガー "行が追加、変更、または削除されたとき" を追加します。
変更の種類を [追加または変更済み] に設定し、テーブル名を [連絡先] に設定します。 このアクションは、新しい連絡先レコードが追加されたとき、または既存のレコードが変更されるたびにクラウド フローをトリガーします。
注
この例では、組織内に 1 つの部署があり、複数の部署のシナリオについては説明していないものとします。
"変数を初期化する" アクションを追加して、連絡先ポイントの同意レコードに含める同意値を設定します。 ここでは、
donotemail
とdonotbulkemail
フィールドの値を使用し、両方のフィールドが false の場合にのみ、連絡先ポイントの同意をオプトインに設定することをお勧めします (false はAllowed for Email and Bulk Email
を表します)。 それ以外の場合は、連絡先ポイントの同意レコードをopt-out
に設定します。計算に使用できるロジックを次に示します。
if(and(equals(triggerBody()?['donotemail'], false), equals(triggerBody()?['donotbulkemail'], false)),534120001,534120002)
この場合、式はトリガー本体の 2 つのフィールド (
donotemail
とdonotbulkemail
) の両方が false であるかどうかをチェックします。 両方が false の場合、数式は534120001
値を返します。 両方とも false でない場合、数式は534120002
値を返します。-
534120001
はオプトインの同意状態の値です。 -
534120002
は、オプトアウトの同意状態の値です。
-
"変数を初期化する" アクションを追加して、連絡先ポイントの同意レコードを作成または更新する必要がある目的の GUID を設定します。
目的の GUID を見つけるには、[ 目的] に移動します。 コンプライアンス プロファイルに移動し、[ 同意の目的 ] タブに移動し、[ 目的] を選択します。 目的の GUID は、URL の末尾に存在します。
次に、[行の一覧表示] にアクションを追加して、電子メール アドレスと目的の組み合わせについて、連絡先ポイントの同意テーブルに既存のレコードが存在するかどうかを確認します。
ここでは、連絡先の電子メール アドレスと同じメール アドレスを持ち、同意レコードを作成または更新する目的の連絡先ポイントの同意レコードを探しています。
-
msdynmkt_contactpointconsenttype
属性は、レコードが目的の同意レコードかトピックの同意レコードかを指定します。534120000
値は目的であり、534120001
はトピックを表します。 -
msdynmkt_contactpointtype
属性は、チャネル (電子メール、SMS、またはカスタム チャネル) を指定します。 この場合、534120000
は、ここで電子メールの同意レコードを処理する際の電子メールを表します。
注
ドロップダウン リストからテーブル名 "Contact Point Consent" を選択すると、同じ名前の 4 つの異なるレコードが見つかります。 最後の 1 つを選択します。
同意テーブルの msdynmkt_contactpointconsent4sを使用していることを確認します。 テーブル名を確認するには、アクションの右上にある 3 つのドット (...) を選択し、[コードの ピーク] を選択します。
-
同意レコードが存在するかどうかを検証する "条件" アクションを追加します。
リスト行ステップの "value" の動的コンテンツを参照することで、ここで使用できる式を次に示します。
empty(outputs('List_rows')?['body/value'])
この条件は、前に "行の一覧表示" ステップから一致する同意レコードが見つからなかった場合に true を返します。
既存の同意レコードが見つからない場合は、次のように連絡先ポイントの同意レコードを作成します。
[新しい行の追加] アクションを選択します。
次に示す値を使用して新しい行を作成します。
テーブル名: 連絡先ポイントの同意 (ここでも必ず
msdynmkt_contactpointconsent4s
を選択してください)。チャネル: 電子メール
同意の状態: 前の手順で設定した変数である必要があります (商用の同意)
連絡先ポイント: 作成または更新された連絡先レコードの電子メール アドレス
目的:
msdynmkt_purposes
(前の手順の目的 GUID 変数)理由: 理由なし
理由の説明: ここでは、任意の説明を指定できます。 これを使用して、クラウド フローを使用して作成されたレコードを一意に識別できます。
ソース: 内部
同意の種類: 目的
システムで同意レコードが見つかった場合、"条件" ステップは false になり、"Apply to each" アクションを実行して検出されたすべてのレコードを更新し、"行の一覧表示" ステップの各行に対して "行の更新" アクションを実行できます。
ここでは、前の手順の出力として、"行の一覧表示" ステップの "値" を選択します。
-
テーブル名: 連絡先ポイントの同意 (ここでも必ず
msdynmkt_contactpointconsent4s
を選択してください)。 - 行 ID: 動的コンテンツ ウィンドウから [Contact Point Consent]\(連絡先ポイントの同意\) を選択します
- 同意の状態: 前の手順で設定した変数である必要があります (商用の同意)
- 理由: 理由なし
- 理由の説明: ここでは、任意の説明を指定できます。 これを使用して、クラウド フローを使用して作成されたレコードを一意に識別できます。
- ソース: 内部
- 同意の種類: 目的
その他のフィールドは空白またはマップ解除したままにできます。
-
テーブル名: 連絡先ポイントの同意 (ここでも必ず
トピック同意レコードの作成
トピックは常に目的の下に作成され、システムは、トピックの同意を確認する前に、親の目的の同意を確認します。 親の目的の同意がオプトアウトに設定されている場合、トピックもオプトアウトとして扱われるので、同意の状態は関係ありません。
ワークフローでトピックの同意レコードを作成する必要がある場合は、上記の基本フローを使用して拡張します。
上記のフローでは、目的の同意レコードが作成され、更新されます。 目的の同意レコードに加えて、トピックの同意レコードを作成および更新する手順を追加します。 システムがトピックの同意をオプトインとして扱うには、親の目的の同意もオプトインする必要があります。 目的とトピックの両方の同意レコードを作成して更新し、システムが期待どおりに動作するようにフローを確認します。
トピックの同意レコードを作成するには、[ 同意の種類 ] の値を [トピック] に設定し、次の形式を使用してトピック (トピック) フィールドにトピックの GUID を入力します。 msdynmkt_topics(GUID of the topic)
注
残りのフィールドは必須ではありませんが、ユース ケースに基づいて入力します。
注意事項と考慮事項
監視とエラー処理
上記のソリューションの推奨事項に従う場合は、キューとエラーのクラウド フロー監視を設定することを検討してください。 エラーの調整と再送信が必要になる場合があります。 詳細については、以下を参照してください。
サード パーティのシステムとの同意の同期
同意センターで行われた変更を外部システムと同期すると、次のような循環ループをトリガーできます。
- 外部システムの変更により、Dynamics 365 で同意レコードの更新がトリガーされます。 Dynamics 365 の同意の更新により、外部システムで更新がトリガーされ、ループが続行されます。
これを回避するには、[理由の説明] フィールドを使用します。 Dynamics 365 と外部システムの間で同意を同期する各フローの理由の説明に一意の値を指定します。 次に、各フローでこれらの特定の値をチェックして、循環ループを中断します。
クラウド フローの ALM の管理
複数の環境 (開発、テスト/QA、運用環境など) があり、環境間で一貫性を保つクラウド フローが必要な場合は、ソリューションにクラウド フローを作成します。 詳細については、「 ソリューションでのクラウド フローの作成」を参照してください。