本日、面白い＆役に立つ AppExchangeをご紹介するつもりだったのですが、どうにもうまくいかず、以前「フローの命名ルールを決めて迷わず実装＆仲間にもわかりやすくしよう」で「そのうち紹介します」と書いていた、フローのベストプラクティスの記事を翻訳してご紹介させていただきます。いつものようにDeepLさんのお力を借りながらお届けします。

元の記事はこちらです。

◇ salesforce admin ＞Article ＞The Ultimate Guide to Flow Best Practices and Standards

-------------------------------------------
とてつもなく長い記事です。
お忙しい方は、最後の「10. チェックリストで確認する」から確認されることをおすすめします。最下部までスクロールすると読めます。

また、開発のバックグランドがない方は（私もありませんので大丈夫です（？））、DeveloperNameやシステムコンテキストなど、
見慣れない単語があるかもしれませんが、開発者ガイドやヘルプに説明が載っていることもありますので、あきらめずに調べてみてください。

DeveloperNameについては、レコードタイプのページでの説明が一番詳しかったです。
◇開発者ガイド＞Salesforce プラットフォームのオブジェクトリファレンス＞リファレンス
＞標準オブジェクト＞RecordType

システムコンテキスト、ユーザコンテキストについてはこのあたりがよろしいかと思います。
◇ SALESFORCE ヘルプ＞ドキュメント＞ビジネスプロセスの自動化＞フローが実行されるコンテキスト
◇SALESFORCE FLOWSOME ＞Flow: How To Launch Your Flows And In What Context

システムコンテキストについては当サイトの記事「フロー画面でのレコードタイプによる選択リストの絞り込みを試してみた」でも触れています。
-------------------------------------------

フローのベストプラクティスとスタンダードへの究極のガイド

避けようがないんです。Salesforce フローは、未来の自動化ツールです。フローは単なる「管理ツール」ではなく、lightning web コンポーネント（LWC）やApexを使用できるようにし、アドミンがそのすべてを一箇所でオーケストレーションすることで、開発者とアドミンを結びつける宣言的開発の聖杯なのです。アドミンと開発者のユニークなコラボレーションが見られるようになり、双方が開発と管理について少しずつ学んでいます。

このブログでは、組織に合わせてフローを拡張するためのベストプラクティス、「gotchas」、デザインのヒントについて説明します。

1. フローを文書化する

フローを文書化することで、次の人、あるいは忘れっぽい未来の自分が、フロー全体の目的を理解することができます。フローデザイナーは、何もないところからソリューションを生み出すわけではありません。難しい問題を解決するにはビジネスケースが必要であり、自動化を長期的に維持するためには、こうしたパンくずを持つことが重要です。

フローの目的を説明する

説明欄を埋めてください！あなたのフローは、どのような問題を解決するものですか？フローが何をするのか、フローが触れるオブジェクト、どこから呼び出されるのか（画面フローならページレイアウト、自動起動フローならプロセスビルダーのプロセスなど）を必ず書いてください。さらに、このフローがビジネスプロセスのどこにフックしているのか、どのグループと関わっているのかにも言及できれば、次の担当者が質問しやすいので、なおよいでしょう。ストーリーにリンクさせるためのJIRAまたはストーリーIDをお持ちですか？それを説明文に貼り付けてください。

要素や変数に一貫した命名ができるようにする。

フローで変数や要素を作成する際は、命名規則に従うこと。変数の説明には、何を捕捉しているのかを含めます。フローを継承する将来の「あなた」や他の誰かにとって、前もって少し手間をかけておくことは、大きな意味を持ちます。この方法には正解も不正解もなく、フロー内で一貫性を保つだけです。一般的な命名規則として、キャメルケースというものがあります。フローの命名に関する提案については、Salesforce Exchange Discord Server の Wiki を参照してください。

すべてのステップを文書化する

