【第2回】ワークフロー・プロセスビルダーからSalesforceフローへの移行の心得とは？

通常、何か新しいソフトウェアを開発する際、「プログラミング言語」を用いて「ルール」を守りながら「命令・実行文」を作成します。その中で、ノーコード・ローコード開発とは、その名の通り「コーディング」をする必要がない/少なくて済むことを意味します。そのため、「ロジック（コンピュータに処理をさせる順序や方法）」を設定する必要はありますが、プログラミング言語を学んだ経験のないユーザーでも、ソフトウェアを開発することができます。

※今回の記事はSalesforceに関する第2回目の記事です。前回の記事もぜひ参照してみてください。

2022年7月現在、Salesforce で実装できるノーコード・ローコード開発は以下【表1】になります。
今まで下記3つの何れかを利用し自動化を実現することができましたが、そのうち1つがWinter'23（2022年10月）、もう1つがSummer'23 リリース以降「新規作成」ができなくなります。

①→③に進むに連れて「実現できること」も「実装難度」も高まっていくとお考えください。
つまり、プログラミング経験がなくてもカスタマイズしやすかった①,②が廃止になり、よりアルゴリズムの理解が必要な③を利用しなければ、新規のカスタマイズができなくなります。

既に実装済の①,②で「新規作成」ができなくても「既存モジュールは継続利用可能」であれば、「実装済の①,②を残し今後のことだけを考えればよい、どうにかなる」と思われる方もいらっしゃるかもしれません。しかし、現場の要望により、項目やロジックを追加したいケースが発生することは容易に想像がつきますよね？

弊社では、①,②,③を組み合わせて自動化を実現していましたが、①,②,③のそれぞれが干渉しあう事象も発生し、拡張性に限界を感じていました。そのため廃止の発表を受け、いち早く2021年末から①,②の③への「フロー化」対応を開始し、主要な機能について改修を終えました。

今回は、そのように紆余曲折しながら手に入れたノウハウである「完全フロー化の心得」を4つご紹介します。

初めに「レコード」について簡単に説明します。Salesforceの「オブジェクト」はデータを格納する「箱」であると、前回の記事で説明しました。一方で「レコード」はその「オブジェクト」に登録された具体的な情報のことを指します。例えば、「取引先オブジェクト」に「取引先A」「取引先B」の2件のレコードがあるといった表現ができます。

今回紹介するレコードトリガーフローとは、レコードを作成、更新、削除された時に起動するフローのことを指します。レコードトリガーフローは、「保存前処理」と「保存後処理」のいずれかを選ぶことができます。どちらが適しているかよく考えた上で、フロー化対応を行ないましょう。

「レコードの作成または更新」により自動起動フローをトリガし、追加の更新をレコードに加えてからレコードをデータベースに保存します。各種処理をスキップすることにより、レコード変更プロセスよりも 10 倍速く Salesforce レコードを更新することができます。ただし、利用できる機能は制限されており、フローを起動するレコード更新以外のアクションを実行することはできません。

「レコード保存後」に他のレコードにアクセスしたり、アクションを実行、サブフローを起動することができます。また、プロセスビルダーで作成したワークフロールールや、レコード変更プロセスの大部分を置き換えたり、ループを実行することができます。

【表2】で「保存前処理」と「保存後処理」の差異をまとめました。
背景色が黄色の部分に関しては、「保存前処理」と「保存後処理」で差異がある要素を指しています。

1)「フローに移行ツール」の利用について
Spring'22（2022年2月）でリリースされた「フローに移行ツール」を利用して、当該オブジェクトの項目の更新のみを行なっている「ワークフロー」を変換した場合は、自動で「保存前更新」フローに変換されます。

本ツールで大抵の「ワークフロールール」を「フロー」に一括変換できますが、一部対応していないものもありますのでご注意ください。
※2022年7月現在、ワークフロー条件がグローバル変数及びレコードタイプを利用しているものや、ToDoを作成、所有者項目の更新、クロスオブジェクト更新には未対応です。詳細は下記Helpサイトをご参照ください。

また「プロセルビルダー」移行ツールは、Winter'23（2022年10月）案内予定とのことです。待ち遠しいですね。
↓
「プロセルビルダー」移行ツールは、Spring'23（2023年2月）にリリースされました。ワークフロールール同様、一部対応していないものもありますのでご注意ください。
※2023年2月現在、移行サポートされているアクションはレコードの更新、レコード作成、フローの呼び出し、Apexの呼び出し、メールアラートになります。

2)最終更新日項目や新規で採番しているレコードの ID など、
　レコードの保存後に設定される項目値へのアクセス（※1）の具体例
・保存前更新：商談コピー時に、商談の項目を初期化したい場合
・保存後更新：請求番号を「年月-連番（自動採番）」の形式に変更したい場合

3)レコードトリガーフローで利用できる、便利なグローバル変数
　$Record（レコード更新直後の値）と $Record__Prior（レコード更新直前の値） について
・「保存前処理」フロー後に「保存後処理」フローが実行される場合、
　「保存前処理」フローで更新された値は 「保存後処理」フローの$Recordに反映されます。
・「保存後処理」フロー内で同じオブジェクトに対して複数回更新を行うと$Recordの値は変わります。
・「保存後処理」フロー内で同じオブジェクトに対して複数回更新を行っても$Record__Priorの値は
　　変わりません。

各処理で$Recordと$Record__Priorのどちらを利用すればよいかご理解いただけるのではないでしょうか？

Spring'22（2022年2月）のバージョンアップで「レコードトリガーフローの実行順序」を定義できるようになりました。実行順序を決定することで、過度に複雑なフローを作成せず一貫性の高い結果を得ることができ、処理を分割することができます。また、プロセスビルダーのように「レコードを再評価」することはなく、処理は1回となります。

