Salesforce Flow チケット当落メール後のフォロータスク自動化の考え方

イベント運営や限定キャンペーンにおいて、チケットの「当選・落選」が確定した後のオペレーションは、単にメールを送信して終わりではありません。当選者には入金確認や参加確定の督促タスクを、落選者にはキャンセル待ちの案内や次回イベントへの誘導タスクを、それぞれ適切なタイミングで割り当てる必要があります。

これらのプロセスを手動で行うと、対応の遅れや漏れが発生し、顧客体験（CX）の低下だけでなく、収益機会の損失を招きます。本記事では、Salesforceの「Flow（フロー）」を活用し、ステータス変更をトリガーにフォロータスクを自動生成する、実務に耐えうる設計手法を詳説します。

Salesforce Flowでチケット抽選後のフォローを自動化すべき理由

抽選イベントの運用において、最も負荷がかかるのは「通知直後」です。数千人、数万人規模の応募者に対して一斉に抽選結果を反映させた際、その後のアクションが個人の記憶やスプレッドシート管理に依存していると、必ずミスが発生します。

手動管理による「フォロー漏れ」と「対応遅延」のリスク

例えば、当選後に期日までに入金がないユーザーを特定し、個別に電話やメールでフォローする業務を考えてみましょう。Salesforce上のステータスを一つずつ確認し、手動で「ToDo」を作成していては、入金期限が過ぎてから気づくといった事態になりかねません。

ステータスに応じた「ToDo」自動生成のメリット

Flowを活用すれば、レコードのステータスが「当選」に更新された瞬間に、期日が3日後に設定された「入金確認タスク」を営業担当者や事務局に自動で割り当てることが可能です。これにより、担当者は「次に何をすべきか」を考える必要がなくなり、Salesforceを開いた瞬間に優先順位の高いタスクから着手できるようになります。

こうしたCRMデータの活用は、単なる事務効率化に留まりません。顧客の行動履歴に基づいた適切なアプローチは、成約率やリピート率に直結します。
【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』でも解説している通り、各ツールの責務を明確に分けることが、自動化の第一歩となります。

実装前に整理すべきオブジェクト設計とデータフロー

Flowを構築する前に、どのオブジェクトにデータを保持し、どのレコードをトリガーにするかを決定する必要があります。

標準オブジェクト（キャンペーン）かカスタムオブジェクトか

一般的には、以下の2つのパターンが多く見られます。

• パターンA：キャンペーンメンバーを使用

  Salesforceの標準機能である「キャンペーン」と「キャンペーンメンバー」を利用する方法です。セミナー管理など、標準的なイベント運営に適しています。

• パターンB：カスタムオブジェクト（抽選・申込管理）を使用

  「1つのイベントで複数の券種がある」「同行者情報を保持する」など、データ構造が複雑な場合は、独自のカスタムオブジェクトを設計します。

メール送信とフォロータスクを連動させるデータ構造

自動化のゴールは、「メール送信」と「タスク作成」のセット実行です。Flow内では、ステータスが「当選」になった場合にのみ、当選通知メールを送信（Email Action）し、同時に「ToDo」レコードを作成するロジックを組みます。

【ステップ別】フォロータスク自動化Flowの構築手順

ここでは、実務で最も汎用性の高い「レコードトリガーフロー」を用いた構築手順をステップバイステップで解説します。

ステップ1：レコードトリガーフローの起動条件設定

まず、トリガーとなるオブジェクト（例：キャンペーンメンバーまたはカスタム申込オブジェクト）を選択します。

• 設定タイミング: レコードが更新されたとき
• 条件の要件: 「すべての条件に一致 (AND)」
• フィールド: ステータス（Status__c）
• 演算子: 次の値に一致する
• 値: 当選（または落選）
• 更新されたレコードでフローを実行するタイミング: 条件を満たすようにレコードを更新したときのみ

ステップ2：当選・落選の条件分岐（決定要素）の作成

「決定」要素を追加し、ステータスの値に応じて処理を分岐させます。
「当選ルート」と「落選ルート」、そして「それ以外（デフォルト）」を定義します。これにより、1つのFlow内で異なるフォローシナリオを一元管理できます。

