この記事は、Salesforce Advent Calendar 2023 の11日目の記事です。他の記事もぜひ見てみてくださいね！

この記事を読んでほしい人

ワークフロー・プロセスビルダーが廃止されて困っている人
↑の廃止理由がわからず腑に落ちない人
自社のSalesforceがなんだか重く感じる人
ガバナ制限のことをちょっと知りたい人

はじめに

Salesforceのデータを自動更新できるツールとして人気を博していたワークフローとプロセスビルダーですが、なんと今年のSummer'23リリースで廃止、フローに全面移行となりこれらは新規作成不可となってしまいました・・・

割と唐突に始まったこの廃止施策、特にこのツールを愛用していたAdmin層からは多くの戸惑いの声が挙がっていました。
確かにフローは高機能で便利ですが、組むために覚えることが多いのでプロセスビルダーが簡単で使いやすい。もう作りたいものは一通り作ってしまったので、今動いてるプロセスはこのまま移行しなくてもいいかな・・？そう思う人もまだいると思います。

「なぜ移行しなければいけないのか？」という問いに対するアンサーが意外となかったので、自分なりに考察してみました。

プロセスビルダーとはなんだったのか

「プロセスビルダー」と「フロー」はほぼ同時期に登場しており、メタデータ的にも大筋で「Flow」として同様に取り扱われるいわば兄弟のような機能です。
フローを組むには多くの要素を自力で配置しなければないのに対し、起動条件とアクションがシンプルにまとまっているプロセスビルダーのほうが多用されていました。
（しかも当初のフロービルダーはFlashベースで取り回しが悪かった・・・）
レコードトリガフローが実装されたのも割と最近で、それまではプロセスビルダーを起点としてフローアクションを起動する実装もメジャーでした。

しかしプロセスビルダーはこのシンプルさと引き換えに、ある潜在的問題を抱えていたのです。

なぜプロセスビルダーを使ってはいけないのか

レコード更新時処理としてプロセスビルダーを用いる場合、他の更新処理より余計にガバナ制限を消費してしまうのです。

あるレコードを更新した場合、画面に表示されない項目を自動更新するという要件を考えます。
プロセスビルダーの「レコードを更新」アクションを使ってこれを実現した場合、ガバナ制限上ではSOQLクエリとUpdate処理が1回ずつ計上されてしまっているのです。
実際ヘルプにもこう書いています。

各 [レコードを作成] アクションでは、1 つの DML ステートメントが使用されます。各 [クイックアクション] アクションでは、1 つの DML ステートメントが使用されます。各 [レコードを更新] アクションでは、1 つの SOQL クエリと 1 つの DML ステートメントが使用されます。各 [フロー] アクションでは、フローで実行される要素に応じて、複数の SOQL クエリと DML ステートメントを使用できます。詳細は、「トランザクション単位のフローの制限」を参照してください。

推察するにこれは、「レコードの更新」アクションが内部ではフローアクションとして処理されているためではないでしょうか。
（多分こんな感じ、実際これをプロセスビルダーから起動させると同じ結果になりました）

この仕様の恐ろしい点として、以下の点が挙げられます

同一プロセス・同一条件の中でも1アクションごとに1回起動してしまう
更新アクションが起動するたびに、そのレコードのレコードトリガフローやApexトリガも起動してしまう

特にApexトリガの場合、Before UpdateとAfter Updateの両方で動くトリガは2回動作してしまいます。
Apex側の実装にもよりますが、プロセスビルダーとApexの組み合わせによって不必要に多数のトリガ処理が走ることがあり、場合によってはガバナ制限エラーにまで至ってしまいます。
一度こうなるともうどうにも更新処理ができず、業務が回らなくなってしまうかも・・・可能であれば、そうなる前に対処すべきです。

ちなみに、ワークフローでは・・・？

ワークフロー項目自動更新では、実はガバナ制限を消費していません。これはそもそもガバナ制限に抵触するような高負荷な処理ができないからだと思われます。ワークフローではBefore Updateトリガで実装できる範囲の簡易な処理しか実装できないのです。

ではどうすべきなのか

「フローに移行」機能を使ってプロセスビルダーの更新処理をレコードトリガフローに移行することが最新のベストプラクティスとなります。レコードトリガフローはApexトリガと同じくBefore/Afterの動作条件設定ができるようになり、このアクションと同様の事象を回避できるようになっています。
「フローに移行」は、現在存在するプロセスをベースとして僅かなステップで代替フローを作成することができます。

1.対象のプロセスを選択する

設定画面の「フローに移行」リンクを押すと、ワークフロー/プロセスの一覧が表示されます。移行対象の1件を選択してください。

2.プロセス内の判定条件を選択する

プロセス内の各判定条件（ひし形+アクション欄を含む1行）を選べるので、1つのフローに含めたいものをまとめて選択します。

今回の事例では、「プロセスを開始したレコード」に対する更新アクションのみが含まれるようにしてください。「関連するレコード」への更新アクションや、「レコードを作成」アクションを一緒に含めてはいけません。

3.作成されたフローにひと手間加える

「フローに移行」ボタンを押すと、自動的に代替フローが作成されます。
(無効化状態で定義が保存されています)

後はこれを有効化するだけ・・・としたいところですが、有効化の前にもう一つ編集しておきます。
フロー開始部分の要素を編集し、「*フローを最適化:」部分を高速項目更新に変更してください。
これにより、このフローは起動条件がBefore Update相当の処理に変更され、ガバナ制限を消費しない処理になります。

あとがき

手順2.で書いたように、全てのアクションを移行できるわけではありません。（無理に行っても更新エラーになるだけです）

しかし、たったこれだけの手順で更新時負荷が軽減されるのであれば、試しにやってみる価値はあるのではないでしょうか？
この記事がその一助になれば幸いです。