salesforceフローは楽しいぞ
この記事は、エモーションテック2022アドベントカレンダーの21日目の記事です。
こんにちは！エモーションテックのなんでも屋、のてです！
私は普段エモーションテックのチームを横断する業務フローやルールの整備をしているのですが、その一環で弊社で利用しているSalesforce（Sales Cloud）のシステム管理者を担当しています。
使ったことがある方はわかると思いますが、Sales Cloudはカスタマイズ性がとても高く、やりたいな〜と思ったことは大体できちゃいます。
一方で、カスタマイズ性が高いが故に運用がごちゃごちゃになりやすかったり、項目が増え過ぎたせいで本当に入力して欲しい情報が入力されない・・・なんていう悩みもよく聞きます。
（弊社もそんな時代がありましたが、今はそこそこいい感じに運用できていると思い・・・ます！）
そんな時に強い味方になってくれるのが、「フロー」です！！！！！！
（以降、読者の皆さんがSales Cloudの基本的なワードを知っている前提で進みます）
フローってなんぞ？
フローは、ざっくりいうと「ノーコードでプロセス処理を作成できる機能」です。
例えば、「商談を受注したら、一部の情報を引き継いだ更新用の商談が自動で作られたらいいのにな〜」というのもフローで実装可能です。
実際に設定してみました。
「レコードトリガーフロー」と書いてあるところには、「どういう条件でこのフローを開始するか」を指定します。
今回は「商談が受注した時」という条件を設定しています。
そして、次の「更新商談を作成」というところには、「どんな情報を保持した商談を作成するか？」という内容を設定します。
下の例では、
取引先を元の商談と同じものにする
受注予定日を元の商談の契約終了日にする
商談名を指定する
という設定を行っています。
商談名は、更新商談であることがわかりやすいように、頭に「更新商談_」と付くように設定しています。
とっても簡単ですね！！！
エモーションテックでは、Sales Cloud上のさまざまな処理をフローで設定しています。
今回は、その中のひとつである「検収処理未完了の案件の通知」について解説したいと思います！
皆さんも月末月初には特に契約や請求の処理に追われるかと思いますが、エモーションテックもご多分に洩れず対応しなければならないことが色々あります。
例えば、成果物が問題なく納品されたことをお客様に証明いただくために「検収」をお願いすることがあります。
この検収の依頼漏れや完了したことの確認漏れ防止のために、毎月月末近くに自動で通知が来るように設定しています。
実際のフローでの設定がこちらです。
上から解説していきます。
まず、この通知は毎月定期で配信したいものなので、「スケジュール」をトリガーとして発火させます。
ただし、デフォルトでは「1回のみ、毎日、毎週」という超ざっくりとした頻度でしか設定できないので、とりあえず毎日発火させてその後の条件分岐で実際のアクションをするかしないかを判定させることにしています。
また、それ以降のアクションでは商談商品を軸にアクションを設定していくので、オブジェクトは「商談商品」を設定します。
続いて、「実際にその後のアクション（今回だと通知）をするかしないか？」の条件分岐を設定しています。
弊社では月末最終営業日の2日前と月末最終営業日に通知するようにしています。
例えば「月末最終営業日の2日前」を判定するには、下記の数式で算出された日付と今日の日付が一致するかどうかを判定しています。
こちらの数式では、まず1900年1月7日が日曜日であったという情報をもとに、日曜日から土曜日を0〜6の数字に当てはめています。
そこから、今月の「最終日」が日、月、火曜日だったら4日前の日付を、土曜日の場合は3日前の日付を、それ以外の場合は2日前の日付を返します。
また、12月は年末年始があり、弊社は大体最終営業日が28日なので、今月が12月の場合は28日を最終日とするようにしています。
返された日付と今日が合致したら、次のステップに進みます。
ここでは、記載の通り「今月検収対象で未検収の商談商品」のレコードを取得しています。
弊社では、検収対象の商談商品ごとにステータス管理をしており、「検収済み」のステータスに至っていない商品をここで検索し、対象のレコード全てを一旦保存します。
最後に、対象のレコードをひとつひとつ処理していきます。
「ループ」という要素を利用し、先に保存した「今月検収対象かつ未検収の商談商品」のレコードひとつひとつに対して、以降のステップを繰り返します。
まず、念の為ここでそのレコードの「親となる商談がちゃんと受注済みか？」を判定します。
この判定を入れないと、例えば「元々は今月納品を予定してて提案してた商談の受注が先延ばしになってしまったが、うっかり商談商品の納品予定日の修正を忘れてしまった」みたいなレコードまで通知の対象になってしまうので、入念にチェックします。
そして、ここでチェックを通過したものが晴れて通知の対象となります！
弊社では、事前にApexで設定したslack通知アクションを使って通知を飛ばしています。
（Apexについては今回は割愛・・・こちらはガッツリYes!コードなので・・・）
もちろんApexアクションを使わず、メールに通知することも可能です。
設定しているApexアクションでは、
・slackのチャンネル名
・配信するテキストメッセージ
・配信時のBotの名前
・配信時のBotのアイコン
が指定できます。
配信するテキストメッセージでは、工夫次第では案件の担当者に直接メンションを飛ばしたり、該当の商談商品へのリンクを貼ったりと色々カスタマイズできます◎
ほら、ノーコードでこんなことができるの、楽しくないですか？？？？？
（一部明らかにコード書いてた？そうだっけ・・・（目線斜め上））
フローを学ぶ
元々は、レコードの更新や作成に関わる処理は「プロセスビルダー」という別の機能を使用していましたが、更新しづらかったりできることの範囲がフローより狭かったので、ある時から全てフローで実装するようになりました。
（一番初めのきっかけは、「商談の受注処理に必要な項目が点在してて複雑だから、モーダル表示してまとめられないかな」でした！今考えたら、セールスパスでも良さそうですねw）
まずはsandboxで「こういうことできないかな？」を手当たり次第実装してみてデバッグする、を繰り返します。
慣れてきて影響が少ないものなら、デバッグ時にロールバックするように設定し、いきなり本番で実装することもあります。笑
デバッグでエラーが表示されたり実装がうまくいかない時は、エラー文言を検索したりリファレンスを読んだりして、似たような事例がないか探します。
最近は、Trailblazer Communityで過去の質問を検索することも増えました。
また、個人的にはSalesforceのサクセスナビの演習問題も役立ちました！
ヘルプ記事よりもわかりやすくまとまっており、応用を効かせやすいと思います。
まとめ
Salesforceでもコードをかけた方ができることの幅はもっと広がりますが、まず基本を覚えることのハードルが高いと感じる方は多いと思います。
フローのようにわかりやすいUIで同じようなことができるなら、少しは心理的ハードルも下がるのではないでしょうか？
もしこれを見ている方が「うちでもSalesforce使ってるし、フローであの業務楽になるかな・・・？」と少しでも思っていただければ幸いです！