• 作成日 : 2025年11月25日

2025年12月にSalesforceのワークフロールールが廃止予定!フローへの移行方法を解説

Salesforceでは、業務の自動化を担う機能として「ワークフロールール」「プロセスビルダー」「フロー」が用意されています。中でもワークフロールールとプロセスビルダーは長く利用されてきましたが、現在は後継機能であるフローへの統合が進み、2025年12月31日には両機能のサポート終了が予定されています。今後は、より柔軟で拡張性の高いフローが自動化の中心となるため、既存ワークフローの棚卸しや移行計画の検討が重要です。

当記事では、ワークフローの基本、各自動化機能の違い、廃止理由、フローの特徴、移行の進め方などを解説します。

Salesforce ワークフローとは?

Salesforceのワークフローとは、社内の定型業務を自動化し、担当者の作業負担を軽減するための仕組みを指します。顧客管理や商談管理を中心に多くのデータを扱うSalesforceでは、更新のたびに手作業で確認・連絡・処理を行うと、ミスや抜け漏れが発生しやすくなります。ワークフローを活用すると、あらかじめ決めた条件に基づいて必要な処理を自動で進められる可能性があるため、業務のスピードや正確性の向上に寄与します。

たとえば、案件のステータスが変わったときに担当者へ通知したり、必要な項目が入力されたタイミングで次の作業に進めたりと、手作業に頼っていた業務の一部を自動化できます。これにより、担当者はより重要な業務に集中でき、組織全体の生産性向上につながります。

Salesforceにおけるワークフローは、日々の業務運用を標準化し、情報の扱いを統一するための自動化基盤として機能します。現場の負荷を軽減しつつ、顧客対応の質を維持するために有用な機能と言えます。

Salesforceの主な自動化機能3つ

Salesforceには、業務を効率化するための自動化機能が複数あり、代表的なのが「ワークフロールール」「プロセスビルダー」「フロー」です。機能の性質ごとに得意分野があるため、目的に応じて使い分けられます。

ワークフロールール

ワークフロールールは、Salesforceで長く利用されてきた基本的な自動化機能で、レコード更新やメール送信など、単純な処理を条件に応じて自動化できます。設定はシンプルで使いやすく、軽微な業務の自動化に向いています。

ただし、高度な分岐処理や複数ステップのワークフローには対応していないため、複雑な業務には不向きです。現在は後継機能である「フロー」への移行が推奨されており、新規でワークフロールールを作成するよりも、既存ルールの維持や段階的な移行に使われるケースが中心になっています。

プロセスビルダー

プロセスビルダーは、ワークフロールールより複雑な自動化が可能で、複数の条件分岐や段階的な処理を1つのプロセスにまとめて構築できます。画面上でフロー図のように操作でき、処理の流れを視覚的に把握しながら設定できるのが特徴です。

しかし、実行速度やパフォーマンスの観点で制約があるため、現在はSalesforceが「フロー」への移行を公式に推奨しています。そのため、既存プロセスの維持目的で利用されることが多く、新規構築には適していません。

フロー

フローは、Salesforceの自動化機能の中で最も強力かつ推奨されるツールで、レコード更新や自動処理はもちろん、画面フローによる入力フォームの作成、複雑な条件分岐、外部連携など幅広い要件に対応できます。ノーコードで高度な自動化が構築できるため、ワークフロールールやプロセスビルダーが担っていた処理もすべてフローに統合されつつあります

今後のSalesforceでは自動化の中心がフローに一本化される方針であり、新しいワークフローを作成する場合にはフローを使用することが標準となっています。

ワークフロールール・プロセスビルダーは2025年12月にサポート終了予定

Salesforceは、長年にわたり自動化の基盤として採用されてきたWorkflow Rules(ワークフロールール)およびProcess Builder(プロセスビルダー)について、2025年12月31日をもってサポート終了(End of Support)とする旨を公式に発表しています。

この日以降も既存のルールやプロセスは動作し、多くのケースで編集・有効化・無効化も可能ですが、バグ修正などの公式サポートが終了するため、レガシー機能として扱われます。そのため、ユーザーは次世代の自動化ツールである「フロー」への移行を検討・実行する必要があります。従来のワークフローに依存した体制では、2026年以降の運用リスクが増大するため、早期の検討が推奨されます。

段階的な廃止のスケジュール

Salesforceによれば、ワークフロールールおよびプロセスビルダーの正式な「サポート終了(End of Support)」日は2025年12月31日と明言されています。この日付を境に、これらの機能は「サポート対象外」となり、Salesforce公式からのバグ修正、セキュリティ更新、機能改善が行われなくなります。

