フロー動作の確認
学習の目的
この単元を完了すると、次のことができるようになります。
- フローのテストケースを特定する。
- フローインタビューとは何かを説明する。
- Flow Builder でフローをテストする。
システム管理者または開発者であれば、いかなるカスタマイズであっても、ユーザにロールアウトする前にテストする必要があることはご存じだと思います。そしてそれはフローも同じです。テストにより、フローの挙動を微調整し、バックグラウンドを特定して修復することで、ユーザエクスペリエンスの成功を保証します。そしてもちろん、後でユーザからの苦情メールに対応しなくても済みますので、あなた自身にもメリットはあります。
始める前に
このモジュールを完了するには、先に「Flow Builder」モジュールを完了しておく必要があります。ここでの作業は、同モジュールでの概念や作業に基づいて行います。
テストプランの作成
テストを開始する前に、テストケースのリストを考えて、どのような結果を期待するかを明確にしておきます。次のような要因を検討してください。
- どのようなときにアクションが実行されることを期待するか
- どのようなときにアクションが実行されないことを期待するか
- 数式がどのように解かれるか
作成してきた「新規取引先責任者」フローでは、4 つの主なテストケースがあります。
| トグル設定 | 一致するレコード | 期待される結果 |
|---|---|---|
| オフ | 存在しない |
|
| オフ | 存在する |
|
| オン | 存在しない |
|
| オン | 存在する |
|
テストしたい内容が決まりましたので、実際にフローをテストしてみましょう。
Flow Builder のテストオプション
フローの動作は、Flow Builder 内でテストできます。ボタンバーには、フローを実行するための [実行] と [デバッグ] の 2 つのボタンがあります。
- [実行] は、開いているフローの最後に保存されたバージョンを実行します。
- [デバッグ] は、[実行] と同じ動作を実行しますが、追加の機能があります。フローの実行中に、フローの入力変数に値を入力して、デバッグの詳細を表示することができます。こうすることで、フローがどのようにデータを処理するかを検証できます。
ヒント
Classic ランタイムでのフロー動作のテストが必要なければ、常に [デバッグ] を使用してフローをテストします。[デバッグ] は常に Lightning ランタイムを使用しますが、[実行] は組織の [プロセスの自動化] の [Lightning ランタイムを有効化] 設定に従って動作します。
[デバッグ] をクリックし、詳細表示を選ぶと、フローの最初の画面 (1) とデバッグ詳細 (2) が表示されます。フローを進むと、右側のパネルに新しい詳細が追加されます。
フローインタビューの紹介
フローが実行されるたびに、フローインタビューが開始されます。フローインタビューは、フローのインスタンスです。
ゲームブックで遊んだことはありませんか? フローはこの本と似ていて、選択が読者に委ねられ、それぞれの選択に対して指示が与えられます。フローインタビューとは、この本のストーリーテラーに相当します。読み進めるうちに、選択肢が出てきて、読者の選択肢に応じた手順に進みます。本を読む度に、あるいは読む人ごとに異なる選択肢を選ぶことで、ストーリーも変わってきます。
インタビューも同じです。インタビューで画面上の入力変数や入力コンポーネントで異なるデータを提供すると、フローの異なるパスが選択され、異なるアクションが実行されます。
では、テストプランの 4 つのケースで、実際にインタビューを見てみましょう。
Flow Builder でのフローのテスト
- Flow Builder で [デバッグ] をクリックします。2 番目のチェックボックスが選択されていることを確認してください。そうでないと、デバッグの詳細が表示されません。このフローにはサブフロー要素や入力変数がありませんので、これらの設定は気にしないでください。
- [実行] をクリックします。
-
最初のテストケースを検証します。
- 名と姓を入力して、取引先を選択します。
- トグルは未選択のままにします。
- [次へ] をクリックします。
-
デバッグの詳細を確認します。
-
最初のカードには、フローインタビューを開始したユーザが表示されています。ここではあなたが開始していますので、自分の名前とユーザ ID が表示されます。
-
2 番目のカードには、最初の画面からの入力をフローインタビューで使用するためにどのように格納したかについての要約が表示されます。たとえば、ここではトグルを選択しなかったため、{update_toggle} 値は false に設定されています。
-
3 番目のカードには、「既存する場合は更新するか?」の意思決定がどのように評価されたかの要約が表示されます。{!update_toggle.value} は false であるため、インタビューはデフォルトパスを進みます。キャンバスでは、「いいえ」というラベルの付いたコネクタに相当し、「レコード作成」要素に直接進みます。
-
4 番目のカードは「取引先責任者の作成」要素の要約です。インタビューでは、{!contact} 変数の値を使用して取引先責任者レコードを作成しています。
-
5 番目のカードは、「Chatter に投稿」アクションの要約です。投稿されたメッセージは「この取引先責任者が作成されました」です。
-
-
このテストケースで予想される結果を検証します。
-
確認画面では「作成された」と指定されています。
- リンクは新しい取引先責任者に繋がります。取引先責任者名は、入力した名前となり、選択した取引先の子となります。
- 取引先責任者の [Chatter] タブで、この取引先責任者が「作成された」と指定されています。
-
- 他の 3 つのテストケースでも同じ手順を繰り返します。一致するレコードを含むケースでは、最初のテストケースと同じ名前、名字、そして取引先責任者を使用してください。
いずれかのテストケースで予想外の結果となった場合は、[デバッグの詳細] で前に戻って原因を突き止めてください。すべてのテストケースが正常に完了したら、フローをユーザに渡すことができます。
リソース
- Salesforce ヘルプ: Flow Builder でのフローのデバッグ
- Salesforce ヘルプ: Troubleshooting Considerations for Flows (フローのトラブルシューティングに関する考慮事項)