【Salesforce】フローの概要とできることできないこと

2021年9月に開催されたSalesforceのイベントにて、
段階的にワークフロー・プロセスビルダーを廃止し、今後はフローの機能を強化していくことが発表されました。

ワークフロー・プロセスビルダーで作成してきた自動化プロセスは、
フローに置き換えていく必要があります。

そこで、フローについてこれから数回に分けて紹介していきます。
今回は「フローとは何ぞや?」という概要と、フローでできること・できないことの比較記事となります。

(参照)
・Salesforceの公式文章として初めてフローの廃止に触れた記事(英語)
https://admin.salesforce.com/blog/2021/go-with-the-flow-whats-happening-with-workflow-rules-and-process-builder

 

■フローの概要

-フローとは?

ノーコードで自動化プロセスやアプリケーション作成が可能なツールです。
Apexほど高度な処理ができませんが、「開発コストが抑えられる」「修正がしやすい」などのメリットから、Salesforceで現在強化を進めている機能の一つです。

-どんなことができるの?

一例として以下のような処理が行えます。

  • 簡易的な画面作成
  • レコード操作(作成、更新、削除)・検索※
  • バッチ処理
  • メール通知やChatter投稿などのアクション
  • ログイン時に画面呼び出しやレコード更新(ログインフロー)

※レコード保存前更新・レコード保存後更新も可能
※関連レコード以外のレコードの検索も可能

 

■Apex・LWCとの比較

・Apexとの比較(2022年2月時点)

 

レコード保存前フロー  レコード保存後フロー  Apex     
同じレコードの項目更新 ※1 利用可能 理想的ではない 利用可能
高性能バッチ処理 ※2 理想的ではない 理想的ではない 利用可能
オブジェクトをまたがる作成・更新・削除 利用不可 利用可能 利用可能
非同期処理 ※3 利用不可 利用可能 利用可能
複雑なリスト処理 ※4 利用不可 理想的ではない 利用可能
カスタム検証エラー

(入力規則のようにDMLエラー)

利用不可 利用不可 利用可能

・利用可能:正常に動作する
・理想的ではない:可能だが、重要な考慮事項がある
・利用不可:今後12か月以内にサポートする予定はない

※1 レコード保存前フローはレコード取得や数式項目の使用ができないが、処理が早い
※2 フローは複雑な数式・リスト処理(※4)に弱い・Mapデータ型をサポートしていない
※3 フローは複雑なエラー処理はできない、再試行のデータ量は一定量しかできない
※4 フローはリスト内の並べ替えやフィルター処理が面倒
ループ機能によってコレクション内の「項目」を参照できず、参照できるのは「値」のみ

 

(参照)
Record-Triggered Automation
https://architect.salesforce.com/design/decision-guides/trigger-automation/#Same_Record_Field_Updates

 

LWC(Lightning Web Component)との比較(2022年7月時点)

 

動的フォーム 画面フロー LWC
デスクトップ上のカスタムオブジェクト 利用可能 利用可能 利用可能
デスクトップ上の任意のオブジェクト ロードマップ 利用可能 利用可能
マルチスクリーンフォーム※1 利用不可 利用可能 理想的ではない
クロスオブジェクト 利用不可 利用可能 利用可能
フォームの背後にあるロジックまたはアクション※2 利用不可 利用可能 利用可能
動的イベント処理※3 ロードマップ 利用不可(LWCと組み合わせて可能) 利用可能
ピクセルパーフェクトなスタイリング※4 利用不可 利用不可(LWCと組み合わせて可能) 利用可能
単体テスト 利用不可 利用不可(LWCと組み合わせて可能) 利用可能

・利用可能:正常に動作する
・理想的ではない:可能だが、重要な考慮事項がある
・利用不可:今後12か月以内にサポートする予定はない

※1:アンケートのように画面フォームを連続させること
※2:レコード操作やメール通知などのアクション
※3:コンポーネント間の連携(通信)
  (オブジェクトのレコードを介さず)画面要素同士で値を受け渡すこと)
※4:ピクセル単位でのUIデザイン

 

 

■フローの実装にあたって気を付ける点

細かい部分も含めると考慮事項は結構な数ありますが、特に重要そうだと思った点をご紹介します。
※文中の「要素」は次回の記事でご紹介します。

 

・1 度に実行できるフロー要素(処理)数: 2000まで
 例)レコード20件取得 →20件をループして変数に割り当て→レコード更新
         1+2×20+1=42要素 という数え方です。
 →ただし、間に画面要素をはさんだり、一時停止要素を追加するなどでトランザクションが分かれる場合は制限がリセットされます。

 

 ※トランザクション・・・分離できない、複数の処理を1つの処理単位にまとめたもの

【トランザクションの開始】はレコードの作成・更新、ボタンをクリックしたとき、URLにアクセスしたとき などを指し、
【トランザクションの終了】はレコードの更新が終了したときや、画面要素、ローカルアクション(ブラウザ上のアクション処理)、一時停止要素が実行されたとき などを指します。

 

・スケジュール済みアクションの 1 時間あたりの処理件数:1000件まで
・24 時間あたりのスケジュール済みフローの処理件数:250,000 または組織のユーザライセンス数×200 の大きい方
→バッチ処理や通知タイミングが指定されたメールアラートを実装する際は件数や処理時間も気にする必要がありそうです。

 

・1トランザクション単位のガバナ制限
→内容はApexと同じようです。
・SOQLクエリ(レコード取得要素)の合計:100回
・SOQLクエリ(レコード取得要素)によって取得されるレコード件数:50,000件
・DMLステートメント(レコードの作成・更新・削除要素)の合計:150回
・DML ステートメント(レコードの作成・更新・削除要素)によって処理されるレコードの件数:10,000件

 

・バッチサイズ(処理単位):200レコード
※Apexと同じ

 

以上の制限に抵触する可能性があるかどうかはデバッグ機能によって、
事前に把握しておくことができます。
デバッグ機能については以降の記事でご紹介いたします。

 

(参照)
・フローの制限および考慮事項
https://help.salesforce.com/s/articleView?id=sf.flow_considerations.htm&type=5
・分単位、バッチ処理、および制限の強化によるスケジュール済みパスのパワーアップ

■まとめ

フローはアドミンでも自動化処理ができるように機能強化されているノーコードツールではありますが、
ガバナ制限などを考慮する実装となると開発の知識もある程度必要そうな印象です。

 

また、なるべく標準機能のフローを用いるのが望ましいですが、
DMLエラーを実装したい、1時間あたりの処理件数が1000件を超える・・・という場合はApexを検討するなど、
何ができて何ができないのか見極めて使い分ける必要がありそうです。

 

今後もフローに関する記事をアップできればと思いますので興味がある方は覗いてみていただけると嬉しいです。