はじめに
ここ1年のアップデートで、フローの使い勝手は大きく向上しました。
フローのバリエーションが増え、トリガの種類が増え、利用可能なリソースが増え、スケジュール済みパスが増え…
出来ることの幅も大きく広がりました。（むしろできないことが探すのが難しいぐらい）
処理の速度もプロセスビルダーと比べて格段に速く（保存前トリガでは10倍速いと謳われている）、これからはプロセスの自動化はフローを主軸に考えることになると思います。
Salesforce側もこれからはフローを中心にしていこうと考えているような気もします。（ここ最近、プロセスビルダーにアップデートがかかっていないはずですし。）
しかし、プロセスビルダーとフローは全く同じ感覚で使用できるものではありません。「プロセスビルダーの方が直感的に使えてやりやすい」というような声も結構耳にします。
ただ、プロセスとフローが処理される順番が決まっており、両者が混在していると思わぬ悪影響が発生する懸念があります。どちらか1つに統一したほうが、将来的に良いような気もします。
ということで、今回は両者の大きな違いを3点ほど上げていこうかな、と思います。
違い①:項目に割り当てる値に数式を直接使用できない
プロセスビルダーでは項目を更新する際に、値に数式を入力することが可能です。
フローにおいて、項目に値を割り当てる際は「割り当て」要素を使用することになります。ですが、この要素の中で割り当て値に直接数式を入力することはできません。（入力したらエラーを吐かれます。）
でもご安心。
フローでは、変数・定数などといった「リソース」を自分で用意することができます。（この「リソース」がフローの理解を難しくしているような気もする）
リソースを新規作成するときの形式を「数式」にして、数式を入力し、そのリソースを「割り当て」要素の割り当て値に使用することで解決できます。
違い②:フローで使用できない関数がある
自動化において、「レコードの更新前の値を参照したい」とか、「レコードのこの項目が更新されたか調べたい」とか、「このレコードが新規に作成されたものか調べたい」といった状況に遭うことがあります。
この場合、プロセスビルダーでは、PRIORVALUE()・ISCHANGED()・ISNEW()といった関数を使用することで容易に実現することが可能です。
フローでは、これらの関数を使用できず、別の方法でこのロジックを実現することも、つい最近までできませんでした（多分）。
このことが、自動化ツールとしてプロセスビルダーを使用する要因となっていました。
そう、つい最近までは。
Spring'21のアップデートのリリースノートにこんな記述がありました。
フローをトリガしたレコードの前の値の参照
レコードが更新されたときに、そのレコードの前の値に Salesforce Flow でアクセスできるようになりました。$Record__Prior グローバル変数には、フローの実行直前のレコードの値が含まれます。
__これを待っていたんだよこれを！__と叫びたくなるようなアップデートでした。
今後はこの機能を利用することで、PRIORVALUE()・ISCHANGED()・ISNEW()といったフローで使用できない関数の完全代替が可能となりました。
具体的には、
PRIORVALUE():$Record__Priorに直接アクセスする
ISCHANGED():数式リソースや「決定」要素で、$Record__Priorと$Recordを比較する
ISNEW():数式リソースや「決定」要素で、$Record__PriorがNullかどうか判定する
こうすることで、代替が可能です。プロセスビルダーを利用する理由が1つ消えました。
違い③:スケジュール済みタスクの考え方
時々、「条件を満たしてもすぐに処理を行わず、一定時間後に処理をしてほしい」といった状況に遭うことがあります。
この場合、プロセスビルダーでは条件を設定したのちに「スケジュール済みタスク」を設定することで実現できました。
フローには、つい最近までこのような機能がありませんでした。
このことが、自動化ツールとしてプロセスビルダーを使用する要因となっていました。
ええ、つい最近までは。
Spring'21のアップデートのリリースノートにこんな記述がありました。
トリガイベントの後にレコードトリガフローの一部を実行
トリガイベントの発生後、動的にスケジュールされた時間にフローの一部を実行する場合は、スケジュール済みパスをレコードトリガフローに追加します。スケジュール時間は、レコードの作成時や更新時、またはレコード内の項目値に基づくことができます。
__これを待っていたんだよこれを！__と叫びたくなるようなアップデートでした（二回目）。
この機能を使うことで、プロセスビルダーでの「スケジュール済みタスク」と同じようなことができるようになりました。プロセスビルダーを利用する理由がまた1つ消えました。
ですが、この二つには__大きな考え方の違い__が存在しています。
プロセスビルダーでは、「条件を満たしたら、タスクをスケジュールする」といった形です。
フローでは、「スケジュールされた時間になったら、パス（「決定」要素などの条件分岐も含む）を実行する」
といった感じです。条件分岐とスケジュールの順番が逆になっているような感じですね。
そのため、フローではスケジュールによってパスを複数用意することになります。