前回の記事の続き。Salesforceフローの基本的な使い方がわかったので、これまでプロセスビルダーで対応していたChatter自動投稿を行う仕組みをフローで作成してみました。今回はサンプルとして新規取引先が作成された専用のChatterグループに通知するという感じで試してみました。(実際に取引先作成だけで通知するようなことは無いですけど、レコード作成したらChatter通知というシンプルな条件ということで。)
事前準備1 - Chatterグループを作成
通知用のChatterグループを作成。Chatter投稿するときにはこのグループにメンションさせたい。
事前準備2 - Chatter自動投稿の有効化を管理するカスタム設定を作成
Chatterグループメンションする機能はSandbox環境ではそのまま動かないのでカスタム設定で無効化できるようにしたい。
フローの作成
今回は取引先レコード作成を起点とするのでフロー種別はレコードトリガフローを選択。
最初に設定する内容はこんな感じ。
- オブジェクト : 取引先
- フローをトリガする条件 : 作成されたタイミング
- エントリ条件を設定 : 指定なし
- フローを最適化 : アクションと関連レコード
要素を追加でアクションを選択。
要素の追加のアクションを選択すると、実行できるアクションすべてが選べる画面が表示されます。Chatter投稿はメッセージングにありました。
ちなみにChatter投稿アクションは要素を追加の欄で検索することでもアクセスできます。
Chatter投稿アクションの設定内容はこんな感じ。表示ラベルとAPI名と説明欄の入力は見たまんま。
入力値を設定の欄で投稿内容などを入力していく感じ。
メッセージのところは、一度新規リソースを作成してそこで定義する必要がありました。
新規リソースの作成時ですが、リソース種別はテキストテンプレートを選択すればいいみたいです。(最初テキストを選択して作成→割り当てで値を定義かと思いましたが、その方法では改行とかできませんでした。)
メモ：リソースを定義する際にはリッチテキスト形式ではなく、プレーンテキストで作成する必要ありとのこと。
設定方法についてSalesforceヘルプに詳細がまとめれています。
ヘルプだけではなく、サクセスナビでも設定手順がまとめられていました。(メッセージの文言の定義仕方がわからなくてこのページで理解できました。)
Chatter投稿の設定方法についてチェックできたので改めて再設定。
メッセージ
リソース変数を用意してそれを指定。
対象名または ID
レコードフィードに投稿したいときは、そのレコードIDを指定すればOKとのこと。今回は作成した取引先が対象なので、グローバル変数「$Record.Id」という感じになればいいはず。
Experience Cloud サイト ID
Exceperince CloudからChatter投稿するときは専用の設定が必要(コミュニティIDの指定)。今回は関係無いので無効化。
ターゲット種別
『[対象名または ID] がユーザ名または Chatter グループ名に設定されている場合にのみ必須です。』ということでレコードフィードへの投稿の場合は特に指定しなくてOKみたい。
表示
『このフィード項目を Experience Cloud サイトユーザが使用できるかどうかを指定します。内部ユーザにのみフィード項目を表示するには、internalUsers に設定します。』ということで内部ユーザのみ見せたい(基本こっちだと思う。)はinternalUsersを指定すればいいみたいだけど、デフォルト設定で用意されているので無効化のままでも良さそう。
という感じで設定した結果がこちら。
フローのテスト
デバッグボタンからテストできるはずなので、実行してみました。処理はロールバックされます。
エラーメッセージは特に出てなかったのとメッセージの変数はちゃんと取引先名と実行ユーザ名に差し替えされていたので設定は大丈夫そう。
フローの実行
有効化ボタンでフローを有効化。これで動くはずなので取引先レコードを登録して試してみました。結果は無事にChatter投稿できました。
チェック1: 取引先レコードフィードに紐付く形での投稿
チェック2: Chattetグループへのメンションでグループへ紐付け
チェック3: ハッシュタグの定義でトピック作成
フローによるChatter投稿が無事にうまくいきました。グループメンション、レコードフィードへの投稿、ハッシュタグ宣言。変数の差し込みとここまでがうまくいけばあとは要件に合わせて設定を調整していけば大丈夫そうです。
ちょっと調整① - 実行条件の追加
最初に記載したカスタム設定の有効フラグがONのときだけ処理が動くように設定を追加してみます。要素を追加で決定を選択。次のような感じで入力します。
※今回はカスタム設定の値判定ですが、グローバル変数『$Setup』で指定できました。
これで条件分岐の枠ができました。
最初に作ったChatter投稿のアクションを有効条件の中に移動したいのですが、それは要素の切り取りでできました。
これで条件に一致したときにだけChatter投稿できるように設定がうまくいきました。
ちょっと調整② - ChatterグループIDのハードコーディング対策
最初の設定はとりあえず動くものをという感じでIDを文字列指定しました。実際の設定ではこれはNGなのでレコード取得などで対応してみます。
ひとまずは新規リソースで変数を作成。
作成した変数にChatterグループレコードIDをセットするためには、まず要素を追加でレコードの取得を設定すればいいはず。対象オブジェクトはグループ(コレボレーショングループの方)です。同名のオブジェクトがあるのでAPI名で検索するのが安全かも。
レコード取得条件ですが、Name項目の文字列指定がいいのではと思います。
ChatterグループのName項目はユニークな制御があるので重複はしないはず。また、Sandboxでテストデータ作成するときなどに一番シンプルになると思います。
設定結果はこちら。
対象レコードは1件なので、最初のレコードを取得すればいいと思います。
Chatterグループのレコード情報は取得できたと思うので変数に値をセットします。要素を追加で割り当てを選択。変数にレコードIDをセットするように設定します。
これでChatterグループIDの情報を保持する変数を用意できました。
用意した変数をChatter投稿のメッセージ変数に差し込みます。
変数名はリソースのところで検索できます。
これでChatterグループIDを環境依存しない形、ハードコーディングしない形で設定できたと思います。最後に実行条件にChatterグループIDの値が存在しているかを追加しておきます。本番環境で値取得失敗することは無いと思いますが、Sandbox環境作成後など取得できないときには処理スキップするように、エラーでシステムが止まらないようにするために判定を追加しておきます。
別名で保存で新バージョンとして有効化します。ついでにデバッグでちゃんと動くことをチェック。(グループID取得できていることをデバッグメッセージで確認できました。)
実際に取引先を新規作成。これで新バージョンでも動作することを確認できました。
せっかくなのでエラーパターンもチェック。グループ名を変更してみます。
グループ名をレコード取得条件としていたので、グループ名変更によりレコード取得が0件となります。グループID変数は値なしとなったのでChatter投稿の実行条件を満たさなくなりました。これにより想定どおりに処理がスキップされるようになったことを確認できました。
いろいろ試してみてフローによるChatter投稿の設定が想定していたとおりに動作しました。実際の設定要件はもう少し複雑になると思いますが、基本的には今回のやり方をベースに処理を追加していく形でなんとかなりそうです。(あとは表示ラベルやAPI名の命名ルールがもう少しきちんと定義したい感じ。)
これでプロセスビルダーで対応していたChatter投稿系の処理はフローで実現できる準備ができたかなと思います。プロセスビルダーは@[グループ名]と定義した場合、裏側ではレコードIDのハードコーティングみたいな感じになっているので、Sandboxではプロセスビルダーを再設定しないと動かないなどの問題がありましたが、フローはレコード取得の仕組みをつかってハードコーディングでは無い形で設定を定義できるようになるのはなかなか良かったです。