各ステップには必ず短い文章を書き、各フロー要素が何であるか、その目的を説明します。こうすることで、必要に応じてチームのどのメンバーも作業を引き継ぐことができるようになります。これは、フローの制限に対処するための回避策を使用したり、より高度な機能を実行したり、Apex invocableを呼び出したりする場合に特に重要です。

2. 呼び出し可能なアクションの力を利用する

呼び出し可能なアクションで非効率なフローをクリーンアップ - 素敵でクリーンで見栄えのするフローを作るために、いくつかの再利用可能なコードを使うことを怖がらないでください。昔は、フローからApexを呼び出すことができましたが、そのオブジェクトやデータ型に対してApexを使用する必要がほとんどでした。フローは汎用的な入力と出力をサポートするようになったので、そのような時代は終わりました。呼び出し可能なアクションで使用される汎用的なコードは、フローの能力を全面的に向上させます。1つのアクションを好きなだけ多くのフローに使用できます。

画像お借りしました

フローは素晴らしいものですが、特にクエリや大量のデータ、コレクションを扱う場面では限界があります。ループにループを重ね、さらにネストしたループを作成したり、要素の実行制限にぶつかったりすることはありませんか？そんな時は、再利用可能なApexがあなたのために力仕事をしてくれるでしょう。

Automation Component Libraryと呼ばれるフローで起動されるアクションのための素晴らしいリポジトリがあります。

3. サブフローを活用し、よりクリーンで再利用可能なスケーラブルなフロー管理方法を実現

"サブフローを使うべきか？"と自問自答し始めるこのフローの例を見てみましょう。

画像お借りしました

ここでは、サブフローを検討すべき典型的なユースケースをいくつか紹介します。

・再利用：フロー内で同じことを何度も行ったり、別のフローで行ったのと同じことを行う場合、サブフローを呼び出して代わりに行ってもらいます。開発の世界では、これを「ヘルパー」クラスと呼んでいます。
・複雑なプロセス/サブプロセス：複数のプロセスや分岐ロジックを含むフローでは、他のセカンダリフローを起動するメインフローを使用します。例えば、以下のような感じです。
・取引先責任者データの管理 - メイン画面のフローで、さまざまな切断されたプロセスを起動する。
　・取引先責任者と企業の関連付け
　・取引先責任者データの確認
　・取引先責任者のアソシエーション(関連、つながり)を管理する
・組織的な混乱：もしあなたのフローが上図のようなものであれば、おそらくサブフロー（または複数）が必要で、すべてがどのようにつながっているかを理解し、大きなプロセスを理解するために必要です。
・権限の処理：例えば、ユーザーコンテキストで画面フローを実行しているが、ユーザがアクセスできないシステムオブジェクトを取得する必要があるとします。サブフローを使いましょう。上位の権限を持つサブフローを使用することで、フローを継続するために必要な権限を一時的にユーザに付与することができます。

サブフローのメリット

・10カ所ではなく、1カ所で変更できます。
・クリーンで簡潔な、より整理されたフローを利用することができます。
・エラーメールの送信や、フロー間で同じエラー画面を表示する（$Flow.FaultMessage変数を渡す場合）など、組織全体の動作を1つの場所で管理できます。

サブフローでの注意点

・サブフローを変更する必要がある場合、グループ間でより多くのコラボレーションとテストが必要です。
・サブフローではデバッグが困難な場合があります。LightningコンポーネントやApexアクションを使い始めると、サブフローでエラーが発生した場合、必ずしも詳細なエラーが表示されるわけではありません。
・サブフローを作りすぎると、UXのオーバーヘッド（負荷）が発生することがあります。

4. ハードコードされたロジックでフローを過負荷にしない

ロジックの抽象化

フロー内のすべてのロジックをハードコーディングすることは、開発プロセスを遅くし、チームの俊敏性を低下させる大きな要因です。可能であれば、Apex、入力規則などの自動化ツールや他のフローも利用できるように、ロジックを1つの場所に保存する必要があります。次のような場合、フローでカスタムメタデータ、カスタム設定、カスタムラベルを使用することを検討する必要があります。

