【2025年対応必須】Salesforceワークフロールールが廃止！ワークフロー自動化の基本とフローへの移行方法を徹底解説

Salesforceでは業務の標準化やミスの削減、生産性向上を目的としたワークフロー自動化機能が広く利用されています。なかでも「ワークフロールール」と「プロセスビルダー」は、Salesforce初心者から上級者まで多くのユーザーにとって欠かせない自動化ツールでした。

しかし、これら2つの機能は2025年12月にサポートが廃止されることが決定しています。今後はより高度な自動化機能を備えた「Flow（以下：フロー）」への移行が必須となります。

本記事ではSalesforceワークフローの基本を知りたい、ワークフロールール・プロセスビルダーの違いを知りたい、サポート廃止に向けてフローへの移行方法を知りたいという方向けの情報をまとめていますので、ぜひ最後までご一読ください。

後継機能であるフローについてはこちらの記事で詳しく解説しています。

参照：Salesforceフローとは？基本機能からレコードトリガフローの使い方も具体例と一緒に徹底解説！

Salesforce ワークフローとは？自動化の基本を解説

ワークフローでの自動化とは何か？

ワークフローでの自動化とはSalesforce内で発生する業務イベント（レコード作成・更新など）に応じて、メール通知・タスク作成・ステータス更新などの処理を自動で実行する仕組みです。人手によるミスを防ぎ対応の抜け漏れをなくすことができるため、業務効率化に大きく貢献します。

例えば次にあげるような処理を人が操作しなくても自動で行えるようになります。

• 商談のステータスが「見積提出」に変わったら自動で営業マネージャーに通知を送信
• リードのスコアが一定値よりも高くなったら、自動でフォロータスクを作成し担当者が抜け漏れなく対応する
• 顧客の契約満了日が近づいたら、アラートを表示して更新案内を送付

Salesforceで提供されてきた3つの自動化機能

Salesforceでは2025年4月現在、3種類のワークフロー自動化機能が提供されています。

ワークフロールール

Salesforce初期から存在するシンプルな自動化機能です。ルール条件に合致したときに、メール送信やフィールド更新などのアクションを自動で実行できます。

プロセスビルダー

複数条件・複数アクションを一連のプロセスとして構成できる機能です。1つのプロセス内で分岐や順序をつけて複雑な処理が可能となります。

フロー

Salesforceが現在推進する最も高機能な自動化ツールです。条件分岐やループ、外部連携、ユーザー画面の表示も含む複雑な業務ロジックを実装できます。今後はこのフローに一本化されます。

Salesforceワークフロールールの基本とできること

Salesforceのワークフロールールは、業務フローの一部を自動化する最もシンプルなツールとして長年利用されてきました。ここでは、ワークフロールールでできることや主なアクションについて分かりやすく解説します。

ワークフロールールでできること

ワークフロールールはSalesforce内で特定の条件に合致したレコードが保存されたときに、あらかじめ定義したアクション（通知・更新など）を自動実行する機能です。

例えば「商談ステータスが“承認待ち”になったら、営業マネージャーにメール通知を送る」「リードが一定条件を満たしたら、フォローアップタスクを自動作成する」といった業務フローを簡単に構築できます。

設定したルールに一致した場合のみ処理が実行されるため、無駄なアクションの発生を防ぎながら精度の高い自動化が可能です。

ワークフロールールの主なアクション種別

ワークフロールールでは、以下の4つのアクションタイプを設定できます。

• フィールド更新：指定した項目の値を自動的に変更します（例：ステータスを「対応済」に更新）。
• タスク作成：フォローアップや確認業務などのタスクを自動で作成し、指定ユーザーに割り当てます。
• メール通知：定型文のメールテンプレートを使用して、関係者に即時通知を送信します。
• アウトバウンドメッセージ：外部システムへAPIを通じてデータを送信します（システム連携に活用）。
  

いずれも繰り返し発生する定型業務において人的ミスや対応遅れを防ぎ、業務のスピードと品質を向上させることができます。

Salesforceのワークフロールールとプロセスビルダーの違いとは？

