※この記事は2021年1月22日時点でのお話です。
皆さん、カスタム通知は使っていますか？
今まで通知といえば、
- 通知メールを送る
- Chatterにメンションを張ってポスト
- Todoを作成し割り当て
などなどいくつかの方法があったのですが、Summer'19よりカスタム通知が実装されたことにより、ダイレクトに通知アイコンに通知を届けられるようになりました。
またスマホアプリにも対応しており、念願だった「スマホに直接通知を送る」が実現可能となったのです。
とは言え、今まで特に取り扱うような案件がなかったのですが、今回カスタム通知に触れる機会がありまして、せっかくなのでフローの使い方を交えてブログに記しておこうと思います。
カスタム通知の基本設定やプロセスビルダーを使った詳しい設定の仕方などについては、株式会社テラスカイさんのTerraSkyBaseにとても分かりやすく掲載されておりましたので、そちらをご紹介いたします。
「カスタム通知」でPC/モバイルに通知を出し分けてみた
要件を整理してみる
さてさて、ある日社内からこんな要望が上がりました。（という設定にします）
お客様から制作の依頼が入ったら自動的に担当者へ通知が届くようにして欲しいんだよね。あと、依頼があった日から3日経っても制作予定日が入力されていなかったら、それを上司と担当者に通知を出して欲しい。
ほうほう、なるほど。
つまり次のような要件です。
- 依頼日が入力されたら担当者に通知
- 依頼日から3日後までに制作予定日が入力されていなかったら上司と担当者に通知
これを実現させるために、まずはプロセスビルダーでできるかどうかを検討しました。
- 依頼日から3日後
このように時間ベースで動作させたい項目があるため、プロセスビルダーの「スケジュール済みアクション」を使うことでどうかと思ったのですが、「スケジュール済みアクション」は「レコードを作成したときのみ」に設定した場合にしか使えません。
今回は制作予定日というレコード作成後に編集して更新される項目があるため、プロセスビルダー単体で完結するのは厳しそうなので、フローも併用することにしました。
なんとなく動作イメージはこんな感じに。
- 依頼日が入力されたらプロセスビルダーからフローを起動
- フローを使ってカスタム通知を送信
- みんなハッピー
では、めっちゃ長文だけどいってみよー。
フローの作成
初期設定
今回はプロセスビルダーから呼び出されるフローを作成したいので、「自動起動フロー（トリガなし）」で作成を進めていきます。
まずはプロセスビルダーから呼び出された際に、プロセスビルダーを起動させた商談のIDを一緒に受け取りたいので、それを入れておく変数を作成。
通知は複数人に送るタイミングがあるので、通知を受け取る人のIDを格納するための変数もついでに作成しておきます。
| 変数名 | データ型 | 説明 |
|---|---|---|
| oppPage_Id | テキスト変数 | プロセスビルダーから商談IDを受け取り格納 |
| sendMembers | テキストコレクション変数 | 複数の通知ユーザのIDを格納 |
フローから見て、プロセスビルダーから送られてくる商談IDは「外部から入ってくる情報」なので、oppPage_Idでは「入力で使用可能」にもチェックを入れておきます。 |
||
| ここ重要。 | ||
 |