ただし、終了日に機能停止が発生するわけではなく、「既存のルール・プロセスが動作しなくなる」わけではありません。動作は継続する可能性がありますが、運用上の安全性・信頼性が大きく下がるリスクがあります。

移行準備のフェーズとして、2023年以降はすでに「新規のワークフロールール・プロセスビルダー作成が非推奨」となっており、2024~2025年にかけて多くの企業が「移行計画の立案」「自動化資産の棚卸し」「フローへの切り替え作業」に着手しています。この段階的な廃止スケジュールを理解し、移行までにテスト・検証・運用切り替えの準備を整えておくことが、安定運用を維持するためには不可欠です。

Salesforceのワークフロールール・プロセスビルダーが廃止される理由

Salesforceがワークフロールールとプロセスビルダーを廃止する最大の理由は、自動化基盤を「Flow(フロー)」へ統一するためです。これら旧来の自動化機能は長年使われてきましたが、システム構造が複雑で保守性が低く、大規模組織では処理速度の低下や運用の分散などが課題となっていました。また、ワークフロー・プロセスビルダーは機能拡張が難しく、複雑な分岐やループ処理、画面操作を伴う業務には対応できません。一方、Flowは同じ自動化をより高速・安定・柔軟に実行でき、UI更新や最新機能追加も集中して行われています。

Salesforceは今後のプラットフォーム成長を見据え、メンテナンスが難しい旧機能ではなく、拡張性の高いフローを標準自動化ツールとして推奨しています。これにより、ユーザーは1つの統合基盤で自動化資産を管理でき、将来的なアップデートにも対応しやすくなります。企業がより効率的で一貫性のある運用を行うための戦略的な移行と言えます。

Salesforce フローと従来の自動化ツールとの違い

Salesforceのフローは、従来のワークフロールールやプロセスビルダーよりも高い柔軟性と拡張性を備えた次世代の自動化ツールです。1つの機能に統合されているため、複雑な業務プロセスも一元的に構築・管理できる点が大きな特徴です。ここでは、従来の自動化ツールとの違いについて詳しく解説します。

既存ツールの機能を拡張して柔軟な自動化ができる

フローは、ワークフロールールやプロセスビルダーが持つ通知・更新・タスク作成などの基本機能をすべてカバーしつつ、より高度な処理も実行できる統合自動化ツールです。レコード更新の順序制御や複数オブジェクトをまたいだ処理など、以前は複数機能に分散していた自動化をフロー1つでまとめられます。これにより、業務ルールの変更にも柔軟に対応でき、長期的な運用負荷を大きく減らすことが可能になります。

複雑な条件分岐やループ処理ができる

プロセスビルダーでは表現が難しかった複雑な分岐条件や繰り返し処理も、フローなら標準機能として実装できます。たとえば、リスト形式で取得した複数レコードへの一括処理や、条件に応じた細かなフロー分岐などが可能です。これにより、人手で対応していた細かな判定やステータス更新を自動化し、業務全体の正確性とスピード向上につなげられます。

画面付きのフローを作れる

フローでは、ユーザーが操作する画面(Screen Flow)を用意できる点が大きな特徴です。入力フォーム、選択肢、ボタンなどを自由に配置でき、Salesforce画面上で対話型の業務フローを構築できます。新人スタッフの入力ミス防止、ガイド付き作業手順の提供、部門間プロセスの統一などに活用され、従来ツールでは難しかった「ユーザー参加型」の業務自動化が実現します。

外部システムと連携できる

フローは外部システムとの連携機能が強化されており、APIコールを使って外部サービスとリアルタイムでデータの送受信ができます。たとえば、ERP・MAツール・外部データベースとの連携などが可能で、複数システムにまたがる業務でも自動化の範囲が大きく広がります。これにより、Salesforceを中心としたシームレスな業務基盤を構築しやすくなり、企業全体のDX推進にも役立ちます。

Salesforce フローの主な種類

Salesforceのフローには、用途やトリガーに応じて複数のタイプがあり、業務プロセスを柔軟かつ高度に自動化できます。ここでは、代表的なフローの種類と特徴を整理します。

スケジュールトリガーフロー

スケジュールトリガーフローは、指定した日時や間隔で自動実行されるフローで、定期的なメンテナンス処理に適しています。毎日・毎週といった単純な間隔のほか、月初・月末など特定日を指定することも可能です。

また、実行対象レコードを条件で絞ることができ、一括更新にも強みがあります。深夜帯に大量処理を行うバッチ的な活用もでき、組織のトラフィックを避けて安全に自動処理を回せる点が大きな利点です。

レコードトリガーフロー

