salesforce開発現場で処理が多く長いフロー作成に悩まされました。

Geminiと会話したところ、やはりフローにも弱点があり、Apex開発も必要という落とし所がありましたので共有します。

フローはノーコードで手軽に開発できるため、多くの現場で導入が進んでいます。また、salesforceもノー、ローコード開発ができる事を強みとして宣伝していると思います。
しかし、フロー開発への頼りすぎにはリスクがあります。

すべてのロジックをフロー実装はリスクが生じる

• メンテナンス性の悪化 : ロジックが複雑化し、多数のコンポーネントが絡み合うと、誰が見ても理解しにくい「スパゲッティフロー」になります。
• パフォーマンス低下 : 大量のデータ処理や複雑なループ処理をフローで行うと、実行速度が遅くなり、ユーザー体験を損なう可能性があります。
• 開発効率の低下 : 画面スクロールやウィンドウの開閉が増え、特定のロジックを探す手間がかかり、開発者の作業効率が落ちます。

以下の位でしたらまともだと思いますが、、、もっと増えると危ういと思います。

単一大型フローよりApex開発の理由

これらのリスクを回避するためには、フローの限界を理解し、 Apexを適切に取り入れる必要があります。
• 複雑なロジックの実現 : 外部システム連携や高度な計算、ガバナ制限を考慮した効率的な処理など、フローでは実現が難しいロジックを確実に実装できます。
• 再利用性と保守性の向上 : 複数のフローやアプリケーションで共通して使うロジックをApexでコンポーネント化することで、一元管理が可能になり、全体のメンテナンス性が大幅に向上します。
• 開発の効率化 : VS Codeなどの開発環境で管理することで、コードの検索、編集、全体像の把握が容易になり、開発スピードが上がります。

まとめ：フローとApexの最適な分業

結論として、フローとApexはどちらか一方を選ぶものではなく、お互いの強みを活かした分業体制が最も効果的です。
• フローはシンプルで視覚的な処理に徹する
• Apexはフローから呼び出される、裏側の複雑な処理を担う

フローとApexの分業体制を確立することで、開発のハードルを下げつつ、システムの健全性とパフォーマンスを長期的に維持できます。

今後のアップデートでフロー開発体験が改良される可能性はあります。
しかし、現状はフロー開発へ頼り過ぎず、Apexでの開発を検討すると良い場合がある事は踏まえてください。