・複数の場所で参照されているアプリケーションまたは組織のデータを統合する。
・マッピングを管理する（たとえば、州と税率のマッピングや、レコードタイプとキューのマッピングなど）。
・変更される可能性のある情報、または頻繁に変更される情報を管理する。
・タスクの説明、Chatter の説明、通知の内容など、頻繁に使用するテキストを保存する。
・環境変数（Salesforceの各環境に固有のURLや値）を保存する。
「X日」のような単純な値やレコード所有者のID、将来的に変更される可能性のある値を保存したい場合は、カスタムラベルなどを使用することができます。

カスタムメタデータを利用したフローがいかにクリーンであるかをご理解いただくために、レコードタイプとキューを対応させた保存後のケースフローのビフォーアフターをご覧ください。このソリューションでは、キュー開発者名、レコードタイプ開発者名、部門項目を保存するカスタムメタデータレコードを利用し、ケースを動的に更新しています。

Before カスタムメタデータドリブンロジック

After カスタムメタデータドリブンロジック

また、Salesforce Admin Blogに掲載されている Jennifer Leeのハードコーディングの回避に関する記事を読むことを強くお勧めします。

データドリブンな画面フロー

もし、あなたのチームが常にロジックやコンテンツが変化する20～30（またはそれ以上）の画面を構築しているとしたら、レコードデータに基づく動的な画面設計パターンが必要かもしれません。

Salesforceの製品担当副社長であるAlex Edelsteinが書いたUnofficialSFの、カスタムオブジェクトレコード（DiagnosticNode/DiagnosticOutcome）と標準フロー機能のみを使用して500画面相当のフローを構築する方法についての素晴らしい記事を確認して下さい。

その他、Flowとビジネスロジックに関する参考リンクです。
・Trailhead: Use Custom Metadata Types in Flows
・Salesforce Admins Site: Advanced Automation with Flows and Custom Metadata Types Webinar Recap
・外部サイト: UnofficialSF: Dreamforce Slides – Advanced Flow for Admins

5. よくある「ビルダー」の失敗を回避する

自分のロジックに隙がないか確認しない

フローは基本的に宣言的なコーディングであり、ガードレールが外されていることを意味します。フローを構築する際には、あらゆるシナリオを想定する必要があります。つまり、探しているものが存在しないかもしれないというケースを想定して計画することです。

ルックアップ/レコードを取得要素の後には必ず決定要素を置き、フローの後半で結果を使用する予定がある場合は、結果がないことをチェックします。ルックアップの直後に、レコードを取得要素で作成した変数に対して「Is null EQUALS False」の決定チェックを追加します。もしあなたがコーダーなら、これが「null」チェックだと想像してください。

なぜこのようなことをしたいのでしょうか。あなたのフロー全体が、「探しているレコードが実際に組織内に存在する」という1つの仮定に基づいていると想像してください。もし、フローの初期段階でそのレコードが見つからなかったら、フローはあらゆる種類の操作を試みることになり、エラーや悪いデータ、ユーザ体験の低下など、意図しない結果に終わるかもしれません。

空のコレクション：起動可能なアクションや画面コンポーネントの中には、「null」とはみなされない「空の」コレクションを出力するものがあります。この典型的な例は、すぐに使える「ファイルのアップロード」コンポーネントで、何もアップロードされないと空のテキストコレクションを返します。このような場合、最も簡単な方法は、割り当て要素を使用してコレクションを数値に割り当て、数値の値から判断を行うことです。

IDのハードコーディング

フローでは、レコードタイプ、キュー、公開グループなどの開発者名をUIの特定の部分で参照することはまだできませんが、だからといって、IDをハードコーディングする必要はありません。

レコードトリガ型のフローを構築していますか？入力条件に数式を使用することで、トリガ条件でレコードタイプの DeveloperNameを参照することができます。

DeveloperNameを直接参照できない場合は、レコード取得要素、カスタムラベル、カスタムメタデータの結果を使用します。レコードタイプIDやその他のユニークな識別子が環境間で異なる可能性があるため、環境を通してデプロイする際に頭を悩ませることになります。

