変数、パス、ループの基本を学ぶ
学習の目的
この単元を完了すると、次のことができるようになります。
- 変数独自の特徴を挙げる。
- スケジュール済みパスのメリットについて説明する。
- Flow Builder のループのしくみについて説明する。
- デバッグの目的を定義する。
さらなる概念
Flow Builder には他にも説明すべき概念があり、ここで取り上げる概念は既出のものよりやや高度です。次の動画では、変数やループといったフローの複雑な概念がわかりやすく説明されています。前述のとおり、単元の末尾のテストはこの動画の内容に基づいて出題されます。質問に答えるのに必要な情報を得るために、必ず動画をご覧ください。
変数とは?
代数の授業で変数について習ったことを覚えていますか? Flow Builder の変数もほぼ同じですが、あれほど退屈ではありません (代数の先生、ごめんなさい)。変数がタコスでもピザでも入れられる弁当箱のようなものであることを説明している次の動画をご覧ください。
トランスクリプトを表示する
[ナレーター] Salesforce フローについて学びたいと思っているなら、変数の概念を理解しておくことが重要です。簡単に言えば、フローで変数が使用されるのは、特定の条件に基づいて値が変化する可能性がある場合です。変数とは情報を入れておく容器です。フローのすべての変数には名前と値があります。フローを進む間に変数の値にアクセスでき、値を変更することもできます。それが変数と呼ばれる所以です。
昼食について考えてみましょう。弁当箱は変数です。名前は「私のランチ」で、値はサンドイッチです。月曜日には弁当箱 (変数) を使ってサンドイッチを持っていきます。火曜日には同じ弁当箱 (変数) を再利用して、ピザを持っていきます。弁当箱と同じように変数は空 (Null) にすることもできます。変数の大まかな考え方がわかったところで、フロー内での変数で何を行うかを見ていきましょう。
たとえば、フロー内に [Contact ID (取引先責任者 ID)] という変数があるとします。[Contact ID (取引先責任者 ID)] 変数の値は取引先の主取引先責任者の ID だとします。フローは取引先オブジェクトのすべての取引先責任者をスキャンして特定の特徴を探し、別の人を主取引先責任者にすべきという結論が出ました。そこでフローは新しい取引先責任者の ID を [Contact ID (取引先責任者 ID)] 変数に割り当てます。ここで重要な点は、この変更が実際にはまだ Salesforce 組織に保存されていないということです。変数はフロー内部の情報用の入れ物です。この変更は、Salesforce 組織に保存するという指示を出すまでは保存されません。
お疲れさまでした。変数を理解するのはなかなか難しいものです。変数はフロー内部で情報を入れておくものであり、変数の値は変更可能で、組織の実際のデータを変更するには追加ステップを実行する必要があるということは覚えておいてください。
変数のデータ型
ここで、弁当箱変数に関するもう 1 つの動画をご覧ください。自動化の変数については、変数のデータ型、変数をまとめて収集する方法に関する制限など、常に学ぶべきことがあります。以下の動画を視聴して、変数に関する知識を培いましょう。
トランスクリプトを表示する
[ナレーター] 本日は弁当箱に関する講義に参加いただきありがとうございます。19 世紀に初めて弁当箱が商品として開発されました。もちろん冗談です! この動画は変数について解説するものです。弁当箱は Flow Builder です。弁当箱がさまざまな料理の入れ物であるのと同様に、変数も一片の情報を保持する入れ物です。
ただし、フローという弁当箱のデータ型が一定であるのに対し、中身である値はフローの過程で変化することがあります。ステンレスボトルは飲み物を入れておく容器ですよね? 同じように、テキスト型の変数はテキストを保持し、数値型の変数は数値を保持します。
Salesforce の項目を作成したことがある場合には、変数のデータ型にテキスト、数値、通貨、日付、日付/時間、選択リストといったさまざまな選択肢があることをご存知かと思います。中には、聞いたことがないものがあるかもしれません。Boolean は、true、false、空白値のいずれかの保存に使用します。チェックボックス項目と似ていますが、空白が false ではない点が異なります。空白は null または無であることを意味します。変数のもう 1 つのデータ型は Apex 定義です。このデータ型は、通常 Apex コードまたは Web サービスへのコールから返される複雑なデータオブジェクトを操作します。変数のデータ型を選択すると、複数の値を許可するオプションが示されます。このオプションを選択した場合は、変数がコレクション変数になります。
弁当箱が大きければ、サンドイッチがたくさん入るようになります。コレクション変数には、同じデータ型の変数のみのコレクションが保持されます。たとえば、数値変数は他の数値とのみ一緒にすることができます。サンドイッチが他のサンドイッチとのみ一緒に詰められるのと同様に、取引先責任者レコードは他の取引先責任者レコードからなるコレクションにのみ追加できます。コレクションにオブジェクトを混在させることはできません。
要点をまとめると、変数のデータ型はレコードの項目のデータ型とよく似ています。どのデータ型の変数も、そのデータ型の変数のコレクションに含めることができます。弁当箱がタコスの入れ物の場合は、昼食がいつもタコスになります。フローを作成したら、いつものごとく、まず Sandbox 組織でテストします。
スケジュール済みパス
毎朝、起きてから 10 分後にコーヒーを飲む人がいます。Flow Builder も同じように機能させることができます。もちろん、Flow Builder がコーヒーを飲むわけではなく、時間を定めたスケジュールに従うようにするということです。カフェインでパフォーマンスを高めるのと同様に、スケジュール済みパスを使用して組織のパフォーマンスを高める方法について説明する次の動画をご覧ください。
トランスクリプトを表示する
[ナレーター] Salesforce ではトレイルという言葉が頻繁に使用されますが、次の数分間はパスに着目します。ここでは特に「スケジュール済みパス」を取り上げます。フローアクションをすぐ実行するのではなく、時間を置いて実行するようスケジュールする場合は、レコードトリガーフローでスケジュール済みパスを使用します。
例を見てみましょう。リードレコードを作成するとフローが起動します。このレコードの作成によってフローがトリガーされます。スケジュール済みパスを使用すると、リードの作成日から 3 日後にそのリードにメールを送信するなど、数分後、数時間後、数日後に動作を実行することができます。作成日に基づいてスケジュールするだけではありません。スケジュール済みパスは、オブジェクトの任意の日付または日付/時刻項目に基づいて作成でき、その当日だけでなく、その日より前や後に実行することもできます。
たとえば、取引先責任者の作成時にメンバーシップの有効期限を設定するレコードトリガーフローがあるとします。この同じフローに、メンバーシップの有効期限が切れる 5 日前にリマインダーをメール送信するようスケジュールすることができます。ワークフロールールやプロセスビルダーを使い慣れている場合、スケジュール済みパスはプロセスビルダーの時間トリガーのワークフロールールや時間ベースのアクションに匹敵します。
次に、スケジュール済みパスのように見えるが、実は異なる 2 つの概念について説明します。レコードトリガーフローの開始要素には、外部システムにアクセスするための「非同期に実行」パスを含めるオプションがあります。このオプションは、高度なフローが必要になるまで無視して構いません。また、スケジュール済みトリガーフローと混同しないようにします。この種のフローは、1 回、毎日、毎週実行するようスケジュールすることができます。たとえば、スケジュール済みトリガーフローが月に 1 回実行されるように設定して、その期間に変更されていないリードを「コールド」とマークすることができます。
要点をまとめると、レコードトリガーフローでスケジュール済みパスを使用して、フローが最初にトリガーされた後の任意の時点で実行されるステップを自動化します。スケジュール済みパスに設定するレコードを作成または更新する必要があります。スケジュール済みパスは、オブジェクトの任意の日付または日付/時刻項目に基づいて作成できます。さらに、フローを作成したら、いつものごとく、まず Sandbox 組織でテストします。
フローループ
かつて週に 5 日オフィスで仕事をしていた頃、冷蔵庫が一杯になって誰かが片付けなければならなかったことを覚えていますか? 次の動画では、ループでレコードのコレクションを処理することを、冷蔵庫の怪しげな容器をまとめて処理することに例えて説明します。
トランスクリプトを表示する
[ナレーター] フローループのトピックは複雑ですが、心配はいりません。Flow Builder のループでは、レコードリストのようなコレクションを 1 つずつ調べて、各レコードに基づいてアクションを実行します。
フローループは非常に強力で、データベース内の何百ものレコードを同時に作成、更新、削除できます。フローのループは複雑そうに聞こえるかもしれませんが、実際の用途を見れば理解しやすくなります。
そこで、1 週間の終わりに冷蔵庫を整理する順番が回ってきた Oscar に注目しましょう。Oscar はフローループのすべてのステップを実行します。ただし、対象は Salesforce レコードではなくて残った食品です。フロー要素 (フローで実行できるアクション) が冷蔵庫の整理とどのように関係しているかを説明します。
最初に必要なフロー要素は [レコードを取得] です。条件を使用してどのレコードを取得するかを決定します。この場合、Oscar はラベルが付いていないすべての残り物を取り出します。次にループ要素を追加します。フローはループを実行するごとに 1 つずつレコードを評価します。この例では Oscar は一度に 1 つずつ食品を調べます。次に [決定] 要素を追加します。この残り物を置いておくか捨てるかを決めます。[決定] 要素はフローループに必須ではありませんが、この例では妥当です。レコードを更新する場合は [割り当て] 要素を追加して、どのような変更を行うか (日付項目の更新など) を指定します。この例では、Oscar はこの食品を置いておくことにして、今日の日付のラベルを付けます。2 つ目の [割り当て] 要素を追加します。これはコンテナのようなものです。コンテナにレコードを入れて、保持するレコードをすべて一時的に保管します。これは Oscar がすべての残り物を箱に入れておくのと同じです。これで最初のレコードのループが完了し、次のレコードで最初から繰り返します。
Oscar は次の食品を調べます。[決定] 要素の後に、フローが進む代替パスを作成する必要があります。Oscar は置いておきたくない残り物をどうするでしょうか? [割り当て] 要素をもう 1 つ追加しましょう。今回は削除するレコードをすべて保管するコンテナを使用します。Oscar の要らなくなった残り物のコンテナは室内コンポストです。次の項目でループを繰り返します。すべてのレコードがループを通過するまで続けます。ループの後にデータベースを実際に変更する必要があります。箱と生ごみ処理容器は一時的な入れ物でしかありません。
フローに [レコードを更新] 要素を追加して、保持するレコードに対する変更を確定しましょう。保持する項目には日付値を追加しましたね。Oscar は置いておく箱の中身をデータベース冷蔵庫に戻します。不要なレコードを削除する [レコードを削除] 要素を追加しましょう。Oscar の場合は屋外コンポストです。Oscar がすべての食品を一度に持って行ったことに気付きましたか? 食品を 1 つずつ屋外コンポストに持って行ったのでは、大きな時間の無駄になります。フローでも同じです。データ要素 (この場合は更新要素と削除要素) は常にループの外側に配置します。ループ内の [割り当て] 要素にレコードを入れることは、ループの後に更新する意図を示すだけです。後で対処するために取っておくようなものです。生ごみを 1 つの容器に入れて屋外に持っていくように、すべての変更を同時に行う方がはるかに効率的です。
お疲れ様でした。ここでは、フローループについて学習し、Oscar が冷蔵庫を整理するのも手伝いました。また手伝いが必要になったら Oscar から声がかかるかもしれません。
デバッグ
Flow Builder に組み込まれている機能の中でも特に有用なデバッグについて説明します。デバッグで自動化の問題を特定して隔離し、修正することができます。さらに、Sandbox 組織で操作したデータをロールバックする方法についても学習します。
トランスクリプトを表示する
[ナレーター] Flow Builder の自動化に問題があるため、トラブルシューティングが必要になりました。都合の良いことに、Flow Builder には組み込みのデバッグツールが付属しています。デバッグを実行して問題を特定し、その根源を隔離すれば、問題を修正したり、問題を回避する方法を判断したりすることができます。どの自動化も完璧に設定しているため、破損するようなことはなく、デバッグツールは必要ないと思っているかもしれません。けれども、Flow Builder の経験豊富なエキスパートが手がけたとしても、完璧な自動化など存在しません。
Flow Builder のデバッグツールは、フローを構築するすべてのユーザーに必須のアイテムです。Flow Builder のデバッグツールによる処理が終了すると、結果に次の詳細が示されます。自動化が成功したか? 失敗したか? どこで失敗したか? 結果の詳細には、インタビューがどのように開始されたか (フローが何によってトリガーされたか)、どのレコードでインタラクションが発生したか、そのアクションが成功したかどうかが示されます。
Flow Builder のデバッグツールはトラブルシューティングだけでなく、初期テストでも役立ちます。このツールは、自動化を本番に導入する前にテストする機能、デバッグ時に特定の入力変数を指定する機能、自動化のさまざまなパスをデバッグする機能、レコードが作成、更新、削除されたものとしてフローをトリガーする機能、自動化を別のユーザーとして実行する機能、デバッグとそのパスの詳細を生成する機能なども備えています。新しい自動化を作成したり、既存の自動化の問題を修正したりする場合に Flow Builder のデバッグツールを使用します。
Flow Builder でデバッグを実行するときは、組織の実際のデータとやり取りする点に留意します。そのため、フローのデバッグは必ず Sandbox 組織で実行することが極めて重要です。Sandbox 組織でテストする際に特に有用な機能が、ロールバックモードオプションです。フローのデバッグ時にロールバックモードを使用すると、自動化の終了後に、Flow Builder によって自動化で実行された変更がロールバックされます。
要点をまとめると、Flow Builder で新規作成または更新された自動化はすべて、デバッグでテストする必要があります。デバッグには、入力変数の指定、フロー要素の結果の表示、別のユーザーとしての自動化の実行など、多様な機能があります。ベストプラクティスは、Sandbox 組織でデバッグを行い、ロールバックモードを使用することです。
学習した内容を確認する
動画を見終えたら、テストを受けて Flow Builder について学んだ内容を確認し、バッジを獲得してください。
リソース