Salesforce Advent Calendar 2021の16日目の記事です。
Salesforceは毎年機能のアップデートが早くてキャッチアップが大変ですね。
リリースノートには目を通しているものの、都度、実際に動作確認までしている人は多くないのではないでしょうか。
特にフローの機能追加スピードは凄まじく、ほとんどApexなどでコードを書かなくてもほとんどの機能を実装することができるようになってきました。
本記事ではwinter'22で追加されたフローの簡単な機能紹介とそれをつかった実装を記載しています。
まだフローを触ったことがないけどそろそろ触ってみようと考えている、という人向けにフローを作るときのベストプラクティスがまとまった記事を載せておきます。
10 Salesforce Flow Best Practices
winter'22で追加されたフローの機能
詳細はリリースノートを確認いただければと思いますが、個人的に私がいいなと思った部分を列挙します。
- レコードトリガフローで、サブフローが使えるようになった
- レコードトリガーフローで非同期パスが使えるようになった
- スケジュール済みパスおよび非同期で実行されるパスをデバッグできるようになった。
- レコードトリガーフローで送信メッセージを送信できるようになった
- フローが失敗した際にレコード変更をロールバックできるようになった
ローコードとはいえ、もうほとんどフローでできないことがなくなってきています。
複雑な処理を作り込まないと行けない場合はApexを使ったほうがいいと思いますが、部分的に処理をApexで記載し、フローから参照する、という方法も検討しておく必要があると思います。
非同期実行とサブフローで項目変更履歴機能を作ってみる
ようやく本題に入ります。本記事では、レコードトリガーフローのサブフローを非同期パスを利用して、項目変更履歴をコーディングなしで作っていきます。
項目変更履歴とはいつだれがどの項目を更新したかを記録する監査的な役割の機能になります。標準やアドオンライセンスでもこちらの機能はありますが、要件によっては標準だと機能が足りなかったり、アドオンライセンスの予算がなく、渋々カスタマイズで対応することもあると思います。
いままではカスタマイズ対応する場合、データ量などを考慮してBigObjectに項目変更履歴のレコードを保存しようとすると非同期処理で実装する必要があったので、必然的にApexで処理を実装する必要がありました。
しかし、今回のアップデートでレコードトリガーフローで非同期処理を実装することができるようになったのでレコードトリガーフローからBigObjectにもレコードを保存する処理を作成できるようになりました。
これでレコード量、保存期間、追跡可能項目数を気にすることなく項目変更履歴の機能をフローで実装することができます。
処理概要
今回作成する処理の概要をまとめると以下の図になります。今回は取引先に処理を実装し、検証を行います。
取引先の変更情報から直接BigObjectにレコードを作成せず、一度カスタムオブジェクトにレコードを作成してから転送しているのは、すべてを非同期処理にすると変更前の項目値を取得できず、すべてを同期処理にするとBigObjectにレコードを登録できなくなるので、非同期処理と動機処理でトリガーフローを分ける必要があったからになります。
この構成は項目変更履歴の実装に限らず、変更前のレコード値の処理と外部サービスとの連携が必要な機能の場合には利用できる構成になります。
具体的な処理内容を解説していきます。
項目変更履歴を一時保存するカスタムオブジェクトを作成
以下のようにカスタムオブジェクトを作成します。Name項目をRecordIdという設定で作成しています。
項目変更履歴を保存するBigObjectを作成
以下のようにBigObjectを作成します。
ポイントとしては関連リストとして表示するためにレコードを紐付けるための「RecordId」と、「更新日時」、「項目名」の3項目でペアとなるIndexを作成することです。
また、Indexの合計文字数は100文字ということを考慮して、「項目名」は60文字を最大文字数として設定しています。
※BigObjectは一度作成すると定義を変更できないので、どうしても定義を修正する必要がある場合は一度削除してから再作成する必要があります。
項目変更履歴を一時保存するサブフロー作成
以下のように自動起動フローでサブフローを作成します。
以下の図では取引先の取引先名が変更された場合に項目変更履歴を作成するように処理を記載していますが、
「取引先名の変更有無」、「変更履歴作成取引先」、「変更履歴追加取引先」を各項目分用意すれば複数の項目で準備することができます。
サブフローとして呼び出される際の入力値としてoldAccountとnewAccountを用意します。
入力値のoldAccountとnewAccountの取引先名を比較して一致するかどうかを判定します。
一致しなかった場合は用意した「項目変更履歴を一時保存するカスタムオブジェクト」のレコード変数に各種値をセットする処理を作成します。
その後、複数の項目値変更が発生していても一括で変更履歴を作成するために、「項目変更履歴を一時保存するカスタムオブジェクト」のリストに先程のレコード変数を追加する処理を作成します。
追跡項目が変更されていない場合はフローが終了できるように決定要素を作成します
「項目変更履歴を一時保存するカスタムオブジェクト」に項目変更履歴内容を作成します
項目変更履歴をBigObjectに保存するサブフロー作成
以下のように自動起動フローでサブフローを作成します。全体の流れとしては、まず「項目変更履歴を一時保存しているカスタムオブジェクト」からレコードを取得し、レコードが存在していればBigObject用のレコード変数に変換して登録を行います。
そしてその後、「項目変更履歴を一時保存しているカスタムオブジェクト」上のレコードは不要になるので削除します。
レコードトリガーフローでサブフローと非同期パスの設定
上記で作成したサブフローを呼び出すレコードトリガーフローを作成します。
次のように即時実行で「項目変更履歴を一時保存するサブフロー」を呼び出し、非同期に実行で「項目変更履歴をBigObjectに保存するサブフロー」を呼び出すように設定します。このようにそれぞれサブフローで処理を整理しておくことでメンテナンス性が高くなります。
こちらのフローの開始条件設定は以下のようになります。
「トリガレコードの元のトランザクションが正常にコミットされた後に外部システムにアクセスするには、非同期に実行パスを含めます。」にチェックを入れることで非同期実行が可能になります。
即時実行で設定する「項目変更履歴を一時保存するサブフロー」では入力値に以下のように設定し、変更前のレコード情報と変更後のレコード情報をサブフローに渡すようにします。
BigObjectを関連リストで表示するパッケージをAppExchangeからインストール
こちらからインストールすることができます。
BigObjectを関連リストで表示するパッケージをページレイアウトに追加
レコード詳細ページのレイアウトにタブを追加し、そこにカスタムコンポーネント「Big Object Related List」を選択してドラッグアンドドロップで配置します。
各パラメータの設定は以下の通りです。
| パラメータ | 値 |
|---|---|
| Big Object API Name | ColumnsChangeHistory__b |
| Lookup field API Name | RecordId__c |
| Fields to display for each record | ColumnName_c,OldValuec,NewValuec, UpdatedDateTimec, User_c |
| Number of records options | 100,200,300,400,500 |
| Display mode(large screens) | Table |
| Display mode(medium screens) | Table |
| Display mode(small screens) | Tiles |
動作確認
それでは実際に動作するか確認してみます。
ちょうど「株式会社セールスフォース・ドットコム」社が「株式会社セールスフォース・ジャパン」に社名変更するとのことなので、変更してみます。編集画面で普通に編集します。
その後、項目変更履歴のタブで確認するとBigObjectのレコードとして項目変更履歴が作成されていることが確認できます。
まとめ
Apexも書ける人であれば、わざわざフローで実装、とはなかなかならないかもしれませんが、エンジニアでない人でもあらゆる処理の実装が可能なのでフローの需要は高いんじゃないでしょうか。機能もどんどん拡張されていくので、今後はApexよりフローを優先して設計を行っていったほうがいいのかもしれないと考えています。
現状ではSalesforceベンダーに開発を依頼しているユーザ企業も多いと思いますが、フローでSalesforce開発が内製化できる企業が増えていくといいなと考えてます。