例として、RecordTypeオブジェクトにレコード取得のルックアップステップを作成します。そして、条件に DeveloperNameと Object項目を指定し、見つかったレコードID（レコードタイプID）を後でフローで使用するために保存します。

キューや公開グループを参照する必要がありますか？IDをハードコーディングする代わりに、Groupオブジェクトのキューの DeveloperNameを使用してレコード取得を実行します。

Group、RecordType、ContentDocumentLink などの設定オブジェクトについて、Salesforce が提供する豊富なドキュメントを使いこなすことを学びます。Salesforceのデータモデルを理解することで、Adminとしてもフロー設計者としても無限に力を発揮できるようになります。

ループするときに不注意になる

ループ処理には、要素の制限、SOQLの制限、複雑な計算式の使用という3つの主要な懸念事項が存在します。

[2023年2月に更新されたガイダンス]。

注意：要素の反復制限は Spring '23リリースで削除されましたが、API Versions 57以上でフローを実行する必要があります。要素の制限を削除されても、CPUタイムアウトや SOQLの制限など、一般的なガバナ制限に注意する必要があります。

1. 要素の実行の制限に注意 - フローが要素にヒットするたびに、これは要素の実行としてカウントされます。Spring’21現在、フローインタビュー1回につき2,000件の要素の実行が許可されています。1,500人以上の取引先責任者をループしているシナリオを考えてみましょう。

ループ内には、ループ要素（1）、決定要素（2）、ループしたレコードに変数を設定する割り当てステップ（3）、そのレコードをコレクションに追加してフローの後半で更新、作成、削除するステップ（4）があります。ループ内のこれら4つの要素は、それぞれ実行制限にカウントされます。つまり、1,500レコードを超えるループでは、実行要素が6,000個となり、反復限界をはるかに超えてしまいます。

この限界に近づくと、トランザクションを強制的に停止させるか、呼び出し可能なアクションを使用してフローをより効率的にする工夫が必要になる可能性があります。トランザクションは、要素が一時停止要素がヒットしたとき、または画面フローでは画面/ローカルアクションが表示されたときに終了することに留意してください。

2. 2.データ操作言語（DML）要素をループ（レコードの取得、更新、削除、作成）の中に入れるのは、スコープがガバナ制限を発動しないことが100%確実な場合のみにしてください。通常、これは画面フローでレコードの小さなサブセットをループしている場合にのみ当てはまります。コレクションに対して複雑なロジックを実行する必要がある場合は、代わりにApexの呼び出しを使用します。

Winter’23には、新しい「次に含まれる」および「次に含まれない」演算子を導入し、ガバナ制限につながるループ内のクエリを避けて、よりパフォーマンスと拡張性の高いフローを構築できるようにしました。

3. 複雑な数式変数に注意 - Record-Triggered Automation Decision Guideによると、「フローの数式エンジンは、非常に複雑な数式を解決する際に、散発的にパフォーマンス低下を起こすことがある。この問題は、現在、実行時に数式が連続的にコンパイルおよび解決されるため、バッチの使用ケースで悪化します。現在、バッチ処理に適した計算式のコンパイル方法を積極的に検討していますが、計算式の解決は常に連続して行われます。数式解決性能の低下の根本的な原因はまだ特定できていません。」

障害パスを作らない

フローを構築する前に、エラーが発生した場合に何が起こるべきかを考えてください。誰に通知すべきなのか？ログレコードを生成する必要があるのか？

新進気鋭のフローデザイナーが犯す最も一般的な間違いの1つは、障害パスを構築していないことです。障害パスは、フローがエラーに遭遇したときに対処するためのもので、フローが何をすべきかを指示するものです（例外処理と考えましょう）。最も一般的な使い方は、画面ベースのフローでエラー画面を表示したり、エラーメッセージを含むメールアラートを複数の人に送信することです。

そうすれば、障害パスの一部を変更する必要があっても、すべてのフローに対して1か所だけで済みます。