注意点としては下記2点があげられます。
①実行順序のルールは下記【表3】になります。1,000 番以前と以降で処理が変わります。
②フローの順序を有効・無効化または変更すると、他のフローの順序が自動的に更新される可能性があります。

SalesforceのHelpサイトでは多数のフローを並び替える場合、10、20、30のようにトリガ順序値を均等に分けることをお勧めしています。後で別のフローをその間 (10 と 20 の間など) に簡単に差し込むことができ、この方法を使用すれば、既存のフローのトリガ順序値を変更せずに済みます。

【表4】並びに続く【図1】～【図3】は実行順序を指定可能な導線を表しています。

【図1】①フロー一覧、【図2】②オブジェクトマネージャからアクセスすると、
ドラッグ＆ドロップで処理順序を一括で変更することができるので設定しやすいです。

※弊社で実装していた時にはこの機能がリリースされていなかった為、実際には利用しておりませんが、実行順序を指定できるのはありがたいですよね。今後活用します。

その為、次の3.データ更新の回数に特に配慮して実装を進めました。

同じオブジェクトに対して「ワークフロー」や「プロセスビルダー」で更新を行い、自動化を実現していたケースもあるかと思います。それぞれ一つずつ「フロー化」するだけであれば比較的容易ですが、処理内容によっては「ガバナ制限」に達し、処理を完了することができないケースも発生します。そのため、分岐や割り当て、変数（数式）を活用し、できる限り複数の「ワークフロー」「プロセスビルダー」を一つの更新処理にまとめることをお勧めします。

商談オブジェクトへの更新事例を【図4】～【図6】を用いて紹介します。

1)複数のワークフローやプロセスビルダーで実行していた処理をまとめる
【図4】赤枠 ①のように、新規・更新・フェーズが契約合意になった場合に、それぞれ項目の割り当てを行い、商談へのレコード更新処理を「1回」に留めています。それぞれ「レコード更新」要素を用いて実装すると、それだけでSQLを「3回」発行することになり、前述したフローへ移行時の補足事項の通り、 {$Record}の値も変わっていきデバッグしづらくなります。更新回数を少なくすることでどの割り当て処理で躓いているのかも把握しやすくなりお勧めします。

2)決定を活用して処理を分岐させつつ、レコード更新回数を1回に
また、新しい価格表を7月から有効とし、過去の価格表を指定した商談商品の新規作成を停止したい場合は、
入力規則で「商談の作成日付が7月以降、かつ、過去の価格表での商談商品作成はエラー」としつつ、
商談コピー時の配慮として、【図4】赤枠 ①「新規？」の分岐でTrueとなった場合に、割り当て「新規項目セット」処理を通るようにしました。
割り当て「新規項目セット」の中で【図5】数式を編集の変数を用いて、過去の価格表IDであれば価格表IDをNullに更新し、商談商品を削除するするようにしました。（Salesforceの標準機能として、価格表IDがNullになると商談商品が自動で削除されますので、そちらを活用しています。）
このように「決定」でおおまかな処理を分割し、内容を把握できるようにしつつ、該当した場合のみ「レコードを更新」を通るようにしています。

3)レコードトリガーフロー内で「新規か更新か」の判断
【図4】赤枠 ①「新規？」の決定要素で切り分けている「新規か更新か」といった条件は、
【図6】のようにグローバル変数の{$Record__Prior.Id} を利用し、Null Trueであれば新規、Null Falseであれば更新として判断することができます。

1つのフローで全てを展開しようとすると、1画面に収まらずソースコードが解読しづらくなります。そのため、当該オブジェクトへの更新はフロー内、別オブジェクトへの更新はサブフローへと使い分けることで1つのフローをシンプルにしました。また、サブフローの利点として、複数のフローから呼び出すことができることもあげられます。事例の【図4】青枠 ②～④が該当し、商談以外のオブジェクトへの更新処理はすべてサブフローとしています。

1)サブフローでの連続処理の注意点
今までの自動化ツールですと「ワークフロー→プロセスビルダー→フロー」順に処理されて、気にかける必要がなかったのですが、サブフローを活用し1つのフローにまとめたことで、処理スピードが追いつかないという現象も発生しました。つまり、【図4】③の処理後に【図4】④の処理を起動し、③の処理で更新した値を④で使用する想定でしたが、まだ値が更新されていない状態で④が起動されてしまったのです。上記は④以降のフロー内で「レコード更新から1分経過後」に本処理を開始することで回避しました。

弊社では対応時期が早かったため「移行サポートツールがない」「フローの順序指定機能がない」状態で「フロー化」を開始しました。結果、新規開発を行ないやすくなりましたが、何度も躓きましたし、リリースニュースを見る度に少し早まったか？と感じることもありました。そのような中、Salesforceのサポートの方やユーザコミュニティ上で質問させていただいた方へ、この場を借りて感謝の意を申し上げます。

本記事を通して、皆様の課題解決の足がかりとなりましたら幸いです。

※2022年8月3日、2022年12月21日、2023年2月21日
　Salesforceのリリーススケジュール変更に伴い、【表1】Salesforce で実装できるノーコード・ローコード開発の情報を更新しました。

※2023年2月21日
　Salesforceのリリースに伴いフローへ移行時の補足事項を編集、Helpサイトの拡充に伴い 5.参考サイトを追加しました。

※本記事は、執筆当時の製品リリース情報を元に作成しています。
　製品・機能の追加、更新により情報が古いままになっている可能性もありますので、必ず最新情報をご確認ください。

当メディア「マナミナ」を運営する株式会社ヴァリューズでは自社データの分析・活用支援も行っております。興味をお持ちの方はぜひ下記よりお問い合わせください。