レコードトリガーフローは、レコードの作成・更新・削除をきっかけに動作するフローで、日常業務の自動化に最も広く使われています。保存前と保存後で実行タイミングを分けられ、データ整形、重複排除、関連オブジェクト更新など、標準機能では難しい処理も細かく制御できます。

複数の条件分岐を重ねたロジックにも対応しており、従来のワークフローでは実現できなかった高度な業務ロジックの自動化を1つのフローで完結できます。

フローオーケストレーション

フローオーケストレーションは、複数のフローやユーザータスクをシナリオとしてつなぎ、順番・条件・担当者を制御できる高度な自動化基盤です。営業・総務・法務など複数部署が関わる承認プロセスや、数週間~数か月にわたる長期プロセスの管理に対応します。

ステップごとに担当者を割り当て、完了状況を追跡できるため、プロセスの見える化にも効果的です。複雑なワークフローを無理なく整理し、業務全体の品質を高めるための強力な機能と言えます。

画面フロー

画面フローは、操作画面をユーザーに提示しながら処理を進める対話型フローです。画面に応じて入力欄・選択肢・ヘルプテキストなどを配置でき、新人や非エンジニアでも迷わず業務を進められるよう案内ができます。

顧客情報のヒアリング支援、問い合わせ対応ガイド、複雑な入力プロセスのミス防止などに幅広く使われます。Lightningページや公開サイトにも埋め込めるため、社内・社外の両方で活用しやすい点も魅力です。

プラットフォームイベントトリガーフロー

プラットフォームイベントトリガーフローは、Salesforce内外で発行されるイベントを契機にリアルタイムで処理を開始できるフローです。外部システムとの非同期連携に強く、たとえばECサイトから送られた注文データを受信して商談を自動作成する、といった使い方ができます。

大量のイベントも効率よく処理できるため、近年のマイクロサービス化したシステム構成に適しています。従来のバッチ処理より早く正確にデータ連携できる点がメリットです。

自動起動フロー(トリガーなし)

自動起動フローは、特定のトリガーを持たず、他のフロー・Apex・ボタン・リンクなどから呼び出して実行するタイプのフローです。共通ロジックをまとめて再利用する用途に適しており、複数のフローから同じ処理を呼び出せるため、保守性が大幅に向上します。

複雑な計算処理、外部API呼び出し、関連レコードの一括更新など、バックエンドで完結させたい処理に最適です。組織全体でロジックを統一し、重複実装を避けられるのもメリットです。

Salesforce フローの作成手順

Salesforce フローは、ノーコード/ローコードで業務プロセスを自動化できる強力な機能です。とはいえ、最初は「どこから手を付ければいい?」と迷いやすいものです。ここでは、フローを新規作成するときの基本的な流れとして、種類の選択・画面上での組み立て・テストという3つのステップに分けて解説します。

フローの種類を選択する

まずは、オブジェクトマネージャーや[設定]画面から「フロー」を開き、「新規フロー」でフローの種類を選択します。代表的なものとして、レコードの作成・更新をトリガーにする「レコードトリガーフロー」、決まった日時に実行する「スケジュールトリガーフロー」、ユーザーが画面操作しながら処理を進める「画面フロー」などがあります。

どのフローを使うかは、「いつ・何をきっかけに・誰の操作で」動かしたいかによって決まります。要件を整理した上で、最も目的に近いテンプレートを選択することが、後の設計をスムーズに進めるポイントです。

要素とコネクタをつなぐ

フローの種類を選んだら、キャンバス上で「要素」を配置し、「コネクタ」でつないで処理の流れを組み立てます。要素には、レコードの作成・更新・削除、条件分岐(決定)、ループ、サブフロー呼び出し、画面表示などがあり、ドラッグ&ドロップで直感的に並べていけます。

処理順序が分かるように、開始要素から終端までのルートを意識してつなぐことが大切です。また、変数やレコード変数を設定しておくと、前の処理結果を後続の要素で参照でき、複雑なビジネスロジックも実現しやすくなります。コメント機能や名前付けルールを使い、後から見ても分かりやすい構成にしておくと保守性も高まります。

動作テストをする

フローの構成ができたら、いきなり本番に有効化するのではなく、必ずテストを行います。フロー画面の「デバッグ」機能を使うと、想定する入力値を与えながら、どの要素がどの順番で実行されたかを確認でき、途中で条件分岐が意図通りに働いているかも追跡できます。

レコードトリガーフローの場合は、サンドボックス環境でテスト用レコードを作成・更新して挙動を検証するのが一般的です。想定外のエラーや無限ループ、権限不足による失敗がないかをチェックし、問題がなければ本番組織で有効化します。運用開始後も、ログやエラー通知を確認しながら、必要に応じて条件や処理内容を微調整していくことが重要です。

