【Salesforce】レコードトリガーフローの最適設計を考える

Salesforceのレコードトリガーフローを便利だからといって考えなしにポンポン作成していくと管理コストがかさんだり、他の処理に影響を及ぼしたりと後々大きな負債になりがちです。

ぜひともそんなことにはなりたくない、ということでレコードトリガーフローの最適設計について考えてみました。

唯一の正解があるわけではないと思いますが、自分はこう考えているよ～ということをシェアできればと。

この記事の内容は個人の見解です。
へえ、そういう考えがあるんだというくらいに受け取っていただけるとうれしいです。

レコードトリガーフローは需要が高い

これまでいくつかのSalesforce案件にかかわってきましたが、レコードトリガーフローを使用しなかったことはありませんでした。

フローを使用しない場合でもApexトリガーは使用していましたね。

それだけトリガー処理は需要が高くそこに価値を感じている方が多いということでしょうね。

レコードの挙動を発火点として、レコードの作成、更新、削除、自動通知やApexの呼び出しなど数々のアクションを実行することができるのでそりゃそうか。

それもノンプログラミングで。

レコードトリガ―フローの最適設計

さて、私が考えるレコードトリガ―フローの最適設計は以下になります。

1オブジェクトにつき原則3フローで作成

レコードトリガ―フローの起動条件のパターンは以下の7つになります。

#	フローをトリガーする条件	フローを最適化
1	レコードが作成された	高速項目更新
2	レコードが作成された	アクションと関連レコード
3	レコードが更新された	高速項目更新
4	レコードが更新された	アクションと関連レコード
5	レコードが作成または更新された	高速項目更新
6	レコードが作成または更新された	アクションと関連レコード
7	レコードが削除された	レコードが削除される前

このうち#5、6、7の条件を軸として利用します。

起動条件としてレコード作成時、更新時、削除時の3パターンはまず押さえておく必要があります。

作成時と更新時の条件に付いては、作成時と更新時が1つの条件にまとめられた「レコードが作成または更新された」を使用します。

それぞれ分離された条件を使用してもいいのですが、その後の拡張性を損なう恐れがあるので自分はあまり使用しません。

「レコードが作成または更新された」であればその処理中でトリガー元のレコードが作成されたのか更新されたものなのかを判定できるのでやはりこちらかなあと。

「高速自動更新」はいわゆるBeforeトリガ（レコード作成前/更新前/削除前）で、「アクションと関連レコード」はAfterトリガ（レコード作成後/更新後/削除後）を指します。

フローでは、レコード削除時はBeforeトリガのみ実行可能なので、結果的に3つのフローを作成すればよいことになります。

ちなみにApexでは1つのトリガー内に複数のコンテキストを含むことができるので1オブジェクトにつき1トリガーの作成で済みます。

フローの場合はコンテキスト分必要になります。

フローをたくさん作るのはオススメではない

１つのオブジェクトに対して小さなフローをいっぱい作っていこうという考えもあるかと思いますが、オススメではないです。

新しい機能を実装するたびにフローの数が増え、管理コストが爆上がりしますし、それぞれのフローの実行順の整理も必要です。

また、多数のフローが同時に動作すると、システムのパフォーマンスに影響を与える可能性があり、特に複雑な条件や処理が含まれる場合、処理の遅延やリソースの消費が増加することがあります。

もちろん1つ1つのフローがシンプルになり可読性が上がったり、開始条件を細かく指定できるので無駄な起動や処理を抑えることができるというメリットはあります。

要はフローを分割する場合も、管理コストとのバランスを見て判断することが大事というお話なのです。

サブフローを利用しよう

さきほどレコードトリガ―フローは1オブジェクトにつき、以下の3つが原則というお話をしました。

もちろんこの３つのフローにすべての処理を集約することは可能ですが、組織が大きくなりビジネスが拡大していく過程で追加実装される処理をすべてまとめていくのはなかなか難しかったりします。

そこで「サブフロー」活用し、処理をいーい感じに分割していきます。

サブフローとは、フロー内で呼び出される別のフローのことです。

サブフローの利点はこんな感じ。

サブフローを作成することで、共通の処理ロジックを一つの場所に集約し、複数のフローから呼び出すことができます。こうすることで同じ処理を複数回記述する手間を省けますよね。

また、もしサブフロー内の処理に変更が必要な場合、一度変更するだけでそのサブフローを使用しているすべてのフローに変更が反映されます。

さらにフローを小さな部分に分割して設計することができるので複雑なロジックを扱う場合でも管理しやすくなります。

ただ作りすぎは結局管理が大変になるのでここもまたバランスには注意したいですね。

おわりに

フローの最適設計って言ってますが、組織にもよるし機能にもよるし正解なんてない気がします。

ただ、salesforceはパッケージ製品であり、何をするにもトレードオフなので自分の中でこれが最適だろうという答えはあってもいいんじゃないかなと思います。

ひとまず今回は私が思う最適解でした。