エンタープライズグレードの実装では、フローがApexコードと同じ場所にエラーを記録する包括的なロギング戦略を使用することを検討してください。Nebula Loggerのようなオープンソースツールを使用して、フローが失敗したときにカスタムLogオブジェクトに書き込むこともできますし、豪華なものが必要ない場合は、上位権限のあるサブフローにログレコードを作成させるだけでもかまいません。

6. 画面フロー：フローの「文脈」を意識する

画面フローを使用する際には、フローが実行されるコンテキストに常に注意を払う必要があります。画面フローをユーザコンテキストの下で実行させる場合、Userオブジェクトや設定オブジェクトにある管理者固有の項目のように、ユーザが見ることのできないオブジェクトにレコード取得要素を作成しに行かないようにしましょう。

ターゲットとするユーザ層とそうでないユーザでテストをします。ユーザが自分のために作られたのではないフローで、荒れた体験をするのは避けたいものです。きめ細かい制御が必要な場合は、フロー固有の権限や権限セットを介して割り当てられたカスタム権限などを活用して、フローのアクセスを管理します。フロー全体へのアクセスを制御する必要がありますか？フローの権限を活用してください（※リンク切れ）。1つのフローの特定の部分へのアクセスを制御する必要がありますか？決定要素の $Permission変数またはまたは項目の表示条件を使用して、実行ユーザに割り当てられたカスタム権限を参照することができます。

システムレベルの項目やレコード（カスタムメタデータレコードなど）を本当に取得する必要がある場合は、上位のシステムコンテキスト権限が含まれるサブフローを使用して、フロー間で呼び出すことができる主要なタスクを実行します。

すべてがシステムコンテキストを尊重するわけではありません！ルックアップやファイルのアップロードなどの Lightningコンポーネントや、フローの動的フォームのレコード項目は、システムコンテキストに対応していません。

7. トリガ式自動化戦略を評価する

すべてのオブジェクトには、ビジネスのニーズとそれをサポートする Salesforce チームのニーズに基づいた自動化戦略が必要です。一般的には、1つのオブジェクトにつき1つの自動化ツールを選択する必要があります。古い組織では、Apexトリガと自動起動フロー/プロセスが混在していたり、最近ではプロセスビルダーとレコードトリガのフローが混在していたりすることが避けられないシナリオの1つです。これは、以下のような様々な問題を引き起こす可能性があります。

1.パフォーマンスの低下
2.「スタック」での実行順序を制御できないことによる予期せぬ結果
3.アドミン/開発者が協力しないことによる技術的負債の増加
4.ドキュメンテーション債務

一般的なアプローチとしては、DMLアクティビティを分離してApexにオフロードし、メールアラートやアプリ内アラートなどの非DMLアクティビティを宣言型ツールで処理することです。アーキテクトやアドミンは、レコードトリガフローをシステムに組み込む最適な方法を模索しており、私たちはまだ「ワイルド・ワイルド・ウェスト」の段階にあります。

より冒険的な組織では、トリガーハンドラーを使用して自動起動フローをトリガしています（例としてMitch Spanoのフレームワークを参照）。これは、アドミンと開発者の両方を協力させるための素晴らしい方法です。

Mehdi Maujoodによる、様々な自動化を混在させることの落とし穴についての素晴らしい記事があります。

一般的に、プロセスビルダーと特にワークフロールールは廃止される予定なので、この2つから離れるべきでしょう。Winter’23の時点で、新しいワークフロールールを作成することができなくなったことを忘れないでください。

ビジネスニーズに応じて、大量のフローを構造化することができる

プロセスビルダー時代の「1オブジェクトに1プロセスビルダー」というガイダンスはなくなりましだからといって、1オブジェクトに何百ものフローを作成する必要はありません。1つのオブジェクトに何百ものフローを作成する必要もありません。ビジネスニーズを考慮して、レコードトリガ型のフローを合理的なレベルに保つようにしましょう。フローは、ビジネス機能や役割ごとに分けて、競合が起きないようにするのがよいでしょう。また、フローを管理するアドミンや開発者の人数も考慮に入れておくとよいでしょう。つまり、フロートリガエクスプローラーによって順序付けられた、より小さく、より保守性の高いフローを複数構築し、細かい入力条件を設定する方が簡単かもしれません。