同じく2025年12月31日をもってサポートが終了となる機能にプロセスビルダーがあります。プロセスビルダーはワークフロールールよりも機能が拡張された自動化ツールです。両者は似ているようで操作性や処理の幅に明確な違いがあります。

UIと操作性の違い

ワークフロールールは設定項目がテキストベースであるのに対し、プロセスビルダーは視覚的なキャンバス上でのドラッグ＆ドロップ操作で設計できます。フロー全体の見通しが良いため、複数条件・アクションのあるプロセス設計にも適しています。

条件分岐の有無

ワークフロールールでは1ルールにつき1条件＋1アクション群という構造でしたが、プロセスビルダーでは1つのプロセス内に複数の条件分岐と処理パスを設定できます。そのため、1つのプロセスで複数のユースケースを管理できるという柔軟性があります。

アクション数の柔軟性

プロセスビルダーでは、レコード作成や投稿処理、他プロセスの起動など、ワークフロールールよりも多様なアクションに対応しています。また、既存レコードの関連項目に対してもアクションを起こせるなど活用の幅が広がります。

処理タイミング（即時 or 遅延実行）

ワークフロールールは基本的にレコード保存時に即時実行されますが、プロセスビルダーでは即時アクション/時間ベースの遅延アクションを選べるため、より複雑な業務フローにも対応できます。

【重要】ワークフロールール・プロセスビルダーは2025年12月にサポート廃止される

2025年12月をもってワークフロールールとプロセスビルダーは正式にサポートが廃止される予定です。そのためすべてのユーザーに対してフローへの移行が求められます。今後の機能維持や運用トラブルを避けるためにも、スケジュールを把握し早期に対応を進めることが重要です。

公式発表の概要とスケジュール

Salesforceは以下のような段階的なスケジュールでワークフロールールとプロセスビルダーの廃止を進めています。

• 2023年以降：新機能開発の停止
  ワークフロールール・プロセスビルダーへの新機能追加は停止され、新規開発はフローに一本化されました。
  
• 2025年初頭：新規作成が不可に
  新しいワークフロールールやプロセスビルダーは作成できなくなり、既存のルールの閲覧・編集のみに制限されます。
  
• 2025年12月31日（予定）：サポート廃止
  既存のワークフロールールとプロセスビルダーへのサポートが終了されます。これ以降、ワークフロールールやプロセスビルダーで作成されたフローは動作に問題が出てもサポートが終了するため、解決が難しく、業務への影響が出る可能性があります。

参照：ワークフロールールとプロセスビルダーのサポート終了

このタイムラインはあくまで現時点の予定であり、今後Salesforceからの最新情報にも注意を払いましょう。

なぜワークフロールールは廃止されるのか？

メンテナンス性の課題

ワークフロールールやプロセスビルダーは長年使われてきた反面、処理の分散化や仕様の重複が起きやすく、運用面でのメンテナンス性に課題がありました。

例えば、似たような処理がワークフローとプロセスビルダーでそれぞれ作成されてしまい、どちらが実行されたのか把握しづらくなるなど、トラブルの要因になるケースが少なくありませんでした。

フローへの一本化と拡張性の向上

Salesforceは、これらの課題を解決するためにすべての自動化を「フロー」へ統一する方針を打ち出しています。フローは、以下の点で旧機能より優れた特性を持ちます。

• 複雑な条件分岐やループ処理が可能
• API連携やApexコードとの統合にも対応
• 画面操作やユーザー入力を含む対話型の処理も構築可能
• ガバナンス・エラーハンドリング機能の充実

フローはこれまでの機能を包含しつつ、より高度かつ柔軟な自動化を実現できる次世代標準ツールになっています。

このような背景から、Salesforceは旧機能であるワークフロールールの段階的廃止とフローへの全面移行を推進しています。次のセクションでは、フローの特徴とメリット、そして移行の方法を詳しく解説します。

Salesforce フローとは？次世代の自動化ツールの基本とメリット