ステップ3：一括処理（バルク処理）を意識したタスク作成ロジック

重要： 単一レコードの更新であれば「レコード作成」要素を直接配置しても動作しますが、データローダなどで一括更新を行う場合、ガバナ制限に抵触する恐れがあります。SalesforceのFlowは自動的にバルク化されますが、ループ処理を組む場合は「ループ内でレコード作成を行わない」のが鉄則です。

ステップ4：メールアラートまたはメール送信アクションの組み込み

「アクション」要素からメール送信を設定します。事前に作成した「メールテンプレート」を呼び出すか、Flow内の「テキストテンプレート」を使用して、宛先（メールアドレス）、件名、本文を指定します。

高度な顧客対応を自動化する場合、メールだけでなくLINEを活用するケースも増えています。
高額MAツールは不要。BigQueryとリバースETLで構築する「行動トリガー型LINE配信」の完全アーキテクチャを参考に、通知チャネルを拡張する設計も検討に値します。

実務で差が出る「ガバナ制限」回避とエラーハンドリング

Salesforce管理者として最も避けるべきは、本番環境で「Limit Exceeded（制限超過）」エラーを発生させることです。

ループ内でのDML操作を避けるためのコレクション変数活用

もし、親レコード（イベント）が「終了」になった際に、紐づく数百人の「落選者」に対して一括でタスクを作るようなロジックを作成する場合、以下の手順を踏んでください。

1. 「割り当て」要素を使用し、タスクの値を設定した単一レコード変数を作成する。
2. その変数を、レコードコレクション変数（リスト）に「追加」する。
3. ループの外側で、その「コレクション変数」を使用して一括で「レコード作成」を実行する。

これにより、データベースへのアクセス（DML操作）が1回に集約され、パフォーマンスが劇的に向上します。

処理失敗時の担当者への通知設定（フォルトパス）

万が一、入力規則違反などでタスク作成が失敗した場合に備え、「フォルトパス」を設定します。エラーが発生した際に、システム管理者にSlack通知を送る、あるいはエラーログオブジェクトにレコードを作成するなどの処置を施すことで、サイレントフェイルを防ぐことができます。

Salesforce Flow vs 外部ツール・MA連携の比較

Flowは強力ですが、全てのフォロー業務をFlowで完結させるのが正解とは限りません。配信規模やマーケティング要件に応じて、適切なツールを選定するための比較表を以下に示します。

自社の要件が「社内タスクの徹底」にあるならFlowが最適ですが、より広い顧客体験の最適化を目指すなら、
LIFF・LINEミニアプリ活用の本質。Web行動とLINE IDをシームレスに統合する次世代データ基盤のような、モダンなアーキテクチャへの投資も検討すべきでしょう。

運用の注意点とセキュリティ対策

自動化を本番環境にデプロイする前に、以下の2点は必ず確認してください。

二重実行の防止策（実行済みフラグの管理）

誤って同じレコードのステータスを再度「当選」に更新してしまった際、また同じメールが飛び、同じタスクが作られるのは避けなければなりません。「フォロー実行済みフラグ（チェックボックス）」等のカスタム項目を用意し、Flowの開始条件に「フラグがFalseであること」を加え、処理の最後でTrueに更新する設計が推奨されます。

Sandboxでの徹底したメール送信テスト

当選・落選のロジックが逆転していた場合、取り返しのつかないクレームに発展します。
Salesforce公式ドキュメント（メール送信の制限と有効化）に基づき、Sandbox環境での「メール送信のアクセス権」を調整した上で、実在するテスト用アドレスに対して、期待通りの本文が送信されるか必ず実機確認を行ってください。

また、フォロー後の「入金」まで自動化の範囲を広げる場合は、会計システムとの連携も視野に入ります。
Salesforceとfreeeを繋いでも「サブスク売上」は自動化できない。前受金管理とバクラクを活用した一括請求アーキテクチャで触れているように、入金確認の自動化は、ビジネス全体のキャッシュフロー健全化に大きく寄与します。

Salesforce Flowを用いた自動化は、正しく設計すれば「24時間365日働く優秀な事務局」になります。まずは最もシンプルなタスク生成から着手し、徐々に複雑なシナリオへと拡張していくことをお勧めします。