このフローがプロセスビルダーから呼び出されたということは、つまり商談レコードの依頼日が入力されたということになるので、
- 依頼日が入力されたら担当者に通知
早速カスタム通知を送るタイミング到来です。まずは担当さんのIDを設定します。
担当者IDの取得と割り当て
このタイミングで通知を送るのは「制作担当者」なので、要素から「レコードを取得」を選択し、まずはユーザオブジェクトから担当さんのIDを取得しにいきます。
制作担当者ID取得の設定画像
次に要素から「割り当て」を選択し、予め作成しておいたsendMembers変数へ取得した制作担当者のIDを追加します。
担当者ID割り当ての設定画像
カスタム通知種別IDの取得
準備ができたので、いよいよカスタム通知の設定を行っていきます。
・・・と言いたいところなのですが、
実はフローでカスタム通知を行う場合、プロセスビルダーで使う場合と違い、__カスタム通知種別ID__という項目が必要になります。
この項目は、Salesforce[設定]にある[カスタム通知]などには表示されていないんですね。
なので要素「レコードを取得」を使って、カスタム通知のIDを取得してくる必要があります。
Salesforceヘルプより抜粋
通知種別 ID をフローから直接照会するには、[レコードを取得] 要素をフローに追加して、API 参照名で絞り込みます。
Salesforceヘルプ「カスタム通知の他の送信方法」
ヘルプにはこのように書いてあるのですが、実際にはAPI参照名という項目にはなっていないのでご注意を。項目DeveloperNameを選択し、Salesforce[設定] > [カスタム通知]で付けたAPI参照名と照合することで取得できます。
カスタム通知ID取得の設定画像
カスタム通知の設定
さて、やっと肝心の通知設定です。
要素から「アクション」を選択し、
サイドメニューから「通知」を選択、アクションの入力フォームをクリックし「カスタム通知を送信」を選択します。
カスタム通知種別IDの項目では、先程設定した「レコードを取得」要素を選択し、その中にあるIdを指定します。
送信者IDには制作担当者のIDが格納されているsendMembersを指定し、準備OK。
あとは通知のタイトルと本文を設定しますが、これは直打ちで内容を書いてしまってもOKです。
もし商談項目など何らかの値を通知に表示したい場合は、必要な項目をレコード取得→割り当てで変数に格納し、それぞれテキストテンプレートの新規リソースとして埋め込んであげれば問題なく送信されます。カスタム通知用の文章はプレーンテキストにするのを忘れずに！
テキストテンプレートの参考画像
最後に、通知をクリックまたはタップした際に遷移させたい商談レコードのIDを、「対象ID」の項目に設定すれば完了です！今回は依頼日が入力された商談レコードに遷移させたいので、oppPage_Idを指定しました。
カスタム通知の設定画像
「一時停止」を使って一旦待機
さて、次の要件です。
- 依頼日から3日後までに制作予定日が入力されていなかったら上司と担当者に通知
こちらを言い換えると、「依頼日から3日間の猶予があるので、その間に制作予定日を入れておくように。3日後チェックするからね！もし入力してなかったら上司に報告するのでよろしく。」ということですね！
つまり3日間はフローは何もしなくて良いわけなので、時間がくるまで一時停止をしておこうと思います。
要素から「一時停止」を選択します。
「一時停止条件」タブでは特に条件などなく強制的に一時停止したいので、選択肢はそのまま「フローを常に一時停止 - 条件なし」に設定しておきます。
「イベントを再開」タブではフローが再び動き出す条件を設定します。
ここではダイレクトに日時指定か、オブジェクトに存在する実際の項目を起算日に設定できますが、データ型が「日付」か「日付/時間」の項目でないといけないので注意です。
今回は商談にある「依頼日」を起算日に設定します。
そして最後に【3日後】の部分を設定します。
「オフセット数」に待機しておきたい数値を入力します。
ちなみにここは負の数も入力可能なので「期日の3日前」としたいときは「-3」としておけばOK。
「オフセット単位」では時間が日数かを選べるので、今回は「Days」と入力します。
これで「商談項目の依頼日に設定してある日付から3日間フローはお休みします」という設定が完了です！
一時停止の再開設定画像
制作予定日が入力されているかどうかチェック
さてさて、3日後までにちゃんと制作予定日が入力されたでしょうか。
確認するためにまずは商談レコードから「制作予定日」の値を取得します。
制作予定日取得の設定画像
次に取得した「制作予定日」がきちんと入力されているかどうかの判定部分を作成していきます。判定方法は単純に「制作予定日がNullかそうでないか」で判断します。
いわゆるBoolean型の場合、結果をtrueかfalseで判定しますが、値に直接「true/false」と記述するのではなく、一覧から選ばないときちんと動作しない点に少し注意です。
入力判定の設定画像
上司のIDを取得
もしここできちんと制作予定日が入力されていたら、無事にフローの役目は終了となります。ですが入力されていなかった場合、担当さんとその上司に通知を出す必要があります。
制作担当者のIDはすでに最初の方で取得済なので、まだ取得していない上司のIDを取得しましょう。
今までの流れと同様に要素から「レコードを取得」で作成しても良いのですが、少しでも時短したいので、フローの一番初めに作成した「制作担当者のIDを取得」を開き、「要素をコピー」を選択します。
その状態で先ほど作成した「制作予定日の入力チェック」の分岐にある「未入力」のところで「コピーした要素を貼り付け」を選択します。
あとは貼り付けた要素を編集し、上司のIDを取得します。
同じ要領で制作担当者IDの割り当てをコピーし、上司IDの追加を作成していきます。
上司ID取得の設定画像
上司ID追加の設定画像
担当と上司へ通知
最後に担当さんとその上司へ通知を送信します。
これも最初の通知アクションをコピペで時短しましょう！
担当と上司への通知設定画像
一時停止から最後までのフローの流れはこんな感じに。
フローの動作はこれで完了です。閉じる前に有効化を押しておきましょう。
これを押しておかないとプロセスビルダーから呼び出すことができません。
あとはトリガーとなるプロセスビルダーをちょいちょいっと作成していきます。
プロセスビルダーの設定
フローに比べて、プロセスビルダーはめちゃくちゃ簡単です。
これだけ！
中身を少し見たいと思います。
まず条件については下記の2点。
- レコードタイプIDが該当のレコードタイプIDと一致しているか
- 依頼日が保存前の値から変更されているか（保存前：空白 → 変更後：入力済）
今回の「依頼日」は一度入力した後はまず変更されない項目を想定したので、こんな感じでも問題が起きる可能性は低いですが、「完了予定日」のように更新される可能性がある項目の場合、更新がかかるたびにフローが起動してしまいますので、フローが起動したらチェックが入るようなチェックボックス項目を追加して、条件に追加し重複してプロセスが走らない工夫が必要になると思います。
続いてアクションの方ですが、アクション種別からフローを選択すると、先程有効化したフローが選択できるようになります。
フローを選択すると、新たにフロー変数を設定という項目が表示されますので、ここから「＋行を追加」をクリックし、
フロー内の変数oppPage_Idを選択し、商談IDを割り当てます。
もしここでoppPage_Idが選択できない場合、フロー内のoppPage_Idにある「入力で使用可能」にチェックが入っていない可能性があります。
あとは有効化して完成！
実際に依頼日を入力してみると・・・
おお。
更にそのまま3日間制作予定日を放置してみると・・・
おお。ちゃんと怒られましたね！
あとはリリースし、担当さんに「入力サボると上司にバレる機能を作ったのでよろしく」と報告して完了です。
お疲れさまでした！
終わりに
プロセスビルダーだけだと割と簡単に使えるカスタム通知ですが、いざフローで使うとなると割と面倒な設定が必要になってきますね。しかし、プロセスビルダー単体だけではできないキューやグループを飛び越えた送信者を設定したり、柔軟な時間ベース処理などを駆使したりと、できることの幅は格段に広がると思います。
この手の分かりやすい情報ってまだまだ探すのが大変ですし、
いつか誰かの情報の足しにでもなりますように。
おしまい。