バッチ処理のベストプラクティス
基本的に下記が推奨
1時間当たりの処理レコード件数が1000件以下の場合は、スケジュールフロー
1時間当たりの処理レコード件数が1001件以上の場合は、ApexSchedulerからApexのBatchClassを呼び出す実装
Schedule-Triggered Flowの作成方法
Startコンポーネントの「What Launches the Flow」セクションで「Scheduled jobs-flow runs for a batch of records」を選択することでSchedule-Triggered Flowを作成することができるようになります。
「Set s Schedule」でバッチ処理を実行する日時を指定。
便利なのが「Run the Flow for a Set of Records」というOptionで、条件に一致したレコードを順に$Record変数に格納してくれるため、Get Recordsでレコードを取得してそれをLoop文で回す手間を省いてくれます。
で、例えば「一週間項目更新のない商談を自動クローズ」というユースケースで続きの判定ロジックを考えてみると、↓みたい感じになる。
Schedule-Triggered Flowの制限事項
Schedule-Triggered Flowの制限事項としては以下の二種類が挙げられます。
基本的には↓の三つに注意しておけばOK
- 24 時間あたりのスケジュール済みフローインタビューの数：250,000 または組織のユーザライセンス数×200 の大きい方
- 特定の時間に基づいた、再開されたフローインタビューまたは (プロセスから) 実行されたスケジュール済みアクショングループの 1 時間あたりの数：1000
- 実行時に実行された要素のフローあたりの数：2000
スケジュールフローで一時間以内に1000件以上のレコード処理がなされる場合、最初の1000件のみ処理され、残りのレコードについては処理されません（※エラー通知などなし
→なので、処理レコード件数が1000件超えが散発的かつクリティカルなものでない場合は無視するという選択肢もある。
一方、実行時に実行された要素のフローあたりの数2000件に引っかかった場合は、エラーが発生し、処理は一切なされません。
よく発生するエラー
UNABLE_TO_LOCK_ROW: unable to obtain exclusive access to this record
スケジュールフローによるレコード操作（DML操作）が既存のロジックと干渉した場合に発生しがちなエラー。商談のStageName更新時にIsClosed自動更新のようにプラットフォーム側が裏でやるロジックと干渉した際に発生することもある。
回避策は色々ありますが、DML操作を非同期処理に変更するのがおすすめです。
Apexの場合は@futureメソッド、プロセスビルダーやフローの場合は0 Hours Laterでアクションを非同期化することが可能です。
■プロセスビルダーのアクションの非同期化
■フローのアクションの非同期化
