Record-Triggered Automation（備忘録）
最も重要な要点は以下のとおりです。
● 要点1：フローとApexは、プラットフォーム上のトリガーよる自動化に推奨されるノー
コードおよびプロコードソリューションです。
● 要点2：同一レコードの項目更新をワークフロールールとプロセスビルダーに入れるの
はやめましょう。代わりに、同一レコードの項目更新を 保存前更新を実行する フロート
リガーに入れるようにしましょう。
● 要点3：可能な限り、プロセスビルダーやワークフローではなく、レコードの保存後に実
行するフロートリガーでユースケースを実装するようにしましょう (同一レコードの項目
更新を除く。その場合は要点2を参照)。
● 要点4：高性能なバッチ処理が必要な場合、または高度に洗練された実装ロジックが必
要な場合は、Apexを使用してください。(詳細については「Well-Architected - データ
処理 」を参照してください)
https://architect.salesforce.com/well-architected/easy/automated#Data_Handling
● 要点5：レコードトリガーによる自動化のすべてをオブジェクトごとに 1つの「メガフロー」
にまとめる必要はありませんが、長期的に自動化を整理し、維持する方法については
考える価値があります。(詳細については「Well-Architected - コンポーザブル」を参照
してください)
https://architect.salesforce.com/well-architected/adaptable/composable
要点3に「レコードの保存後に実
行するフロートリガーでユースケースを実装するようにしましょう」とあるが、95%のトリガフローはbeforeで実装できるはず。
Apex開発者がいてフレームワークも整ってるならApexでもええが、
一方、チームに開発者リソースへの一貫し
たアクセスがなかったり、強力に組織化されたコード品質のカルチャーがなかったりする場合
は、少数の人しか保守できない数行のコードよりも、より多くの人が保守できるトリガーフロー
の方が有益である可能性が高いでしょう。
理解。とはいえフローではパフォーマンス的に良くない場合でもフローを選択する機会ありそう。所謂「高性能バッチ処理」に分類される物。高性能バッチ処理ってなんだよって話だけど。ここの線引きがむずいんだが！
ユースケースの考慮事項
同一レコードの項目更新
ワークフロールールまたはプロセスビルダーのプロセス内で、同一レコードの項目更新ア
クションの実装をしないでください！ また、レコードの保存後に実行するフロートリガーで同一
レコードの項目更新の実装もしないでください！ 代わりに、保存前更新を実行するフロートリ
ガーまたは 保存前更新を実行する Apexトリガーで同一レコードの項目更新アクションを実装
するようにしてください。
基本的にbeforeを使え
- レコードの項目値はすでにメモリにロードされており、再度ロードする必要がありませ
ん。- 更新は、メモリ内のレコードの値を変更し、元のDML操作に依存して変更をデータベー
スに保存することによって実行されます。これにより、高価なDML操作だけでなく、それ
に付随する再帰的な保存も回避できます。
高性能バッチ処理
● 複雑な論理式や数式の定義と評価
○ フローの数式エンジンは、非常に複雑な数式を評価する際に時折パフォーマン
スが低下します。この問題は、バッチユースケースで悪化します。なぜなら、数
式は現在、実行時にシリアルにコンパイルと評価が行われるからです。私たち
はバッチに対応した数式のコンパイルオプションを積極的に評価していますが、
数式評価は常にシリアルに行われます。数式評価のパフォーマンス低下の根
本的な原因はまだ特定できていません。
● 複雑なリスト処理、大量のレコードからのデータのロードと変換、無限ループ
○ フローでリストを直接扱う際の現在の制限については「複雑なリスト処理」を参
照してください。
● Map または Set のような機能を必要とするもの
○ フローはMapデータ型をサポートしていません。これに関連して、Apex呼び出
し可能アクションがApexオブジェクトをフローに渡し、そのApexオブジェクトに
Map型のメンバ変数が含まれている場合、フローではそのメンバ変数にアクセ
スすることはできません。ただし、メンバ変数は実行時に保持されるため、フ
ローがそのApexオブジェクトを別のApex呼び出し可能アクションに渡すと、受
信側のApex呼び出し可能アクションでメンバ変数にアクセスできます。
● トランザクションのセーブポイント
○ トランザクション セーブポイントはフロー トリガーではサポートされておらず、今
後もサポートされることはないでしょう。
Map使ってゴリゴリやる系がよさそうなやつはApex選んでもええってことかね。
お化けフローや大量のサブフローで構築されているあのフロー群は適切なのか？
まあなんだかんだSalesforce公式でもApex使う事をそこまで躊躇していない感じはする。
（それをベンダーが許容するか置いといて）
保守性がどうこうって話はあるが、よほどお化けフローよりもApexで奇麗に書かれている方が読みやすい気はするんだが。フローの数式使って誤魔化して訳分からなくなっているケースもあるだろう。
クロスオブジェクトCRUD
複雑なリスト処理
フローからApex呼びだそう！Apexは共通化して色んな所から呼び出そう！
体感的にこの実装は悪くなさそう。Salesforceにおいては。
BLを共通化することで、Apexバッチとフローから呼び出せる。この設計は間違っていなかった。
続きは後日
Discussion