前置き~これまでのフローのアップデートを体験する~
今日からお休みなのでこの機会を利用してこれまでに著しい発展をしてきたフロービルダーを利用してフローを作りたいと思います。
せっかくなのでSpring'21のプレ組織を手に入れてこれまでのフローの更新と新しいバージョンのフローを含めて体験しようと思います。お休みも結構長いので可能なかぎりこれまでに更新されたフローを体験して記事にまとめようと思っています。
業務だと作成する機会がないので非常に楽しみです。
前準備 プレ組織を入手する
上記からプレ組織を取得できますので必要な情報を入力してEditionはDeveloperを選びます。
他のEditionだと期限があって途中で使えなくなりますので注意が必要です。
設定 >= プロセスの自動化 => フロー より新規フローを作成します。
今回は「レコードトリガーフロー」の作成を行います。
作成するレコードトリガフロー
今回はケースオブジェクトを使って新規作成時にケースのWeb氏名とWebメールを入力していきたいと思います。
ケースの名前とメールが入力されていなければ取引先責任者の氏名とメールをそのままケースの名前とメールに入力していきます。
全体像
以下のようになります。
またベータ版ですが、自動レイアウトの場合は以下のようになります。
自動レイアウトであれば要素間のつなぎ合わせで歪んだ線に頭を悩ますこともなく表示してくれます。
また各要素をクリックすると編集することができます。追加する際も（＋）をクリックして追加したい要素を選ぶだけなので最初はわかりやすく作れると思います。
開始 レコードトリガフロー
フローをトリガする条件は「レコードが作成された」、フローを実行は「レコードが保存される前」にラジオボタンを合わせます。
また今回は特にケースのレコードの取得条件をつけません。
標準のワークフローやプロセスビルダーと違いフロー特有の選択肢は「レコードが更新された」、「レコードが削除された」、「レコードが保存される前」かと思います。
レコードが更新されたものだけを変更しようとしたときはワークフローやプロセスビルダーは数式でNOT（ISNEW())としないと出来なかったことがクリックだけで出来るようになったのはとても便利です。
さらに驚いたのが「レコードが削除された」場合もレコードトリガフローを使えるようになり、Apexのトリガと遜色ないほど拡張性が上がってきました。
決定 メールアドレス入力判定
結果を実行する条件の要求：すべての条件に一致（AND）
リソース：{!＄Record.ContactId} 演算子：null 値：{!＄GlobalConstant.False}
ANDリソース：{!＄Record.SuppliedEmail} 演算子：null 値：{!＄GlobalConstant.True}
ANDリソース：{!＄Record.Contact.Email} 演算子：null 値：{!＄GlobalConstant.False}
条件はシンプルな条件ですが、一つ注意を上げるとすると取引先責任者のメールを参照する前に、そもそも取引先責任者に値があるかどうかを確認しなければなりません。
これを怠ると、取引先責任者の値がないにもかかわらず、取引先責任者のメールアドレスを探そうとしてエラーが起こってしまいます。
あと取引先責任者の値があったとしても取引先責任者にメールアドレスがない場合はコピーする元がないので、それも条件に含めます（3行目条件）。
画像と比べると値が異なっているように見えますが、表示するときはプロセスビルダーと同じような形で表示を変えてくれたようです。編集する際は上記のような形に変わります。
1年前のフローと比べるととても直観的になっていてわかりやすいです。また参照関係にある値をプロセスビルダー同様に参照できるようになって便利になっています。またリソースのデータ型がわかるようにデータ型の画像も付け加えられています。
今回は使用していませんが、地味ながら重要な「結果を実行する条件の要件」でAND以外に「OR」「カスタム条件ロジック」もあります。当初のフローは確か「AND」条件しかなかったように記憶しています。
割り当て Webメール割り当て
変数：{!＄Record.SuppliedEmail} 演算子：次の文字列と一致する 値：{!＄Record.Contact.Email}
これで取引先責任者のメールをケースのメールに値を設定します。
決定 Web氏名入力判定
結果を実行する条件の要求：すべての条件に一致（AND）
リソース：{!＄Record.ContactId} 演算子：null 値：{!＄GlobalConstant.False}
ANDリソース：{!＄Record.SuppliedName} 演算子：null 値：{!＄GlobalConstant.True}
ANDリソース：{!＄Record.Contact.LastName} 演算子：null 値：{!＄GlobalConstant.False}
割り当て Web氏名割り当て
変数：{!＄Record.SuppliedName} 演算子：次の文字列と一致する 値：{!Name}
値のNameは数式で次の形で作成しています。
データ型：テキスト 数式：{!＄Record.Contact.LastName}+ ' ' + {!＄Record.Contact.FirstName}
エラーが起こった時
久々のフロー作成というのもあり、意図せずエラーを起こしてしまいました。
取引先責任者の名前だからNameでよいかと思っていたんですが、ダメでした。
「Flow error～」のリンクをクリックするとブラウザが立ち上がり、どの部分で問題を起こしているかわかりやすく表示されていました。
この変更は直観的な把握ができるのでありがたい変更です。
バグ？
色々直しながら作成していましたので、バージョンを上げたり、下げたり、時には削除を繰り返しているとフロー名をクリックしたときに最新のバージョンが表示されていなかったり、起動しているフローが必ずしも新しいものではなかったりしていました。
明確に記録と取っているわけではないので、私の勘違いかもしれませんが・・・
原因究明に困ったので、別名のフローとして保存して試してみたらきちんと動いたので、バージョンの上げ下げや削除した際に問題が起こった時に解決できない場合は別名でフローを作り直すのもありかもしれません。
あとレコードトリガフロー（＄Record.）の場合、失敗しない場合でも簡単にデバッグできる仕組みがあればなお便利だと思います。現状だと実際にレコードを作って確認しないといけません。
おまけ
内容とは関係ないですが、Spring'21のリリースノートを読むとLightningフロー（プロセスビルダーとフローの総称）がSalesforceフローと名前が変わるようです。
現行のフローのことをLightningフローと言う方もいらっしゃる（アドビのフラッシュ時代のフローと明確に区別するためでしょう）ので、それとの混乱をさけるための名称変更でしょう。
https://help.salesforce.com/articleView?id=release-notes.rn_forcecom_flow.htm&type=5&release=230
これまでのアップデータされたフローを体験した感想。
全体的に想像以上に使い勝手が上がっていて、1年前のSpring'20の最初のフロービルダーと比べるとプロセスビルダー並みに直観的でユーザビリティに富んだものに変わっていたのでスムーズに作成ができたと思います。
Apexと遜色ないほどの仕上がりになりつつあるなという印象です。
フロービルダーを使ってフローを作成できるようになればこれまで以上にアドミンが活躍できる場ができると思います。簡単な自動化システム、画面入力システムでよいのであればフロービルダーですべてのシステムを組めるのではないかと思ってしまうほどです。
丁度タイミングがあったのでエントリーします！
「この記事はSalesforce 開発者向けブログ投稿キャンペーンへのエントリー記事です。」