このブログ記事の下の関連リンクにある素晴らしい Automate This！セッションで、レコードトリガフローの様々なデザインパターンを紹介していますので、ご参照ください。

開始条件を使用する

開始条件を具体的に設定しましょう -フローで使用されないレコードの変更に対して自動化を実行したくないのです。フローチームは、プロセスビルダーの主要な課題であった、開始基準を満たさないフローの計算コストを大幅に改善しました。これは、実行順序の問題とともに、オブジェクトの自動化が多すぎるという、残された障壁の1つを取り除くものです。

ベンチマークとパフォーマンスについて言えば、自動化のトリガとなったレコードと同じレコードを更新するときは、必ず保存前更新フローを使用します。Record-Triggered Automationのアーキテクトガイドによると、保存前更新フローは保存後フローよりもかなり速く、Apexとほぼ同じパフォーマンスです。

8. データロードとsandboxのシーディングのために、フローにバイパスを構築する

これはフロー固有のベストプラクティスではありませんが、トリガや宣言的自動化にバイパス（迂回路）を含めるのは良いアイデアです。このようなバイパス戦略により、データを一括インポートする必要がある場合、オブジェクト（またはグローバル）のすべての自動化を無効にすることができます。これは、新しい sandboxのシーディング（検証のためのテストデータ等の整備）や、大量のデータを組織にロードする際に、ガバナ制限を回避するための一般的な方法です。

自動化に一貫性を持たせ、バイパスを1つの場所（カスタムメタデータタイプやカスタムパーミッションなど）にまとめるだけで、多くの方法があります。

9. スケジュール済みフローがガバナ制限にどのような影響を与えるかを理解する

スケジュール済みフローを設定する際に、レコードスコープを選択することで、そのフローに大きなガバメントリミットが発生します。ここで言う「スコープの設定」とは、sObjectとフィルター条件を選択する画面のことです。

フローの開始（上）でレコード範囲を指定する場合

スケジュールされたフローのクエリによって取得された各レコードに対して、1つのフローインタビューが作成されます。

24時間あたりのスケジュールされたフローインタビューの最大数は、250,000、または組織内のユーザライセンス数に200を掛けた数のいずれか大きい方です。

つまり、この方法で24時間あたり250,000以上のレコード（またはユーザライセンスに基づく制限値）に対して行動することはできないのです。それ以上の件数を処理する必要がある場合は、ここで範囲を指定せず、呼び出し可能なアクションを実行することをお勧めします。また、Apexの一括処理や非同期処理を検討する必要があるかもしれません - これらのシナリオでは開発者に助けを求めてください。

フロー内のスコープを指定する場合（呼び出し可能なアクション、Get Records)

制限は、あなたが慣れ親しんでいるものとより一致するようになります。つまり、レコードごとに1つのインタビューが作成されるのではなく、フローに対して1つのインタビューが作成されることになります。この方法を取る場合、同じレコードのセットに対してスコープを指定しないでください（上のスクリーンショットを参照）。もしそうすると、フローはN²のレコードに対して実行され、すぐに限界に達してしまいます。

このルートは、制限をよりコントロールする必要があり、SOQLや複雑な処理を含む Apexを呼び出したい場合に使用します。

このシナリオでは、最初のレコード取得で800レコードが返された場合、フローはこれらのレコードをバッチ処理しようとしません。実行中のユーザはまだ自動プロセスユーザ（ Automated Process user）であり、すべての CollaborationGroups（Chatterグループ）やライブラリを表示できないなど、特定の癖があることに留意してください。

ダブルディッピング：レコードスコープを選択し、同じレコードセットに対してレコードを取得するステップを実行しないでください。

どの道を選べばいいのか？