フローは、これまでのワークフロールールやプロセスビルダーでは実現が難しかった高度な処理をノーコード/ローコードで構築できる次世代の自動化ツールです。

フローの特徴と機能

フローが従来の自動化ツールと大きく異なるのは、その柔軟性と拡張性の高さにあります。

複雑な条件分岐やループ処理

 一連の処理の中で条件に応じて処理内容を切り替えたり、複数のレコードに対して繰り返しアクションを実行したりすることが可能です。さらに「該当レコードをすべて順に処理する」といったループ処理も組み込めるため、例えば「商談に関連するすべての商品レコードを1件ずつチェックし、合計金額を算出する」「顧客アンケートで特定の回答をしたユーザーだけに別の処理を実行する」といった処理が実現できます。

ユーザーとのインタラクションを含めた画面フロー

画面フローは、ユーザーに入力や選択を求めながら処理を進めるインタラクティブなフローです。例えば営業担当が商談を登録する際、入力ステップを順番にガイドするウィザード形式のフローを提供したり、サポート担当者が質問に答えていくだけで適切な対応方法が自動で提示される仕組みを作ることができます。業務の抜け漏れや属人化を防ぎ、標準化を進めることができます。

外部システムとの連携（API連携、Apex呼び出し）

Salesforce内の処理だけにとどまらず、HTTPリクエストを利用して外部のAPIと通信することで、社外システムとのデータ連携も可能です。例えば社内チャットツール（SlackやTeams）への通知送信、在庫管理システムとの連携、Webサービスから情報を取得してSalesforceに反映するといった処理を自動フローの中に組み込むことができます。さらにより高度な処理が必要な場合には、開発者が作成したApexクラスを呼び出すこともできます。

ワークフロールール/プロセスビルダーの上位互換

これまで使われてきたワークフロールールやプロセスビルダーが行っていた処理をすべて再現可能であり、事実上その完全な上位互換といえます。フィールド更新やメール送信、タスク作成といった基本的な処理はもちろん、複数条件の組み合わせ、時間ベースのアクション、条件による分岐など、これまで以上に複雑なロジックにも対応できます。

フローの種類（オートメーション設計の柔軟性）

フローにはさまざまな種類があり、業務内容や処理タイミングに応じて使い分けが可能です。

レコードトリガーフロー

特定のオブジェクトでレコードが作成・更新・削除されたタイミングで、条件に応じた処理を自動的に実行できます。例えば「新規リードが作成されたら担当営業に通知」「商談のステージが変わったらフォロータスクを自動生成」といった処理が可能で、これまでワークフロールールやプロセスビルダーで対応していた業務を代替できます。

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

「毎朝8時に未対応タスクを洗い出して通知」「月末に請求データを自動で集計」といった毎日や週次など、あらかじめ決めた時間に定期実行される自動化処理を設定できます。ルーティンワークの自動化や、時間ベースのデータチェックなど業務効率化に寄与します。

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

 複数のフローや承認プロセスを組み合わせて、段階的に処理を進める必要があるより複雑なワークフローを構築できます。一連の業務を1つのストーリーとしてつなぐことができるため、複雑なシナリオを分かりやすく自動化できるのが大きな特長です。

■例：システム不具合の対応フロー（ITサービス企業の場合）

例えばITシステムを提供している企業で、顧客から「システムに不具合が発生した」という連絡を受けたケースを考えてみましょう。

フローオーケストレーションを使えば、以下のような部門横断の一連業務を1つの流れとして自動化できます。

1.カスタマーサポートが「ケース」を作成（ユーザー操作 or トリガー）
2.フローにより、システム部門に対して自動で調査依頼を通知
3.システム部門が対応を完了すると、マネージャーが結果を確認・承認
4.承認が下りたら、カスタマーサポートに処理完了通知が戻り、顧客に連絡

このように、複数部門をまたぐ複雑な業務フローを分かりやすくシナリオとして構築・制御できるのがフローオーケストレーションの強みです。

