Salesforce でメール送信と言えば、ワークフローとメールアラートを思い浮かべる方は多いと思います。
Salesforce の自動プロセス機能は、一昔前は「ワークフロー」「プロセスビルダー」「フロー」が使い分けられていました。
しかし、Salesforce は公式に段階的なフローへの移行を明示しました。
複数段階での移行を計画しています。最初の段階は、Winter ’23 リリースから始まります。新規のワークフロールールを作成することはできなくなります。後日、プロセスビルダーで新規のプロセスを作成することはできなくなります。後の段階で、ワークフロールールとプロセスビルダーはすべてのプラットフォームオートメーションとともに完全に廃止されます。これらの段階を設けることにより、システム管理者が余裕を持ってフローへの移行に対応できるようにしています。
詳細は公式記事をご覧ください。（ワークフローおよびプロセスビルダーの廃止とフローへの移行）
今回は、今までワークフローで実装していたメールアラート機能をフローで実現する方法を紹介します。
前提
本記事は Developer Edition で設定を行なっています。
環境がまだない方は、下記公式記事リンクの「サインアップ」から取得できます。
（公式 Salesforce Developers Japan Blog）Developer Edition サインアップ手順
メールテンプレートの作成
メールテンプレートの作成は、従来と同じです。
[設定] > [Classic メールテンプレート] > [新規テンプレート] で作成します。
※必要に応じて、フォルダの作成も行います。
今回はシンプルな設定で動作の確認のみを行います。
利用するユースケースにもよりますが、オブジェクトの差し込み項目も必要に応じて設定します。
その際はフロー上で取得できるオブジェクトの情報に限られるため、ご注意ください。
公開グループの作成（任意）
本手順はスキップ可能です。
すでにメールの受信先が決まっていたり、設定したい公開グループがあったりする場合は次に進んでください。
[設定] > [公開グループ] > [新規] で公開グループを作成します。
登録するユーザは要件に応じて設定してください。
ここで設定した公開グループを、メールアラートの設定で利用します。
メールアラートの作成
[設定] > [メールアラート] > [新規メールアラート] で作成します。
一例として、「商談がWinした時にメールを受け取る」というケースを想定し、オブジェクトは「商談」にします。
特筆すべき設定内容はありませんが、「メール受信者」に特定のメール項目の値を使う等の要件がない場合は、できる限り公開グループを設定することを個人的にお勧めします。
公開グループを設定する理由
理由はシンプルで、メンテナンス性が上がるからです。
本番リリース後は、保守契約などがない限りは主にお客様のシステム部門で運用されることが多いです。
その際に、「メールアラートの変更」と「公開グループの編集」のどちらがハードルが低いかと言う話です。
例えば、「商談が成立した時」「商談がロストした時」にメールを受け取るグループに、「このユーザも追加したい」と言う要望があるとします。
メールアラートに直接ユーザを登録しておくより、メールを受信する対象のユーザグループとして公開グループを設定しておく方がユーザの出し入れが簡単に思えます。
Salesforce 経験があれば、機能の設定も行えるかもしれませんが、お客様によってはユーザの管理ぐらいしかできない場合もあります。できるだけ「ユーザ」以下の機能でメンテナンスできる方がいいですよね。
システムベンダーとしてもメリットがあります。メールアラートの設定を変更したらその分テストが必要ですよね。公開グループの設定変更であれば、そのユーザにメールが送信されるかどうかだけの観点に限定できるので、負担減です。
フローの作成
[設定] > [フロー] > [新規フロー] で作成します。
本記事の例では、商談に関連するメールアラートを作成したので、フローも商談に関連する「レコードトリガーフロー」を選択します。
フローのトリガ条件の設定
以下のように、どのオブジェクトのどの条件で動作するかを定義します。
今回は「商談がWinした時にメールを受け取る」というケースなので、商談を設定します。
| 設定項目 | 値 |
|---|---|
| オブジェクト | 商談（Opprtunity） |
| フローをトリガする条件 | レコードが更新された |
| エントリ条件を設定 | 条件の要件：全ての条件に一致（AND） 項目：IsWon 演算子：次の文字列と一致する 値：True |
| 更新されたレコードでフローを実行するタイミング | 条件の要件に一致するようにレコードを更新したときのみ（*1） |
| フローを最適化 | アクションと関連レコード（*2） |
（*1）毎回商談を更新する度にメールが送られて欲しくない場合は、「条件の要件に一致するようにレコードを更新したときのみ」に設定します。
（*2）メールアラートを利用する場合は、必ずこちらを利用します。
メールアラートのアクション設定
なんとも味気ないフローになってしまいますが、デフォルトで用意されている「メールアラートを送信」アクションを利用するだけです。
レコードトリガーフローなので、IDは最初から渡される変数にあるものを利用します。
【おまけ】
フローの中でも様々な変数、画面、画面上のコンポーネント、アクションなどにAPI名が登録できます。上の画像のように、Action_*** など、何を表すAPI名なのかルールを決めておくと、後で混乱するリスクを減らせます。
フローを保存し、有効化しておきましょう。
動作確認
Developer Edition に最初から登録されているレコードで試してみます。
では、商談を1件、「Closed Won」で更新します。
ちゃんとメールが届きました。
ソースコード
こちらの GitLab リポジトリにて公開しています。
おわりに
私個人としては、フローで複雑なロジックを組んだり、レコードトリガーフローを量産したりして、スパゲッティになるのを避けるため、フローは多用しません。
しかし、フローはすでに用意されている仕組みの範囲であれば、簡単にウィザード形式の画面を組んだり、シンプルなCRUDやアクションの実行には適しています。
ローコード開発とプロコード開発のそれぞれのメリットデメリットを把握し、適切に使い分けましょう。
この記事が少しでもお役にたてれば幸いです。
コメント