Salesforceワークフロールールからフローへの移行方法

Salesforceでは、今後はフローが標準的な自動化手段となる方針が示されており、既存のワークフロールールやプロセスビルダーを計画的にフローへ移行することが重要になります。やみくもに作り直すのではなく、「どの自動化を残すか/統合するか」を整理しながら段階的に移行すると、安全かつスムーズです。ここでは、移行前の棚卸しから実際の移行手順、よくある課題とその対処法までを整理します。

既存ワークフローの棚卸しと移行計画の策定

最初のステップは、現在稼働しているワークフロールールとプロセスビルダーの「棚卸し」です。組織設定から対象オブジェクトごとに、どの条件でどのような処理(メール送信・項目更新・タスク作成など)が走っているかを一覧化し、重複・類似しているものや、すでに使われていないものを洗い出します。これにより、「そのまま移行すべきか」「統合・簡素化できるか」「無効化してよいか」を判断しやすくなります。

次に、「どの自動化からフローに移行するか」という優先順位を決めます。ビジネスへの影響が大きいルール(商談・リード・案件承認など)や、将来的に拡張したい領域から着手すると効果的です。また、本番環境にいきなり手を入れるのではなく、必ずSandbox(試験組織)を用意し、移行・テスト・レビューの流れを標準プロセスとしておくことが、トラブル防止の上で重要なポイントです。

フローへの移行方法・手順

移行作業では、既存のワークフローやプロセスビルダーのロジックを、1つずつフローに置き換えていきます。レコードの作成・更新に連動する自動化であれば「レコードトリガーフロー」を使うのが基本です。トリガー条件(レコード作成時/更新時/特定の条件を満たしたとき)を、元のルールの条件式を参考に設定し、分岐(決定要素)と処理(メール送信・項目更新・レコード作成など)を順番に再現します。

可能であれば、複数のワークフロールールやプロセスビルダーを1つのレコードトリガーフローに統合し、「開始条件+分岐」で整理することで、将来のメンテナンス性が高まります。ただし、一度に統合しすぎると可読性が落ちるため、「オブジェクト×目的」ごとにフローを分けるなどの設計指針を決めておくとよいでしょう。作成後はSandbox環境で挙動確認を行い、テストレコードを使って「元のルールと同じ結果になるか」を比較検証し、問題がないことを確認してから本番環境へデプロイします。

フロー移行時によくある課題と対処法

フローへの移行時によくある課題として、「誰が見ても分かる設計になっていない」「テスト不足で本番で想定外の動きが出る」「パフォーマンスやガバナ制限に引っかかる」などが挙げられます。対処法としては、まずフローの命名規則・コメント・説明文を統一し、「どのオブジェクトの何を自動化しているフローか」が即座に分かるようにしておくことが大切です。また、1つのフロー内で要素を詰め込みすぎず、共通処理はサブフロー化するなど、保守しやすい構成を心がけます。

テスト面では、代表的なパターンだけでなく「境界ケース」(条件ぎりぎりの値、関連レコードがない状態など)も含めて検証し、想定外の分岐や無限ループを起こしていないかを確認します。実行ログやデバッグ機能を活用し、問題があれば早い段階で修正することが重要です。また、移行期間中は古いワークフローと新しいフローが二重に動作しないよう、切り替えタイミングと無効化手順を明確にしておくと、予期せぬ重複更新や通知の多重送信を防げます。こうしたポイントを押さえれば、リスクを抑えながらフロー中心の自動化基盤へ移行していけます。

Salesforceワークフローからフローへの移行ポイントを押さえよう

Salesforceでは、従来のワークフロールールやプロセスビルダーが2025年12月31日にサポート終了予定となり、自動化はフローへの統一が進んでいます。フローは画面付き処理や複雑な分岐・ループ、外部連携などにも対応できる次世代の自動化基盤です。

移行では、まず既存ルールの棚卸しと統廃合方針を整理し、レコードトリガーフローなどで段階的に置き換えます。Sandboxでのテストや命名規則の統一、旧ワークフローとの二重動作防止といったポイントを押さえることで、リスクを抑えつつフロー中心の運用へシフトできます。


※ 掲載している情報は記事更新時点のものです。

※本サイトは、法律的またはその他のアドバイスの提供を目的としたものではありません。当社は本サイトの記載内容(テンプレートを含む)の正確性、妥当性の確保に努めておりますが、ご利用にあたっては、個別の事情を適宜専門家にご相談いただくなど、ご自身の判断でご利用ください。

関連記事