Salesforceでは従来のワークフロールールが順次廃止され、より柔軟な自動化が可能なフロー（Flow）へ移行することが推奨されています。
すでに新規作成は制限されており、今後の運用を安定させるためには早期の移行が不可欠です。
そこで本記事では、ワークフロールール廃止の背景や移行の必要性を整理しつつ、実務で迷わないための移行手順・注意点をわかりやすく解説します。
今後のSalesforce運用を安定させるためにも、早めのフロー移行が重要になるので、ぜひ最後までご覧ください。
※1
Salesforceのワークフロールールとは
Salesforceのワークフロールールは、レコードが作成・更新されたタイミングで条件を満たすと特定の処理を自動で実行する仕組みです。
条件（if/then）を設定し、該当したら「項目自動更新」「メールアラート」「ToDo作成」「アウトバウンドメッセージ」などのアクションを実行できます。
システム管理者がコードを一切書かずにマウス操作だけで設定できるため、シンプルな定型業務の自動化の定番機能として長年利用されてきました。
しかし、複雑な条件分岐や多段階の処理には対応が難しく、現在はその後継となるSalesforce Flowに役割が引き継がれつつあります。
Salesforceのワークフロールールで自動化されること
Salesforceのワークフロールールで実行できるアクションは、公式に定められた4種類のみです。
どれも定型業務の自動化に適しており、Salesforce導入初期から多くの企業で活用されてきました。
Salesforceのワークフロールールで実行できるアクションの概要は以下の通りです。
| アクション | 概要 |
| 項目更新（Field Update） |
|
| メールアラート（Email Alert） |
|
| ToDo作成（Task） |
|
| アウトバウンドメッセージ（Outbound Message） |
|
上記の4つは非常に便利ではあるものの、複雑な条件分岐や複数アクションの連携が難しい制約があったため、廃止されることとなりました。
Salesforceのワークフロールールのメリット
ワークフロールールは、Salesforce導入初期から多くの企業で利用されてきた定番の自動化機能です。
特に「決まった条件で同じ処理を繰り返す」ような業務に強く、手作業に依存しがちな現場運用を安定させる役割を果たしてきました。
ここでは、Salesforceのワークフロールールのメリットについて解説します。
ヒューマンエラーの排除につながる
Salesforceのワークフロールールは、人の手で行う更新作業や通知業務に発生しがちなミスを根本から排除できる点が大きなメリットです。
例えば、項目更新のし忘れ、メール通知の送り忘れ、重要案件のフォロー漏れなどは、どれだけ注意していても一定の確率で発生します。
そこで、ワークフロールールを設定しておけば、条件を満たした瞬間にSalesforceが自動で処理を実行するため、抜け漏れがゼロに近づきます。
ワークフロールールは、シンプルな設定で業務品質を底上げできる実用的な自動化手段の一つです。
手動作業の削減になる
Salesforceのワークフロールールは、日々発生するルーチンワークを自動化し、担当者の作業負荷を大幅に軽減できる点が大きなメリットです。
ワークフロールールを設定しておけば、条件に応じてSalesforceが自動で処理を実行するため、誰が担当しても同じ品質で業務が進みます。
例えば商談成立時のフェーズ更新と通知メール送信を自動化すれば、手動作業をゼロにしつつ処理スピードの均一化も可能です。
定型業務の削減は、積み重ねると大きな工数削減につながり、組織全体の生産性向上を後押しでき、社員はより価値の高い顧客対応や営業活動に集中できるようになります。
リアルタイムでの共有できる
Salesforceのワークフロールールは、データ更新の瞬間に自動アクションが発動するため、情報共有のスピードを最大化できます。
例えば、大口契約が成立した瞬間にマネージャーへ自動通知を送れば、次のフォロー施策を即座に検討可能です。
また、重要なリスク兆候が出た際に関連部署へタイムリーに情報が届くことで、対応遅れによる損失も防げます。
ワークフロールールを活用すれば、「今、現場で何が起きているか」を組織全体が即時に把握できる体制を構築できます。
Salesforceのワークフロールール以外の自動化機能との違い
Salesforceにはワークフロールール以外にも、プロセスビルダーやフローといった、より高度な自動化を実現する仕組みが用意されています。
プロセスビルダーは「複数条件の判定」や「多数アクションの連続実行」が可能で、ワークフロールールより表現力が高い中間的な自動化ツールとして発展してきました。
一方で、最新の自動化基盤であるフローは、画面操作・データ更新・外部接続などあらゆる業務プロセスをノーコードで構築できる強力なツールで、現在はSalesforceの自動化の中心機能となっています。
ここでは、それぞれの特徴や役割を解説します。
プロセスビルダー
プロセスビルダーは、ワークフロールールの後継として登場した可視化型の自動化ツールで、複数の条件分岐を1画面で直感的に設定できる点が最大の特徴でした。
ワークフロールールでは実現できなかった「if A→アクション1」「if B→アクション2」のような分岐処理を、ドラッグ＆ドロップで簡単に構築できるため、より複雑な業務ロジックの自動化に広く活用されてきました。
また、プロセスビルダーには以下の3つの起動タイプがあり、それぞれが現在はフローの対応機能へ統合されています。
- レコード変更プロセス（レコード作成・更新時に起動）⇒レコードトリガーフロー
- プラットフォームイベントプロセス（イベント受信時に起動） ⇒プラットフォームイベントトリガーフロー
- 呼び出し可能プロセス（他プロセスから起動） ⇒自動起動フロー
プロセスビルダーは、かつてはワークフロールールより高度な判断・処理が可能な中間的ツールとして位置づけられていましたが、現在はSalesforceの自動化基盤がフローに一本化されたことで、プロセスビルダーは役割を終えつつある旧世代ツールとされています。
現在では、将来的な拡張性やパフォーマンスの観点から、すべての機能がフローへ統合される方向で統一されています。
フロー
フロー（Flow）は、Salesforceにおける自動化機能の新たな標準として位置づけられている強力なツールです。
ワークフロールールのシンプルさと、プロセスビルダーの高度なロジックをすべて統合し、さらに「ユーザとの対話型画面」など新しい機能を備えることで、Salesforce内の自動化をほぼフローだけで完結できるように進化しています。
フローの設定はGUIで行え、コード不要ながらプログラムレベルの複雑な処理まで実現可能です。
フローには、これまでの自動化ツールの役割を吸収した以下のような複数の種類があります。
| 種類 | 概要 |
| レコードトリガーフロー | ワークフローとプロセスビルダー（レコード変更）の機能を統合したフローで、レコードの作成・更新・削除時に起動する |
| 自動起動フロー | プロセスビルダーの後継で、他フローやApexから呼び出して部品のように使える汎用的なフロー |
| 画面フロー | 入力フォーム、案内ステップ、ウィザード形式の業務フローなど、従来ツールでは不可能だったUIを構築でき、ユーザが操作できる対話型の画面をノーコードで作成できる点が特徴 |
フローに統合されたことで、Salesforceの自動化は以下のようなメリットを生み出しています。
- ツールの一本化で管理負荷を削減
- プログラムレベルの高度な処理が可能
2026年現在、Salesforceの自動化は完全にフローへ一本化されており、ワークフロールールやプロセスビルダーは段階的に廃止へ向かっています。
既存の自動化設定を今後も安定して運用するためには、フローへの移行が必須です。
Salesforceのワークフロールール廃止の現状とリスク
Salesforceでは、長年利用されてきたワークフロールールについてすでに新規作成の制限が始まっており、将来的には利用できなくなるため、現行ルールを放置したままでは運用停止や不具合のリスクが高まります。
特に、営業プロセスや顧客管理の自動化にワークフロールールを多用している企業では、早期の移行計画が不可欠です。
ここでは、廃止までの最新スケジュールと、Salesforceがこの機能を終了させる背景について解説します。
機能制限から完全廃止に至るまでの最新スケジュール
Salesforceはワークフロールールおよびプロセスビルダーを段階的に廃止する方針を数年前から明確にしており、そのロードマップは年々進行してきました。
まず2023年時点で両ツールへの新機能追加が停止し、改善・拡張は完全に終了しました。続いて2025年初頭には、ついに新規のワークフロールール作成が不可となり、2025年12月31日をもって、ワークフロールールとプロセスビルダーは公式サポートが終了しました。
2026年1月現在、既存ルールが即座に使えなくなるわけではありませんが、今後バグが発生しても修正プログラムは提供されず、新しいOSやブラウザ環境における動作保証も行われません。
現在のワークフロールールは「動いてはいるが、いつ不具合が起きてもおかしくない」状態であり、本番環境で依存し続けること自体がリスクとなっています。
出典：Completely Removing Tableau Desktop
廃止される背景と主な理由
Salesforceが長年利用されてきたワークフロールールを廃止する最大の理由は、プラットフォーム全体の保守性向上とシステム負荷の軽減にあります。
ワークフロールール・プロセスビルダー・フローの3つが併存する状態では、同じような機能が複数に分散し、管理者は「どこで何を設定したか」を把握しづらく、動作トラブルの原因にもなっていました。
そこで動作トラブルに関わる諸問題を解消するため、Salesforceは最新基盤であるフローへ機能を一本化する方針を採用しました。
フローは処理速度が速く、複数条件の同時判定・ループ処理・削除操作など、従来ツールでは不可能だった高度な自動化が可能です。
廃止は単なる整理ではなく、Salesforce全体の品質向上と進化を見据えた必然的なアップデートであり、これがワークフロールールが役割を終える大きな理由となっています。
Salesforceのワークフロールールからフローに移行方法
ワークフロールール廃止に伴い、既存の自動化設定をフローへ正しく移行することは、今後の安定運用に欠かせない重要なステップです。
Salesforceは移行を支援する公式ツールを提供していますが、すべてが自動で変換されるわけではないため、事前の棚卸し・適切な再構築・動作確認が必要になります。
特に自動化が多い組織ほど、移行の品質が運用リスクを左右します。
ここでは、移行作業を3つのプロセスに分けて、具体的にどのように進めればよいかを解説します。
既存ワークフロールールの洗い出しと棚卸し
フローへの移行を成功させるための第一ステップは、現在稼働しているワークフロールールをすべて洗い出し、内容を可視化することです。
ワークフロールールの洗い出しの際には、まずは管理画面から全ワークフロールールを一覧で確認し、Excelやスプレッドシートに「ルール名/対象オブジェクト/条件/アクション内容/利用状況」などを整理して書き出します。
そして、整理した後に以下の観点で棚卸しを行うと効果的にフローへの移行への準備が行えます。
- 今も実務で使われているか
- 類似ルールと統合できないか
- そもそも移行が必要か など
上記の棚卸し作業により、不要な設定を削除し、本当に必要なルールだけを移行対象として絞り込めます。
公式ツール「フローに移行」による自動変換の実施
棚卸しで移行対象が整理できたら、次のステップは Salesforce標準ツール「フローに移行（Migrate to Flow）」を使った自動変換です。
Migrate to Flowは、既存のワークフロールールをワンクリックでレコードトリガーフローへ変換できる便利な機能で、移行作業の時間を大幅に短縮できます。
操作手順はシンプルで、設定画面から対象オブジェクトを選び、変換可能なワークフロールールを一覧から選択して「変換」ボタンを押すだけです。
この方法はSalesforce公式でも推奨されており、まずはこのツールを使って 「自動で移行できるもの」 を把握することが効率化の第一歩となります。
ただし、Salesforceのヘルプにも記載されている通り、以下のようなルールは自動変換の対象外になります。
- 複雑な数式フィールド参照
- 特定のアクション（アウトバウンドメッセージ等）を含むルール
- 条件分岐が複雑なワークフロー
- 複数アクションを含み内部で依存関係があるもの など
Migrate to Flowでは、「自動変換できるルール」と「手動でのフロー再構築が必要なルール」を分類すると、移行全体の作業量が明確になり、実際のスケジュールとリソース計画が立てやすくなります。
手動再構築（レコードトリガーフロー）と有効化・テスト
公式ツールで変換できなかったワークフロールールについては、「Flow Builder」を使って手動でレコードトリガーフローを作成する必要があります。
特に複雑な条件分岐や独自ロジックを含むルールは、ツールでは変換不可となるため、フローの構成要素（トリガー、判断、更新、通知など）をワークフロールールの内容に合わせて組み立てていきます。
そして、フローを作成したら、次の重要ステップはデバッグによるテストです。
Flow Builderにはデバッグ実行機能が備わっており、実データに近い条件を用いて「どの条件で何が実行されるか」を逐一確認できます。
無事にテストを問題なくクリアした場合、フローを「有効化」し、最後に元のワークフロールールを必ず「無効化」しなければなりません。
新旧の自動化が同時に動作してしまうと、二重更新・二重通知などのトラブルにつながるため、この手順は移行プロセスの最終かつ必須の工程として押さえておく必要があります。
手動再構築とテストの丁寧な実施によって、ワークフロールールからフローへの移行は安全かつ確実に完了できます。
Salesforceのワークフロールールからフローに移行する際の注意点
ワークフロールールからフローへの移行は、単純に置き換えるだけではなく、正しく動作させるための事前準備と移行後の確認が欠かせません。
特に、公式の移行ツールが対応できない複雑なルールや、フローに変換した結果挙動が変わる可能性のある処理は、想定外のトラブルにつながるリスクがあります。
ここでは、移行を進める際に気をつけるべきポイントを2つの視点から解説します。
移行ツールの利用できないパターンがある
Salesforce公式の「フローに移行（Migrate to Flow）」ツールは便利ですが、すべてのワークフロールールを自動変換できるわけではありません。
特に、以下のような複雑な条件や特殊なアクションを含むルールは、ツールの制約により変換対象外となります。
| 対象外なケース | 概要 |
| クロスオブジェクト参照が含まれる場合 | 複数オブジェクトを跨ぐ参照があると、ツールが正しくロジックを解釈できず変換不可 |
| 複雑な数式を利用している場合 | 長い数式ロジックを直接条件に書いているワークフローは対象外 |
| 特殊なアクションを含んでいる場合 | Chatter投稿、カスタム通知の送信、承認申請の自動送信などは変換不可 |
上記のケースでは、移行前にルールの仕様を必ず確認し、どの部分をフローでどう再現するか設計しておく必要があります。
フローに移行後の検証が必要になる
公式ツールで問題なくフローへ変換できたとしても、そのまま本番環境で正しく動作するとは限りません。
ワークフロールールとフローでは処理方式や実行タイミングが異なるため、移行後には必ず動作検証を実施し、業務への影響が出ないよう調整する必要があります。
特に以下のポイントは、事前に確認しておくべき重要項目です。
| 検証が必要な項目 | 概要 |
| 実行タイミング（保存前／保存後）の最適化 | 業務ロジックに合った実行タイミングを選定することが重要 |
| 二重実行の防止（旧ワークフローの無効化） | 元のワークフロールールを無効化し忘れると二重実行が発生するため、切り替え作業は必ずセットで実行する |
| トリガー順序（Flow Trigger Order）の確認 | フローごとに「トリガー順序」を設定し、意図する順序で実行されるかを確認する |
上記のポイントを押さえると、フロー移行後の不具合や業務停滞を防ぎ、安定したSalesforce運用が実現しやすくなります。
Salesforceのワークフロールールについてよくある質問
ここでは、Salesforceのワークフロールールに関するよくある質問とその回答について解説します。
承認プロセスも「フロー」へ移行・統合する必要がありますか？
現時点（2026年）では承認プロセスをフローへ移行する必要はありません。
ワークフロールールやプロセスビルダーとは異なり、承認プロセスには廃止予定が明確に示されていません。
Salesforceの公式担当者も次のように回答しています。
| 「Salesforceは、承認プロセスをすぐに廃止する予定はありません。これは数千のお客様に活発に利用されている機能だからです。」 |
さらに補足として、Salesforce側は次の点も説明しています。
| 「将来的には『フローオーケストレーション』など、より柔軟な機能が拡張される可能性はありますが、現時点のフローだけでは承認プロセスの全機能を完全に代替できるわけではありません。」 |
現状では、既存の承認ルートが複雑・標準の承認画面・メール通知を活用しているなどの状況であれば、無理に移行する必要はありません。
既存のワークフロールールを放置するとどうなりますか？
2025年末のサポート終了後も、ワークフロールール自体は当面動作します。
しかし、Salesforceのバージョンアップに伴う動作保証が完全に失われた状態であるため、今後予期せぬ不具合が発生しても修正パッチは提供されません。
エラーが出てもサポートに依頼できず、業務への影響を自社だけで解決する必要が生じるのが現状です。
さらに、ワークフロールールは旧世代の仕組みであり、処理速度がフローより遅く、組織全体のパフォーマンスに悪影響を及ぼす可能性もあります。
特に、大量データを扱う環境やData Cloud・外部連携を行っている組織では、ボトルネックになるリスクが高まります。
ワークフロールールの放置は、将来的な障害の温床になり得るため、できるだけ早めに対応するのがおすすめです。
移行ツール「フローに移行」で変換できないルールはどうすべきですか？
移行ツールがエラーを返す場合や変換不可と判断された場合は、手動での再構築が必須です。
変換できないルールに対しては、Flow Builderでゼロから再設計することが最も安全で確実なアプローチです。
手間はかかりますが、この機会に業務プロセスそのものを見直し、不要なロジックを整理しながら再構築すれば、結果的に「保守性が高く、将来の変更にも強い自動化設計」へと改善できます。
複雑なルールこそ丁寧に再設計すると、長期的な運用負荷を大きく下げられます。
まとめ：Salesforceのワークフロールールをフローに移行し、使いこなそう！
Salesforceのワークフロールールの廃止は、Salesforce運用全体をより高度化・効率化する大きな転換点です。
フロー（Flow Builder）へ移行すれば、従来では難しかった複雑な条件分岐、ループ処理、データ操作をノーコードで実現でき、ビジネスプロセスの自動化レベルは格段に向上します。
一方で、フローは機能が豊富である分、現場のユーザが使いこなすためのサポートが不可欠です。
ワークフローからフローへと操作手順が変わると、入力ミスや戸惑いが生まれ、せっかくの自動化の効果が十分に発揮されないケースもあります。
そこでフローを本格的に運用する際に有効なのが、ノーコードで画面上にデジタルガイド・ツールチップを表示できる「テックタッチ」のようなデジタルアダプションツール（DAP）です。
画面上に操作ガイドや入力ヒントをリアルタイムで表示できるため、ユーザは迷うことなく新しいプロセスに順応できます。
ワークフロールールの移行は「作って終わり」ではなく、使われて効果を発揮してこそ意味を持ちます。
2026年以降のSalesforce運用をより強固なものにするためにも、フローへの移行とあわせて、ユーザ定着を促す仕組みづくりまで見据えた取り組みが重要です。
