Salesforce自動化の現在地｜なぜフローへの統一が進むのか
多くの人が見落としがちですが、Salesforceの自動化はフローを使った設計が基本であり、ワークフロールール・プロセスビルダーからの移行を含めて、業務プロセス全体を見据えた設計を行うことで定着と成果につなげられます。本記事では、この結論を具体的な手順とともに解説します。
国内CRMアプリケーション市場は2023年に約2,498億円（前年比13.4%増）に達し、2026年には約2,918億円まで拡大すると予測されています（IDC Japan調査）。このCRM市場の成長に伴い、Salesforceを活用する企業も増加しています。
しかし、Salesforceの自動化機能を取り巻く環境は大きく変化しています。従来使われてきたワークフロールールとプロセスビルダーは非推奨となり、フローへの統一が進められています。
この記事で分かること
- Salesforce自動化ツール（フロー・プロセスビルダー・ワークフロー）の違いと選び方
- フローの種類と代表的な活用パターン
- ワークフロー・プロセスビルダーからフローへの移行手順
- 自動化設計の失敗パターンと成功のポイント（チェックリスト付き）
Salesforce自動化ツールの種類と違い
Salesforceの自動化ツールは、現在フローへの統一が進められており、新規開発ではフローを使うことが推奨されています。
Salesforce Flow（フロー） とは、Salesforceのノーコード/ローコード自動化機能です。ワークフロールールとプロセスビルダーの後継として位置づけられています。
プロセスビルダーは、Salesforceの旧自動化ツールです。現在は非推奨（廃止予定）となり、フローへの移行が推奨されています。新機能の追加は停止されています。
ワークフロールールは、Salesforceの旧自動化機能です。プロセスビルダーとともに非推奨となり、フローへの統一が進められています。
【比較表】Salesforce自動化ツール比較表（フロー・プロセスビルダー・ワークフロー）
| 項目 | フロー | プロセスビルダー | ワークフロールール |
|---|---|---|---|
| 現在のステータス | 推奨・現行 | 非推奨（廃止予定） | 非推奨（廃止予定） |
| 新機能追加 | あり | 停止 | 停止 |
| ノーコード対応 | ○ | ○ | ○ |
| 複雑な分岐処理 | ○ | △（制限あり） | ×（単純条件のみ） |
| レコード作成・更新 | ○ | ○ | ○ |
| Apex呼び出し | ○ | ○ | × |
| 画面フロー対応 | ○ | × | × |
| スケジュール実行 | ○ | ○ | ○ |
| 将来性 | 高い | 低い（移行推奨） | 低い（移行推奨） |
この比較表からわかるように、フローは両方の後継として位置づけられ、より柔軟な自動化が可能です。新規開発はフローで行い、既存のプロセスビルダー・ワークフロールールは段階的にフローへ移行することが推奨されています。
Salesforceフローの種類と代表的な活用パターン
フローにはいくつかの種類があり、用途に応じて使い分けることで効率的な自動化が実現できます。
レコードトリガーフローとは、レコードの作成・更新・削除をトリガーに自動実行されるフローです。旧プロセスビルダーの後継的機能として、最も多く使われるフロータイプです。
BtoB企業では、リードスコアからのMQL自動判定とインサイドセールスへの割り当てが、最初に自動化される典型的なパターンです。この自動化は成果が見えやすく、営業効率への直接的な効果が期待できます。
初期導入フェーズで本番運用されるフロー数は、中堅〜大企業の場合で10〜40本程度が相場感と言われています（ただし公的統計ではなく、導入支援の実務経験に基づく目安です）。
レコードトリガーフローの基本と活用例
レコードトリガーフローは、レコードが作成・更新・削除されたタイミングで自動的に処理を実行します。
活用例1: リードのMQL自動判定
- トリガー: リードのスコアが閾値を超えて更新されたとき
- 処理: リードステータスをMQLに変更、インサイドセールス担当者に自動割り当て
活用例2: 商談ステージ変更時の通知
- トリガー: 商談のステージが「提案」に変更されたとき
- 処理: 関係者へ自動通知、次のアクション項目を自動作成
活用例3: 顧客情報の自動更新
- トリガー: 取引先のレコードが更新されたとき
- 処理: 関連する商談・ケースの情報を自動更新
その他のフロータイプと使い分け
レコードトリガーフロー以外にも、用途に応じたフロータイプがあります。
スケジュールトリガーフロー: 定期的なバッチ処理に使用。例えば「毎週月曜に未対応リードを一覧化して通知する」などの定期処理に適しています。
画面フロー: ユーザーが操作する画面を伴うフロー。入力フォームやウィザード形式の入力ガイドを作成する際に使用します。
自動起動フロー: 他のフローやApexから呼び出されるサブフロー。共通処理を部品化して再利用する際に使用します。
ワークフロー・プロセスビルダーからフローへの移行方法
既存のワークフロールール・プロセスビルダーからフローへの移行は、多くの企業で課題となっています。新規開発は100%フローで行い、既存は2〜3年かけて段階的に移行するのが一般的です（ただし移行期間は既存の複雑さによって大きく異なります）。
重要なのは、フロー移行は単なる機能置換ではなく、業務プロセス全体の見直しが必要になることが多いという点です。移行を機に、不要な自動化の整理や、より効率的なプロセス設計を行うことが推奨されます。
移行の基本ステップ
ステップ1: 棚卸し
現在稼働しているワークフロールール・プロセスビルダーをすべてリストアップします。それぞれの目的、トリガー条件、実行アクションを整理します。
ステップ2: 優先順位付け
以下の観点で移行の優先順位を決定します。
- ビジネス上の重要度（売上・顧客対応に直結するか）
- 複雑さ（単純なものから着手するか、重要なものから着手するか）
- 依存関係（他の自動化との連携有無）
ステップ3: 設計・開発
フローで同等の機能を設計・開発します。この際、単純な置き換えではなく、業務プロセス全体を見直す機会として活用します。
ステップ4: テスト
Sandbox環境でテストを行い、既存の動作と同等であることを確認します。特にエッジケース（例外的な条件）のテストを念入りに行います。
ステップ5: 本番適用
本番環境に適用し、旧プロセスビルダー・ワークフロールールを無効化します。一定期間は並行稼働させ、問題がないことを確認してから旧機能を削除します。
Salesforce自動化の失敗パターンと成功のポイント
「フローを作れば自動化完了」と考え、業務プロセス全体の設計や運用ルールを整備しないまま導入した結果、フローが複雑化して管理できなくなる、または現場で使われなくなるケースは典型的な失敗パターンです。
IBM調査によると、SalesforceのAI施策を含む自動化で「ROI目標達成」と回答した企業は33%にとどまります。一方、成功企業は60%の効率向上、2倍以上のパイプライン拡大を実現しています（ただしこれはグローバル統計であり、日本固有の数値ではありません）。
この差は、フローの「作り方」だけでなく「業務プロセス全体を見据えた設計と運用」にあると考えられます。
よくある失敗パターン
失敗パターン1: フローが複雑化して管理不能に
担当者ごとにフローを作成した結果、類似のフローが乱立し、どれが何をしているか把握できなくなるケースがあります。命名規則やドキュメント管理が整備されていないことが原因です。
失敗パターン2: 現場で使われない
自動化を設計した担当者と、実際に使う営業担当者の間で認識のずれがあり、「便利だと思って作ったが誰も使わない」状態になることがあります。現場の業務フローを理解しないまま設計したことが原因です。
失敗パターン3: エラーが発生しても気づかない
フローのエラー通知設定が適切でなく、自動化が失敗しても誰も気づかないまま放置されるケースがあります。監視・アラート体制の不備が原因です。
成功に導くチェックリスト
【チェックリスト】Salesforce自動化設計チェックリスト
- 自動化の目的とビジネス成果を明確に定義している
- 業務プロセス全体を把握した上で自動化範囲を決定している
- フローの命名規則を定め、チーム内で共有している
- フローごとに目的・トリガー・処理内容をドキュメント化している
- 現場の営業担当者・オペレーターにヒアリングを行っている
- Sandbox環境でテストを実施している
- エッジケース（例外条件）のテストを行っている
- エラー発生時の通知先・対応フローを設定している
- 本番適用後の監視・アラート体制を整備している
- 運用開始後のレビュー・改善サイクルを計画している
- フロー管理者（オーナー）を明確にアサインしている
- 複数のフローが競合しないか確認している
- 不要になった旧プロセスビルダー・ワークフローを無効化・削除している
- ユーザー向けの操作マニュアル・トレーニングを準備している
- 定期的なフロー棚卸しのスケジュールを設定している
まとめ｜Salesforce自動化を定着させるために
本記事では、Salesforceの自動化機能について、フローの基本から移行方法、成功のポイントまで解説しました。
ポイントの整理
- ワークフロールール・プロセスビルダーは非推奨となり、フローへの統一が進んでいる
- 新規開発はフローで行い、既存は段階的に移行することを推奨
- フロー移行は単なる機能置換ではなく、業務プロセス全体の見直しの機会
- 「フローを作れば完了」ではなく、設計・運用ルール・監視体制の整備が重要
今後は、SalesforceのAI機能（Einstein、Agentforce）とフローを組み合わせた自動化・パーソナライズが主戦場になると予想されています。フローの基盤を整備しておくことで、これらの新機能を効果的に活用できるようになります。
Salesforceの自動化はフローを使った設計が基本であり、ワークフロールール・プロセスビルダーからの移行を含めて、業務プロセス全体を見据えた設計を行うことで定着と成果につなげられます。本記事で紹介したチェックリストを活用し、自社の自動化設計を点検してみてください。