画面フロー

 画面フローは、ユーザーがSalesforce画面上で操作しながら進めるタイプのフローです。たとえばデータ登録ウィザードや、申請フォーム、選択肢によって処理が分岐するナビゲーションなど、ユーザー体験を重視した業務フローに適しています。

	ワークフロールール	プロセスビルダー	フロー
操作画面	テキストベースの設定画面	ビジュアルキャンバス	ビジュアルキャンバス＋詳細設定
条件分岐の有無	なし（1条件のみ）	あり（複数条件・パス）	あり（高度な分岐・ループ処理対応）
対応アクション数	少（主に通知・フィールド更新）	中（投稿処理・関連レコード更新など）	多（すべてのアクションに対応）
画面操作の自動化	不可	不可	可能（スクリーンフロー）
外部システム連携	一部可能（アウトバウンドメッセージ）	一部可能（連携オプションあり）	可能（API・Apex連携）
開発スキルの必要性	不要	基本不要	ケースによって必要
将来的なサポート	2025年に廃止予定	2025年に廃止予定	今後の標準機能として推奨

Salesforceフローについて詳しく知りたい方はこちらの記事をご覧ください。

参照：Salesforceフローとは？基本機能からレコードトリガフローの使い方も具体例と一緒に徹底解説！

Salesforceワークフロールールからフローへの移行方法と注意点

フローへの移行は単なる置き換え作業ではなく、既存プロセスの見直しと最適化のチャンスでもあります。移行計画を立て順を追って進めましょう。

現行ワークフローの棚卸しと移行計画

まずは現在運用しているワークフロールールやプロセスビルダーを一覧で把握し、何がどのように動いているのかを可視化します。

Salesforceの「設定」画面の左側にあるクイック検索機能を利用し、「ワークフロールール」や「プロセスビルダー」と入力して該当するページを開き、それぞれの詳細画面から既存のルールやプロセスの一覧を確認します。そのうえで、すでに使用されていないルールや似たような条件・アクションが重複して設定されていないか、あるいは処理内容が複雑すぎて業務に対して非効率になっていないかを整理していきます。

さらに、すべてのワークフローを一括で移行するのではなく、業務への影響度を基準に優先順位を付けながら計画的に対応していくことが大切です。例えば、営業活動や顧客対応に直結するようなルールは優先的に移行対象とし、影響が比較的少ないプロセスは後回しにするなど、段階的に進めることが理想的です。

この棚卸し作業が移行の成否を左右するため、関係部門と連携しながら慎重に進めることが大切です。

フローへの移行手順

Salesorceでは「フローに移行」ツールが提供されており、プロセスビルダーやワークフロールールからフローへの移行を効率的に進めることが可能です。以下に実際の画面操作に基づいた具体的な手順を紹介します。​

1.Salesforceの「設定」画面を開き、左側のクイック検索で「フローに移行」と検索を行います。​結果に表示された「フローに移行」をクリックします。

2.「フローに移行」ツールを起動

「フローに移行」では今までに作成されたワークフロールール、プロセスビルダ―が一覧で表示されます。この中でフローに移行したい対象を選択し、右側の​「フローに移行」というボタンをクリックします。

3.フローへの移行を実行するとポップアップ画面が表示されます。移行が完了すると、移行したフローを確認するための「Flow Builderでテスト」、作成されたフローを有効化する「有効化を切り替え」のボタンが表示されます。

まずは、自動作成されたフローがもともとのワークフローの内容を反映しているのか「Flow Builderでテスト」をクリックし、フローが想定した内容で作成されたのかデバッグを行い、確認します。

4.デバッグで挙動の確認が終わったら元の画面に戻り、「有効化を切り替え」をクリックし、フローの有効化ともともとのワークフロールール、プロセスビルダーの無効化を行います。

フロー移行ツールで移行できないよくある理由

「フローに移行」ツールは非常に便利ですが、すべてのプロセスを変換できるわけではありません。以下のよくある移行できない理由に当てはまる場合、ツールでの変換ができず手動でフローを構築し直す必要があります。

他のプロセスビルダーを呼び出している場合

