プロのようにフローを実装する

学習の目的

この単元を完了すると、次のことができるようになります。

• フローの作成が開発の一種であることを理解する。
  
• フローを作成する際のリスク軽減のベストプラクティスに従う。
  
• Sandbox 環境でフローを作成する。
  
• フローの開発とリリースを計画する。
  

このバッジは、Flow Builder のスキルを習得するための過程の一部です。Flow Builder の強力なプロセス自動化スキルを身に付けてエキスパートになるには、「Flow Builder を使用したフローの作成」トレイルに従って学習してください。このバッジに取り組む前に、そちらのトレイルを完了することをお勧めします。

強力な機能には、責任が伴う

「Flow Builder を使用したフローの作成」トレイルのほかのすべてのバッジを完了している場合、すでに数多くのフローを作成しており、Flow Builder を使って独自のフローを作成できるだけの十分な経験があるはずです。これまでの経験から、Flow Builder が非常に強力なツールであることは理解しています。フローでは、次のようなことができます。

• 組織のユーザーから入力を受け取る。
  
• Salesforce レコードを作成、更新、削除する。
  
• 誰にでもメールを送信する。
  
• 外部システムのデータと連携する。
  

これらの機能 (およびそのほかの機能) は非常に有用ですが、同時に一定のリスクも伴います。ユーザーが想定外の操作を行うこともあれば、データが失われたり混在したり、顧客に誤ってメールが送信されたりすることもあります。これが自動化の本質です。自動化は指示したとおりに正確に動作しますが、必ずしも意図したとおりに動作するとは限りません。

フローの作成者として、フローを作成して有効化するだけでは不十分です。リスクを最小限に抑え、フローが意図したとおりに動作することを確実にする責任があります。そのためには、正しい考え方が必要です。

私たちは皆人間であり、ときにはミスをします。フロー作成者が最初から完璧にできないのは、ごく普通のことです。経験豊富なフロー作成者であっても、最初からフローを完全に仕上げられることはほとんどありません。さらに、フローは日々変化し、そして成長する「生きた組織」で実行され、その組織と関わるすべての人に影響を与えます。

ケースが作成されるたびにフローが実行されるとして、ユーザーがフローの想定どおりに値を入力しなかったらどうなるでしょうか。新しいケースのレコードタイプを追加したらどうなるでしょうか。新しい選択リスト値を追加したらどうなるでしょうか。新しいユーザープロファイルを追加したらどうなるでしょうか。想定される理想的なシナリオだけでなく、不完全なシナリオでも動作するように、フローをどのように設計すればよいでしょうか。

リスクの軽減

リスクを軽減するためのベストプラクティスを実践することで、エラーや不完全なシナリオを検出することができます。

• フローの結果を定義する計画を作成する。
  
• その計画を使用して、フローの作成中にテストを行う。
  
• 安全で分離された環境 (Sandbox) でフローを作成する。
  
• フローが Salesforce の制限を超えてしまう原因となるようなことを避ける。
  
• フローで、問題を想定して適切に処理する機能を追加する。
  
• フローをリリースする前に、ユーザー種別ごとにデバッグ実行を行う。
  

これらすべてのベストプラクティスを採用すれば、フローに潜んでいるほぼすべての問題を発見できます。ただし、知っておいてほしいことがあります。これらは開発者にとっての一般的なベストプラクティスです。

開発者なら、これらについてはすでに馴染みがあるものかもしれません。システム管理者の方も、心配は要りません。これらのスキルはここで学べますし、コードを書く必要もありません。Flow Builder の宣言型ツールセットの中だけで、これらすべてのベストプラクティスを実践できます。

宣言型ツールを使用しているからといって、開発者として劣っているわけではありません。自動化の作成は、ユーザーを追加したりアプリケーションを設定したりするよりも複雑です。最初から最後までソリューションを開発する行為そのものだからです。テスト、エラー処理、デバッグ、システム制限への配慮は、いずれも通常のシステム管理者の業務を超えています。

このバッジでは、これらのリスク軽減ベストプラクティスを 1 つずつ学び、真のフロー開発者になることを目指します。★

常に Sandbox で最初に作成する

これまでも多くのバッジで触れてきましたが、繰り返し強調します。フローは必ず最初に Sandbox で作成してください。この考え方は、既存のフローを変更する場合にも当てはまります。

Sandbox でフローを作成し変更する場合は、ユーザーに提供する前に必ずテストとデバッグを行う必要があります。本番環境では、小さな変更であってもリスクを伴います。たとえば、単なるタイプミスを修正するために、ほんの少しだけ変更したいとします。非常に小さな変更だからと判断し、Sandbox を使わずに本番環境で直接修正することにしました。それは今のところは問題ありません。

翌月、Sandbox で新しいバージョンのフローを作成し、テストしてから本番環境にリリースしました。

Sandbox 側では修正が行われていなかったため、リリース時に本番環境で修正済みだったタイプミスが上書きされてしまったのです。その結果、レコードやレポートなど、データが表示されるあらゆる場所で、誤った「Activ」という値が再び表示されてしまいます。こういう恥ずかしい事態は避けなければなりません。

では、Sandbox での作業が完了したら、どのようにして本番環境に反映すればよいのでしょうか。その方法については、「フローの実装 II」バッジの最後で解説します。まずは、フローを作成するときと同様に、本番環境にリリースする前に実施すべきベストプラクティスを 1 つずつ確認していきましょう。

何よりもまず計画

これはほかのバッジでも触れましたが、リスク軽減のための非常に重要なベストプラクティスです。フローの作成を始める前に、必ず計画を立ててください。

フローの計画は、フローチャート、表、図など、どのような形式でも構いません。重要なのは、意図したフローについての詳細な情報が含まれていることです。

ここでは、フローの要素については何も触れていないことに注目してください。それらの詳細については、今は気にしなくて大丈夫です。「誰が」「いつ」「何を」「どこで」「なぜ」を重視してください。「どのように」は、計画に沿ってフローを作成していく中で自然と形になります。

もちろん、どんな計画でも、実践すれば必ず見直しが必要になります。フローを作成している途中で、計画の調整が必要になることや、計画を文書化し終えた後に新たな点を思い出すことは自然なことです。それで問題ありません。流れに身を任せましょう。計画は必要に応じていくらでも見直せます。たとえドラフトのまま終わったとしても構いませんので、まずは計画を立てて、無計画のまま作成してしまうリスクを減らしましょう。

フローを計画する

このバッジでは、いくつかのフロー作成シナリオを通して、作成および実装に関するベストプラクティスに焦点を当てます。サポート部門から、フローを作成してほしいと依頼されたと想像してください。依頼内容は次のとおりです。

ケースが一度でもエスカレーションされた場合、状況が変更された後も、そのエスカレーションがメトリクスに反映されるようにしたい。また、以前にエスカレーションされたケースがクローズされたときは、取引先所有者にメールを送信したい。

ユーザーは、自分が本当に望んでいることを実現する最善の方法とは限らないにもかかわらず、特定の解決策を指定して依頼してくることがよくあります。たとえば、この依頼をしたユーザーは「ケースは常にエスカレーションされたままであるべきだ」と言ったかもしれません。ですが、ケースの状況を永遠にエスカレーションのままにしておくことはできません。サポートチームはいずれケースをクローズする必要があるからです。依頼者が想定している解決策をそのまま受け入れるのではなく、その依頼の理由を明らかにするための質問を行いましょう。

この依頼を、計画として分解してみましょう。

計画はできましたが、まだフローの作成は始めないでください。次の単元では、フローの作成を始める前に理解しておくべきリスク軽減戦略となるテスト主導型開発について説明します。