ダイアログをビジネス プロセス フローまたはキャンバス アプリに置き換える
ダイアログは非推奨 となりましたので、ビジネス プロセス フローまたはキャンバス アプリに置き換える必要があります。 この記事では、これらのオプションのさまざまな機能について説明します。 また、モデル駆動型フォームに埋め込まれたビジネス プロセス フローたキャンバス アプリを使用して、既存のダイアログを置き換えることができる状況について説明します。
機能の性能比較
次の表に、ダイアログの機能セットと、それに相当するビジネス プロセス フローおよびキャンバス アプリ内の機能を一覧表示します。
| ダイアログの機能 | 相当する機能がビジネス プロセス フロー内にあるか? | 相当する機能がキャンバス アプリ内にあるか? |
|---|---|---|
| ページ | はい (ビジネス プロセス フロー) |
はい (アプリ画面) |
| プロンプトのみ | いいえ | はい (ラベル) |
| プロンプトと応答 | はい (テーブル列のみ) |
はい (ラベルと入力フィールド) |
| 入力引数 | 制限あり (ビジネス プロセス ステージ内の手順) |
はい (クエリ文字列パラメーター) |
| 変数 | いいえ | はい |
| クエリ変数 | いいえ | はい |
| 条件分岐ロジック | はい | はい (アプリ内の任意の画面に移動) |
| 再利用 (子ダイアログとして起動) |
いいえ | はい (アプリ内の任意の画面に移動、異なるアプリを新しいウィンドウで起動) |
| 開始または終了時にワークフローを実行 | はい | いいえ (代わりにクラウド フローを使用) |
| 入力時にワークフローを実行 | はい | いいえ (代わりにクラウド フローを使用) |
| ページの切り替え時にワークフローを実行 | はい | いいえ (代わりにクラウド フローを使用) |
| URL を使用して開始 | いいえ | はい |
| セッションのログ記録 | はい | いいえ |
| SDK サポート | はい | はい |
ビジネス プロセス フローでの追加の機能
- プロセス分析 (ビュー、グラフ、および 1 つのステージで費やされた時間)
- カスタム コントロール
キャンバス アプリでの追加の機能
- アプリの分析 (アプリの使用状況とパフォーマンス)
- 複数テーブル ページによる構成
- フローの実行
- データ コネクタ (標準とカスタム)
- スタンドアロン アプリとしての起動
- 構成可能なレイアウト
ビジネス プロセス フローまたはキャンバス アプリのいずれかを選択する
ダイアログの置き換えを選択する場合は、提供するユーザー エクスペリエンスを考慮することが重要です。 また、ほぼすべてのダイアログはキャンバス アプリを使用してモデル化できる点に留意してください。
個人および Dynamics 365 アプリ コンテキストのグループの間でコラボレーションを必要とする最上位のワークストリーム全体にガイダンスを提供するプロセスをモデル化するダイアログは、ビジネス プロセス フローに置き換えるのが最適です。 たとえば、見積もりのレビューや転送です。
あるいは、規範的なタスク (潜在顧客を予測するためのコール スクリプトなど) をモデル化するダイアログをキャンパス アプリに置き換えたり、キャンパス アプリを使用して、営業案件の更新など、その他のタスク用のユーザー エクスペリエンスを簡略化したりすることもできます。 これらのシナリオでは、スタンドアロンのキャンバス アプリからでも利点が得られることがあることに注目してください。
ビジネス プロセス フロー シナリオを使用したダイアログの置き換え
一連のページ上において、ユーザーに主要な情報を要求し、見積もりを作成した上で、その見積もりを顧客に電子メールで送信する前に見積もりの承認または却下を判断するレビュー担当者に電子メールを送信するダイアログがあるとします。 この種のプロセスはビジネス プロセス フローを使用することで、より効率的にモデル化されます。
ダイアログを置き換えるには、プロセス内の主要なステージを識別することから始めます。 主要なステージとしては、すべての製品の一覧表示および割引の適用が確実に行われるようにするコンテンツの準備ステージ、見積もりを作成し、その形式の正確性を確認する見積もりの生成ステージ、レビューを受け承認を得るために見積もりを送信するプライマリ レビュー ステージ、特定の状況下で最終的に見積もりのレビューを行うセカンダリ レビュー ステージ、顧客に見積もりを送信する見積もりの配信ステージなどがあります。
次に、ユーザーがプロセス内で従う必要のある主要な手順を識別します。 たとえば、コンテンツの準備ステージには、ユーザーが見積もり対象の製品をダブルチェックするための単純な true/false ステップ、価格リストを選択するための必須の検索ステップ、次のステップに進む前に割引価格を入力するための数値ステップが含まれます。 "見積もりの生成" ステージには、"コンテンツの準備" ステージで前に取得したすべての情報と、それに関連する Dynamics 365 行に基づいて見積もりを作成するアクション ステップがあります。 プライマリ レビュー ステージとセカンダリ レビュー ステージには、見積もりのレビューをガイドする true/false ステップに加えて、承認の状態を取得する必須のステップが含まれます。これにより、承認が受信された場合にのみプロセスが次のステージに進むようになります。 このステップでは、認証されたレビュー担当者のみが、見積もりに対して承認を与えることができるように列レベル セキュリティを構成します。 さらに、プライマリ レビュー ステージおよびセカンダリ レビュー ステージに、入力時に電子メール通知がすべてのレビュー担当者に送信されるなどの、ワークフローを追加することもできます。
最後に、ビジネス プロセス フローのステージとステップに加えて、プロセス フローをガイドする条件ロジックを構成します。 この例では、プライマリ レビュー ステージの後に次のような 条件分岐 を追加できます。ステップによって、セカンダリ レベルのレビューの必要性が示された場合、プロセスの次のステージはセカンダリ レビュー ステージとなり、それ以外の場合は、見積もりの配信ステージとなります。
このビジネス プロセスをユーザーが利用できるようにするには、適切なユーザーが確実にビジネス プロセス フローに対する権限を有しそれをアクティブ化できるようにします。
ビジネス プロセス フローを作成する方法の詳細については、チュートリアル: プロセスを標準化するビジネス プロセス フローの作成 を参照してください。
キャンバス アプリ シナリオを使用したダイアログの置き換え
潜在顧客への売り込み電話を通して販売担当者をガイドするコール スクリプトに従うダイアログがあるとします。 このプロセスは、キャンバス アプリを使用することで簡単に取り込むことができます。
データの読み書きの対象となるデータ ソースに接続することから開始します。 この例では、潜在顧客、アカウント、および連絡先の情報については、Dynamics 365 への接続 が使用されます。
必要な画面の数を特定することから始めます。 この例では、5 つの画面を使用することに決めます。
- 画面 1。 一覧から電話をかける潜在顧客を選択します。
- 画面 2。 紹介、会話が可能かどうかの確認、および後日の電話のかけ直しのスケジュール設定を行います。
- 画面 3。 BANT (予算、機関、必要性、およびタイムライン) を決定します。
- 画面 4。 次の手順を取り込んで、フォロー アップ通話をスケジュールします。
- 画面 5。 通話の最後で、時間を割いてくれたことに対して潜在顧客にお礼を言います。
次に、各画面をビルドします。 最初の画面では、電話する必要がある潜在顧客の ギャラリーをビルド します。 2 番目では、ラベルを使用して画面にタイトルを付けてコール スクリプトを指定する一方で、ラジオ ボタンなどのコントロールを使用して人が話すのに適した時間であるかどうかを取り込みます。 適切である場合は、条件ロジックを使用して、次の画面に移動するためのボタンを有効にします。適切でない場合は、同じ画面上で、顧客への電話のかけ直しをスケジュールすることを試みるためのスクリプトを表示します。 同様に、後続の画面間で使用するコール スクリプトを定義します。
最後に、画面間の移動を定義 します。 この例では、画面を順番に移動するだけではなく、潜在顧客が話し合いを持つことに関心がない場合のように、2 番目の画面から最後の画面 (スクリプトの最後で、時間を割いてくれたことに対して潜在顧客にお礼を言う) にユーザーを移動することが必要になる場合があります。
このアプリをユーザーが使用できるようにするには、アプリを公開します。 コール スクリプトを提供し迅速なデータ入力をサポートするスタンドアロン アプリが利用可能なことから、このようなシナリオがどのように変化する可能性があるか検討してください。
このエクスペリエンスを Dynamics 365 Sales に埋め込むとします。 これを行うには、まず、Dynamics 365 Sales のフォーム上で iframe を作成します。 次に、Power Apps メニューから アプリ セクションに移動し、発行したばかりのアプリを選択し、詳細 タブの下にある Web リンクをコピーし、それを iframe の URL として貼り付けます。
このステップをさらに見ていきます。このアプリが潜在顧客のメイン フォーム内、および潜在顧客のコンテキスト内で直接利用できるようになることで、最初の画面でユーザーがアプリから潜在顧客を選択するように求められないようにしたいと仮定します。 関連する情報をアプリに渡すには、フォームの読み込みなどの特定のイベントに対して実行される JavaScript を使用して、潜在顧客やアカウント ID などの情報を含むクエリ文字列を付加するように iframe URL を変更するだけです。 次に、最初の画面 (潜在顧客の選択用) を削除し、代わりに Param 関数 を使用することによりクエリ文字列を介してアプリに渡される値にアクセスするように、アプリを更新します。
ダイアログの置き換えに関するよくあるご質問
キャンバス アプリ上の依存関係は追跡されますか?
- キャンバス アプリでの依存関係は、Dynamics 365 アプリ内の依存関係と同じ方法で追跡されます。
コマンド バー内のボタンからキャンバス アプリをポップアップとして起動することができますか?
- はい。 これを行うには、ターゲット URL をご利用のキャンバス アプリの URL に設定するだけです。その URL は前述の説明に従ってアプリの詳細セクションから取得します。
キャンバス アプリからワークフローを呼び出すことができますか?
- これはサポートされていません。 代わりにクラウド フローを使用することをお勧めします。
ダイアログを自動的にビジネス プロセス フローまたはキャンバス アプリに変換できますか?
- ダイアログをビジネス プロセス フローまたはキャンバス アプリに自動変換する方法はありません。