プロセスAの中でプロセスBを呼び出すような、プロセス内で「別のプロセスを呼び出す」設定があると、ツールでは変換できません。意図しない処理の重複や、依存関係のトラブルを引き起こす可能性があるからです。呼び出し元・呼び出し先のロジックを統合して1つのフローとして再構築するなど工夫が必要です。

カスタム通知を送信している場合

 標準の通知ではなく、通知テンプレートを指定しカスタム通知を利用しているアクションはフローに移行ツールで移行することができません。移行ツールがカスタム通知の中の構成を確認しに行くことができないため、カスタム通知の内容をフローに取得させ、通知を送信するアクションを手動で構築する必要があります。

参照：カスタム通知をフローで送信する方法

Chatter投稿のアクションがある場合

ワークフロールールやプロセスビルダ―でChatterへの自動投稿を行っている場合、フローにはChatter投稿を行うアクションが用意されていないため、移行ツールでは変換できません。ApexクラスでChatter投稿を実装する。または、Chatter以外の通知手段（リッチ通知やメールなど）に切り替えるなど通知方法を変更することも検討してください。

クロスオブジェクト参照が含まれる場合

 例えば商談（子）レコードから取引先（親）レコードのフィールドを参照して条件設定している場合などの場合、移行ツールは1つのオブジェクトの範囲内でしか自動変換できないため、処理できず変換に失敗します。親レコードの値を取得するようにフローを手動で構築する必要があります。

承認申請を含む場合

 プロセスの中である条件を満たしたら自動で「承認申請を作成」するような構成は移行ツールでの変換対象外となります。フローの中で「承認リクエストを作成」アクションを手動で追加してください。

「条件を満たしている」のなかで数式を条件に使っている場合

 実行条件として「以下の条件を満たしている」で、その条件に数式を直接書き込んでいるケースも変換ができません。例えば、「スコアが70以上で、かつステータスが“未対応”」を数式であらわし、この数式を「以下の条件を満たしている」に設定しているプロセスです。

AND(

  ISPICKVAL([Lead].Status, "未対応"),

  [Lead].Score__c > 70

)

フローでは条件を1つずつ設定する必要があり、直接このような数式を記述することはできません。プロセスのなかで複雑な条件を数式を使って構築している場合、分解して設定しなおす必要があります。

「再評価にチェック」を入れている場合

 プロセスの中でレコード更新後に再度自動評価をさせる設定がONになっているプロセスは、フローには再評価という設定は存在せず、移行ツールで自動移行することはできません。再評価が必要な条件を満たす場合は、「ループ」や「条件付きサブフロー」などフロー内で実現可能な形に設計しなおす必要があります。

これらのケースに該当するプロセスは、手動でフローを再構築する必要があります。対象のプロセスが自動変換可能かどうかは事前に一つひとつ確認し、必要に応じて手動で再構築する準備を進めておくことが移行成功のカギとなります。

まとめ

Salesforceのワークフロールールとプロセスビルダーの廃止に伴い、今後は「フロー」が業務自動化の標準機能となります。旧機能をそのまま放置していると、将来的に業務停止やデータ処理ミスといったリスクを招きかねません。今から計画的に移行を進めることで、運用上のトラブルを未然に防ぎ、より高度な業務自動化を実現することができるでしょう。

フローを活用した自動化の設計・構築について不安がある場合は、Salesforce導入支援の専門パートナーに相談するのも一つの選択肢です。ワークフローの再設計から移行支援、運用定着までを伴走型でサポートすることで、移行後も安心してSalesforceを活用できます。

ストラではワークフローやプロセスビルダーのフローへの移行はもちろん、Salesforceの導入や外部システム連携など、現場への定着化支援やチェンジマネジメントまで一貫したSalesforce活用をご支援します。

具体的な支援内容や価格についてご興味・ご関心がある方は、ぜひストラへお問い合わせください。

また、ストラのSalesforce導入支援や定着化支援、開発支援について、さらに詳しく知りたい方はこちらのページで紹介しています。

• Salesforce導入支援
• Salesforce定着化・活用支援
• Salesforce開発・システム連携支援