アウトバウンド マーケティングを使用してアウトバウンド マーケティングの承認機能を構築する
注意
Dynamics 365 Marketing と Dynamics 365 Customer Insights は Customer Insights - Journeys と Customer Insights - Data になりました。 詳細については、Dynamics 365 Customer Insights のよくあるご質問 をご覧ください
Customer Insights - Journeys の新しい顧客には、リアルタイム体験機能のみが提供されます。 詳細については、既定のリアルタイム体験のインストールを参照してください。
重要
この記事は、アウトバウンド マーケティングにのみ適用されます。
Dynamics 365 Customer Insights - Journeys では、開発者に新たな可能性をもたらす拡張機能でインフラストラクチャを提供しています。この新たな拡張機能を活用する 1 つの方法は、承認機能を作成することであり、Power Automate との統合が含まれる場合があります。
このトピックでは、マーケティング Customer Insights - Journeys の承認機能を開発する方法の概要を説明します。 ここに記載されている機能を使用することで、組織は承認ワークフローを実装することができます。一部の重要なタイプのエンティティ (電子メール、顧客体験、セグメント) を作成しているユーザは、このワークフローを、すぐにライブに移行することはできません。 その代わり、承認者は各レコードを検査して、ライブへ移行を許可するかどうか、またはさらになる作業が必要となるかどうかを判断する必要があります。 一般的に承認者とは、システム内で承認者として指定されている管理者、またはマネージャーです。
重要
ここで説明する承認機能は、同僚間の協業ワークフローをサポートすることを目的としており、設定が未完了となっているエンティティが誤って本番リリースされることを防止します。 また、ユーザーが承認されていない状態からライブへ移行することを防止するプラグインの開発、レコードのフィールド (承認が必須、承認されたユーザー、有効な状態のユーザー) をユーザーが編集できないようにするプラグインを開発することが推奨されます。
承認プロセス
このトピックに記載しているカスタマイズは、以下のような承認ワークフローの設計と実装に役立ちます:
標準ユーザー (承認されていないユーザーで、マーケターと呼びます) に対しては、承認が有効化したエンティティフォーム上ではライブへ移行ボタンは表示されません。 かわりに、 承認のリクエスト ボタンがコマンドバー上に表示されます。 これらのエンティティでは、カスタマイズされたステータス値の集合が使用され、これは各レコードの承認状態の追跡に使用されます。 承認を必要とするレコードは、 要承認 のステータスで始まります。
マーケターが新規レコード (電子メールのデザインなど) の作成を完了した際に、承認の送信ボタンを選択すると、エンティティが有効であると確認され、以下の変更がトリガーされます。
- このレコードのステータスは、 承認リクエスト済に変わります。
- このレコードは変更ができなくなります。
- 電子メール メッセージは、システムで設定された承認者に自動的に送信され、承認が必要なことを伝えます。 このメッセージには、承認か拒否をおこなうボタンが含まれています。 これには、Dynamics 365 Customer Insights - Journeys (承認ボタンと拒否ボタンのあるところ) で関連レコードを表示するリンクがあります。
- 承認者には、承認ボタンと 拒否ボタンがコマンドバー上に表示されます。
承認者は以下に示すいずれかの応答をして下さい:
- 承認: レコードのステータスが承認に変更されます。 このレコードでは、すべてのユーザーが 本番リリース ボタンを使用することができます。 このレコードの編集が行われない限り、すべてのユーザがこのレコードをライブに移行することができます。 ユーザーが承認済みのレコードの編集を行う場合、ライブに移行ボタンは再び 承認のリクエストボタンに変わり、ステータスは要承認へと変わります。
- 拒否: レコードのステータスが拒否に変更されます。 承認のリクエストボタンが再びコマンドバー上に表示されます。 この時点でユーザーは修正を行い、その後承認の再申請をすることができます。
レコードが承認され、稼働されるまではこのプロセスを繰り返します。
承認をサポートする拡張機能
Customer Insights - Journeys ソリューション (8 月リリース以降) では次の関数が追加されており、複雑なライフサイクル (マーケティング メール、顧客体験、コンテンツ設定、マーケティングページ、マーケティングフォーム、セグメント) を持つエンティティの既定のロジックを上書きするか使用することができます。
| 関数名: | 説明 |
|---|---|
| MsDynCrmMkt.ExtensibilityCallback.liveEditablePreAction | エンティティがライブで編集可能状態となる前に、実行するコードを実装するために使用します。 |
| MsDynCrmMkt.ExtensibilityCallback.customUpdateFormControls | エンティティのメイン フォームが実行されたときにトリガーされます。 これにより、ページ内のすべてのコントロールのロックを解除して編集可能にすることができます。 |
| MsDynCrmMkt.ExtensibilityCallback.canGoLive | ロジックを完全に上書きし、ライブに移行リボンの表示/非表示を切り替えることができます。 |
| MsDynCrmMkt.ExtensibilityCallback.preventSave | エンティティの保存動作を制御することができます。 |
| MsDynCrmMkt.ExtensibilitySupplier.entityValidator | バリデーター ファクトリを返します。 正しく初期化が行われた後、特定のエンティティーの構成が有効であるかどうかを確認するために使用することができます。 |
Customer Insights - Journeys ソリューションのカスタマイズのためにとどまる唯一の制限事項は、以下のとおりです:
- 遷移状態 (ライブへ移行および停止中) と固定ステージの間の新しい状態は無視されます。
- ライブへ移行状態を経由せずに、直接ライブ状態へと移行する場合は、エンティティの値が変更されていないことを確認してください。
- 既存の状態を削除しないでください。
- エンティティが非アクティブ状態になると、再アクティブ化することはできません。
実装
手順 1: 新しいソリューションを作成する
新規ソリューションを作成し、サンプル承認という名前を付けます。
ソリューションに顧客体験エンティティを追加します。
ソリューション>承認サンプル>エンティティ>顧客体験>フィールドへと移動します。
Statuscode属性を選択し、以下の新規ステータスを追加します。
Approved
承認依頼済
Note
作成した新規ステータスの値をコピーして下さい。これを後で使用します。 これらの値は、カスタムリボンボタンを作成する際に必要となります。
ステータスの移行方法の編集を選択し、オプションの横で使用可能な省略記号 (...) を選択して、以下のようにステータスを追加し、Okをクリックします。
新規フィールド msdyncrm_restorestatuscode を作成し、データ種別を 整数とします。このフィールドには、以前の状態に関する情報が格納されます。
ソリューション内で、「承認」などの名前を付けた新しいエンティティーを作成します。 このエンティティーを使用して、システムにログインしたユーザーが承認者かマーケターかを判断します。
承認者とマーケターの 2 人の新規ユーザーを作成します。 承認者は上記で作成されたエンティティへの書込みアクセス権を持ち、マーケターはシステム管理者またはシステム カスタマイザの権限はありません。
手順 2: リボン ボタンを作成する
このソリューションを機能させるには、3つのカスタムリボンボタンを作成する必要があります。これについては以下で説明します。 カスタムのリボン ボタンを作成するには、コマンドとリボンのカスタマイズを参照するか、Microsoft コミュニティで利用可能なツールを使用してください。
| リボン | ルールを有効化する | アクション |
|---|---|---|
| 承認 | - 承認者になる - 承認が必要な状態となる |
エンティティを承認済ステータスへと移行します。 |
| 拒否 | - 承認者になる - 承認が必要な状態となる |
エンティティを以前の状態へと戻す (msdyncrm_rstorestatuscodeフィールドを使用して取得)。 |
| 承認の要求 | - マーケターになる - ドラフト、エラー、停止のステータスである |
エンティティの実際のステータスを msdyncrm_restorestatuscode フィールドに保存し、エンティティの検証チェックを実行します。エンティティが有効である場合、エンティティは承認依頼済みのステータスになります。 |
管理者はマーケターが 稼働中 編集可能 のステータスになることがないよう、留意する必要があります。 ドラフト、エラー、停止のステータスから承認のリクエストが発生し、承認者がこの変更を拒否をした場合に、この変更が保持されるため、マーケターの判断で新規変更がなされます。 「稼働中-編集可能」となっているステータスのレコードを承認者が拒否すると、「稼働中」のステータスに戻されるため、このロジックをライブ「稼働中-編集可能」のステータスに適用することはできません。 もしこの変更が保存されるようになった場合は、フォームに表示される内容がサービスに保存されている内容と異なるため、ユーザーが混乱するおそれがあります。
この問題を回避するためには、マーケターが行った変更を元に戻すことになります。 エンティティーに多くのカスタマイズがされていない場合は、エンティティー内に追加フィールドを設置し、レコードが「稼働中-編集可能」のステータスになった際にこのフィールドを使用してエンティティーをシリアライズすることを推奨します。
これを実現するにあたり、新たな拡張ポイント MsDynCrmMkt.ExtensibilityCallback.liveEditablePreActionを導入します。 前述のように名前を付けたフォームのロード時にイベントを作成することで、レコードが「稼働中-編集可能」のステータスになった際にこのコードが呼び出されます。 デシリアライズは、拒否リボンのアクション内、プラグイン内のどちらでも実行できます。 第2のアプローチを強く推奨するのは、それが型定義に対して有用な制御を与え、 Power Automate の統合との互換性があるためです。
手順 3: 拡張ポイントを活用する
この例では、上述の拡張ポイントのうち 2 つを使用する必要があります。 両方とも、以前作成した新しいソリューション内の顧客体験のメイン フォームのロード時のイベントとして追加してください。
- MsDynCrmMkt.ExtensibilityCallback.canGoLive: この関数が定義されている場合は、ライブに移行ボタンを表示する時を決定するために使用されます。 この例では、エンティティが下書き、エラー、停止状態で、ログインしているユーザーはマーケターであるか、自分たちが承認済み状態にあることを確認する必要があります。
- MsDynCrmMkt.ExtensibilityCallback.customUpdateFormControls: この関数が定義されている場合は、フォームが完全に読み込まれた後に実行されます。 これの使用例としては、マーケターが編集できるよう、フィールドのロックを解除することができます。
手順 4: 2つのシステム ビューを作成する
要承認と承認のステータスのエンティティを特定するには、承認が必要なすべてのエンティティと、承認済みで ライブへ移行前となっているエンティティを表示する 2 つのシステムビューを、顧客体験の内部に作成することを推奨しています。 詳細: ビューの作成または編集