ワークフロールール/プロセスビルダーのフロー移行は済んでいますか?Salesforceは、2025年12月31日にワークフロールール/プロセスビルダーのサポートを廃止すると発表しています。
既存のワーフロー/プロセスビルダーの移行を検討されている方も多いと思います。しかし、「フロー移行って何をすればいいの…?」「ちゃんと移行できているか不安」「移行後の検証方法が分からない」と思っている方も多いのではないでしょうか。
そこで、今回は、「フロー移行後の動作検証」に焦点を当て、とくに動作検証に必要な手順や注意事項を紹介します。
※フロー移行については以下の記事をご参照ください。
https://www.sunbridge.com/blog/column/flow-migration-steps/
プロセスビルダーの確認とテストケース作成の準備
今回は例として「成績評価」というプロセスビルダーを用います。このプロセスビルダーは以下の動作をします。
- 「成績点数」オブジェクトの項目「総合点」が80点以上の時、項目「成績評価」をAにする
- 「成績点数」オブジェクトの項目「総合点」が40点以上80点未満の時、項目「成績評価」をBにする
- 「成績点数」オブジェクトの項目「総合点」が40点未満の時、項目「成績評価」をCにする
まず、フローに移行したいプロセスビルダーを確認します。確認するポイントは以下の3点です。
①どのようなときにプロセスビルダーが起動するか(起動条件)
②動作条件が何個あるか、また、その動作条件に数式が含まれているか
→数式が含まれている場合は要注意!
数式の場合、「プロセスビルダーの要素(上記画像の青いひし形)の個数 = 動作条件の個数」とはなりません…!
その数式がどのような意味で、どのような条件なのかをしっかりと読み解きましょう!
③「ルール適用時のアクション」はどのような動作になっているか
→別のフローが起動する場合は要注意!
フローがもたらす結果についても確認しましょう!
これらは、構造の大枠を捉えるために行います。
①は単体テスト仕様書の前提、②はテスト手順、③は想定結果に繋がってきます。
いきなり詳細を調べるのではなく、まずは全体感を把握しましょう。
以上を踏まえたうえで、例に当てはめてみると…
①どのようなときにプロセスビルダーが起動するか(起動条件)
→「成績点数」というカスタムオブジェクトのレコードが作成または編集されたとき
②動作条件が何個あるか、また、その動作条件に数式が含まれているか
→動作条件数は3個、数式は含まれていない
③「ルール適用時のアクション」はどのような動作になっているか
→レコードが更新される(3パターン)
となります。
ディシジョンテーブルと単体テスト仕様書の作成
次にディシジョンテーブル作成していきます。ExcelでもGoogleスプレッドシートでも大丈夫です。
表は、「条件」と「動作」に分けます。
条件は「起動条件」と「動作条件」に分けて記載をしましょう。
起動条件:作成したときのみか、作成および更新したときか(今回は作成および更新なので2パターン)
動作条件:②で確認した内容(今回は3パターン)
起動条件と動作条件は、下記の通りD列に記載してください。
動作条件についてはさらにどのような入力が行われるのかを確認しましょう。
必須項目でない場合、空白のときにプロセスビルダーが起動しないかをチェックすることが必要です。今回の場合は、必須項目の設定ではないので、動作条件にもう1パターン(空白の場合)を追加します。
同様にして、動作のD列も埋めていきます。
以上で表の準備は終わりです!
次に、パターンを作成していきます。作成するパターンは2種類です。
①OKパターン:プロセスビルダー(フロー)が起動する場合
②NGパターン:プロセスビルダー(フロー)が起動しない場合
条件を整えて、プロセスビルダーが正常に起動するかどうかも大切ですが、条件が異なるのに起動してしまうのも良くありません。そのため、NGパターンもしっかりと考慮しましょう。
また、NGパターンはどの条件が原因でプロセスビルダーが起動しないのかを一目で分かるようにセルに色をつけておくと抜け漏れを防ぐことができます。
次に条件と動作に「〇」を入れていきます。
具体的には、「新規作成」かつ「総合点が80点以上の場合」という条件で起動させたいときは「新規」と「80点以上」に〇をつけ、想定される動作(成績評価がA)に〇をつけます。以上のことを各条件で行っていくと、今回のディシジョンテーブルは、以下のとおりになります。
OKパターンが6個、NGパターンが2個となりました。今回の例では、空白のときに動作する条件がないため、空白にした場合はプロセスビルダーは起動しません。そのため、総合点が空白のときがNGパターンとなっています。
以上のようにディシジョンテーブルを作成することで、抜け漏れのないテストケースを洗い出すことができます。ここまで終わったら、ディシジョンテーブルを基に単体テスト仕様書を作成します。
以上のように前提・テスト手順・想定結果を記入します。単体テスト仕様書を書く際のポイントは、「自分以外の誰でも読めば単体テストが実施できる」ぐらい詳しく書くことです。マニュアルを作成するように詳しく、分かりやすく記載しましょう!
フロー移行と単体テストの実施
単体テスト仕様書ができたところで、いよいよプロセスビルダーをフローに移行します。フローへの移行手順はこちらの記事をご覧ください!
https://www.sunbridge.com/blog/column/flow-migration-steps/
無事にフロー移行はできましたか?それでは、正しく移行できているかを確認していきましょう。手順は以下のとおりです。
①[Flow Builderでテスト]をクリックし、Flow Builderに飛ぶ
②移行したフローの順番が、移行前のプロセスビルダーの条件の順番と変わっていないかを確認
もし、異なっていた場合はこの時点で移行前と同じ順番になるように修正しましょう。
③単体テスト仕様書通りに単体テストを実施し、動作を確認
③の単体テストですべてのテストケースが想定結果通りであれば検証終了です!お疲れさまでした!
もし、想定結果と異なるテストケースがあった場合はさらなる確認が必要です。
考えられることとして、今回は3つ挙げます。
①フローの条件、動作が正しく移行できていない
フローの条件・動作の内容とプロセスビルダーを見比べてみてください。
②テストケースが間違っている
とくに、条件が数式になっている場合など、条件の読み解きミスや動作の読み解きミスによって想定結果と異なってしまっている可能性があります。正しく読み解けているか、再度確認しましょう。
③そもそも移行前から正しく動いていなかった
とくに、動作が「フローの起動」の場合は、フローの名前が変わっていてフローが起動していないなどの場合があるので注意してください。
以上で、フロー移行後の単体テストは終了です。お疲れ様でした!
要点まとめ
ここでフロー移行後の単体テストの流れをおさらいしましょう。
①ワークフロールール/プロセスビルダーの構造を確認する
②ディシジョンテーブルを作成する
③単体テスト仕様書を作成する
④フローを移行する
⑤単体テストを実施する
この手順で行えば、抜け漏れのない単体テストを実施することができます。ぜひ、実践してみてください。
最後に
いかがだったでしょうか。
正しくフローに移行できていないと間違った処理や業務上のミスに繋がってしまうため、確実に動作検証を行うことが大切です。ワークフロールール/プロセスビルダー廃止まで猶予があるうちにフローに移行し、正しく動作できているかをSandboxで確認しましょう!
サンブリッジではフローの設定トレーニングやフロー移行のサポート、移行後の動作検証も行っております。
「兼務でフロー移行に手が回らない」「動作検証が正しくできているか不安」「移行対象数が多く対応できるか不安」という方はお気軽にお問い合わせください。
本記事が皆様の運用の参考になれば幸いです。
〜はじめてSalesoforceを操作する方も安心〜
Salesforceシステム管理者トレーニング

システム管理者の不安を解消するお手伝いをいたします!
Salesforceシステム管理者向けトレーニングでは、レベル別にトレーニングを設定しているのでご自身のレベルに合ったトレーニングを選択し受講いただくことができます。
トレーニングで利用するサンプルマニュアルもご提供しています。リンクよりトレーニングの内容をご確認ください!