どちらの道を選ぶべきか、正解も不正解もありません。バッチサイズや総レコード数をスコープに指定することはできません。そのため、制限をより厳密に制御したい場合は、invocable（呼び出し）を作成し、スコープを指定するのがベストかもしれません。あるいは、スケジュール済みフローでこれを行わず、Apexのスケジュールされたジョブを使用します。

また、レコードの日付が関係するユースケースでは、代わりにレコードトリガ型のフローでスケジュールパスを構成することができます。スケジュールパスは、より柔軟なガバナ制限を持ち、バッチサイズも設定できるため、Apexとスケジュールトリガフローの中間的な存在になる可能性があります。

スケジュールフローに関する考察は、公式ドキュメント「スケジュールトリガフローのに関する考慮事項」をご覧ください。

10. チェックリストで確認する

これで、素晴らしいフローを作る準備が整いました。ここで、すべてのフローに適用される便利なチェックリストを紹介します。

1. 要素や説明の文書化：フローには、しっかりとした説明文、変数の適切な命名規則、6ヶ月後に見直したときに意味をなさないかもしれないフロー要素の説明文があることを確認します。

2. Null/Emptyのチェック：レコードの集合を処理する前に、決定要素でNullまたはEmptyの結果をチェックすることを忘れないでください。幸せな道筋だけを想定しないで、起こり得るシナリオをすべて想像してください。

3. ハードコードされたID：所有者ID、キューID、グループ、レコードタイプIDのようなIDをハードコードしないでください。DeveloperNameを使用して、それぞれのオブジェクトのレコードを取得します。開始条件を作成する場合、DeveloperName（API名）項目を数式で参照することができます。

4. ハードコードされたロジック：決定の条件ロジックで、キューID、オーナーID、数値（割引率など）のように、頻繁に変更される可能性のあるものは、ロジックをハードコードしないでください。カスタムラベルやカスタムメタデータを活用しましょう。

5. 過度なネストループと「ハック」：もっと適切なコードがあるはずなのに、フローのパフォーマンスを限界まで引き延ばしていませんか？開発者が構築した汎用的な Apexの呼び出しを使用するか、Automation Component ライブラリやその他のオープンソースから提供されたコンポーネントを利用しましょう。

6. 大量のデータに対するループ処理：フロー要素の制限（現在2,000）または Apexの CPU制限を引き起こす可能性があるレコードの大規模なコレクションをループしないようにします。

7. レコードと項目のセキュリティとフローのコンテキストをチェックする：画面フローを構築する場合、ユーザが設計したものをすべて見ることができ、実行できると仮定しないでください。意図したユーザーと意図しないユーザーの両方を想定してフローをテストしてください。

8. ループの中のデータ操作：自動起動フローやレコードトリガフローでは、作成/更新/削除要素をループ内に配置しないようにしましょう。新しい「次に含まれる/次に含まれない」演算子を可能な限り使用してください。

9. フローのエラー：フローにエラーが発生した場合、どのような処理を行うのでしょうか？誰に通知するのか？障害パスを使いましょう

10. 自動化のバイパス：自動起動やレコードトリガーのフローには、カスタム設定やカスタムメタデータベースのバイパスが用意されていますか？

構築しましょう！

ここまで来られた方、おめでとうございます。フロー構築のプロへの道を歩んでいるのは、あなただけではありません。Salesforce Automation Trailblazer Communityに参加して、世界中のSalesforceアドミンとつながってください。このコミュニティでは、他のアドミンが構築しているフローについて詳しく学んだり、プロダクトマネージャーから最新の情報を聞いたり、フローについて質問したりすることができます。このガイドがお役に立てれば幸いです。あなたが作るフローを見るのが楽しみです。

リソース

Architect’s Guide to Record-Triggered Automation
Salesforce Automation Trailblazer Community
UnofficialSF
Automation Component Library
Advanced Logging with Nebula Logger
Flow Naming Conventions | SFXD Wiki

公式ブログより、フローのベストプラクティス（長いです）