Salesforceフロー（Flow）とは、Salesforce上でデータの取得・作成・更新や画面表示など、業務プロセスを自動化する仕組みです。作成にはポイント＆クリックのFlow Builder（フロービルダー）を使い、キャンバス上で要素をつなぎながら設計できます。外部システムとの処理は、連携でフローに組み込むことができます。
この記事では、フローの意味と主な種類の早見に加え、自社で最初に決める設計判断と、訪問営業の「訪問後に商談／行動を更新したら、条件に応じてフォロー用ToDoを自動作成する」という動きを、起点・エントリ条件・保存後レコードトリガー・レコード作成・デバッグ／有効化・現場での結果まで通して解説します。
本記事は2026年9月13日時点の情報です。機能・提供状況は変更されることがあります。
オススメの資料
UPWARDで成果を出している企業の成功事例をご紹介
資料ダウンロードはこちら
目次
このセクションでは、Salesforceフロー（Flow）の定義を最小限に整理します。定義を押さえたうえで、「最初の1本をどう設計するか」の判断に進みます。
Salesforceサクセスナビでは、フローを「Salesforce組織または外部システムで情報を収集、更新、編集、作成するプロセスを自動化する」ものと説明しています。本記事では主体をSalesforce上の自動化として先に捉え、外部システムは連携によってフローに組み込める範囲とします。作成はFlow Builder（フロービルダー）で、要素（レコードの読み書き・画面表示など）を配置し、コネクタで実行順をつなぎます。
Help「フローの作成」は、自動化するプロセスをモデル化したうえでFlow Builderで設計・作成する流れを案内しています。ワークフロールール／プロセスビルダーからの移行も推奨されていますが、新規の自動化はフローを第一候補にするのが実務の前提です。既存Apex資産との密結合が必要な部分だけ、開発者と分担してApex(Salesforce独自のプログラミング言語によるコード開発)に委譲します。
本記事の中心は「自社ではどれを選ぶか／次に何をするか」の実務判断について解説します。
です。営業業務の自動化の全体像は、次の記事を参照してください。
関連記事>>営業の自動化はどこまでできる？業務別マップと進め方を実務目線でわかりやすく解説
出典>>Salesforceサクセスナビ「日々の定型業務を自動化し時短&効率化！「フロー」を使いこなそう」
出典>>Salesforce Help「フローの作成」
出典>>Salesforceサクセスナビ「ワークフロールールのフローへの移行について」
出典>>Salesforceサクセスナビ「フローへの移行」
このセクションでは、Flow Builderを開く前に自社で決めておく設計判断を整理します。種別や保存タイミングの選択を誤ると、作り直しやToDoの重複作成につながりやすいため、ここが本記事の中心です。
一貫例として、次の業務を想定します。
業務シナリオ
フィールドセールスが訪問後に、商談または行動（Event）を更新する。更新内容が「要フォロー」の条件を満たしたら、フォロー用のToDo（Task）を自動作成し、所有者・期日・関連先をそろえる。
| 問い | 画面フロー（Screen Flow） | レコードトリガーフロー（Record-Triggered Flow） |
|---|---|---|
| 起動のきっかけ | ユーザーがボタン／コンポーネントから起動 | レコードの作成・更新・削除で自動起動 |
| 向くこと | 訪問直後の短い入力ガイド、必須項目の揃え込み | 保存を契機にしたToDo作成・関連更新・通知 |
| 本シナリオでの位置づけ | 結果入力そのものを短くしたいとき補助 | 本編の主役（更新後にToDoを自動作成） |
【実務判断】 「人がボタンを押して進めるか／レコード保存で裏で動かすか」で選びます。本シナリオの主処理はレコードトリガーです。入力率が低い組織では、後述のとおり画面フローを入口に併用する判断もありますが、最初の1本はレコードトリガーに絞ると学習コストが下がります。
出典>>Salesforceサクセスナビ「フロー作成の最初のステップ！フローの種類を学ぶ」
【公式仕様】 レコードトリガーフローには、保存前（UI上は「高速項目更新」）と保存後（「アクションと関連レコード」）があります。保存前はレコードがデータベースに保存される前に実行され、主にトリガーレコード自身の更新・検証向きです。保存後は保存後に実行され、関連レコードの作成・更新やメール送信など、より広いアクションが可能です。保存前ではレコードIDが利用できない場面があり、要素も割り当て・決定・レコードを取得・ループなどに制限されます。
| 観点 | 保存前（高速項目更新） | 保存後（アクションと関連レコード） |
|---|---|---|
| タイミング | 保存直前 | 保存後（ID付与後） |
| 向いていること | トリガーレコード自身の項目補正・検証 | ToDo作成、関連更新、通知など |
| 本シナリオ | 訪問結果の文言補正だけなら候補 | ToDo作成はこちら |
【実務判断】 フォロー用ToDoの作成は、別オブジェクトのレコード作成です。保存前では実現できないため、保存後（アクションと関連レコード）を選びます。「同じレコードを保存前に直すか／保存後に別アクションを打つか」で迷ったら、後者なら保存後、という単純な切り分けで十分です。
出典>>Salesforce Help「保存前と保存後のレコードトリガーフローの決定」
出典>>Salesforce Help「レコードが作成または変更されたときの自動化の開始」
【公式仕様】 更新トリガーでは、「更新されたレコードでフローを実行するタイミング」として、条件を満たすたびに動かすか、条件の要件に一致するようにレコードを更新したときのみ動かすかを選べます。Trailheadのレコードトリガー演習でも、重複作成を避けるために後者を選ぶ理由が明示されています。
【実務判断】 本シナリオでは、すでに「要フォロー」の商談を関係ない項目だけ再保存したときに、毎回ToDoが増えると現場が壊れます。したがって開始条件は条件一致時のみを基本にします。金額や優先度で分岐が必要なら、決定要素を追加しますが、開始条件と決定の両方で「毎回／一致時のみ」の意図がぶれないかをデバッグで確認します。
| 状況 | 第一候補 |
|---|---|
| 条件分岐＋レコード作成・更新で足りる | フロー |
| 複雑なトランザクション制御・既存Apex資産との密結合 | Apex（または自動起動フローとの併用） |
| 再利用したい共通処理だけ切り出したい | 自動起動フロー（Autolaunched Flow） |
【実務判断】 訪問後フォローToDoの1本目は、フローで十分です。ガバナや再利用の都合でコードが必要になった部分だけ切り出します。
| 決めること | 本シナリオの推奨 | 理由（実務判断） |
|---|---|---|
| 種別 | レコードトリガーフロー | 訪問後の保存をきっかけに自動実行したい |
| 最適化 | アクションと関連レコード（保存後） | ToDoという関連レコードを作成する |
| オブジェクト例 | 商談（または行動） | 訪問結果の更新先として現場で触りやすい |
| 実行タイミング | 条件一致時のみ | ToDoの重複作成を防ぐ |
| 主要素 | レコードを作成（＋必要なら決定） | 件名・期日・所有者・関連先をセット |
| Apex | 当面不要 | 定型のレコード作成で足りる |
このセクションでは、前節の判断をそのまま実装イメージに落とし込みます。起点から現場での結果まで、一つの業務例で通します。
【実務判断】 組織によって「要フォロー」の表現は異なります。ここでは再現しやすい例として、次をエントリ条件にします（カスタム項目名は自社に合わせて読み替えてください）。
行動（Event）を起点にする場合も同じ考えです。訪問予定の行動を「完了／結果入力」したタイミングで、関連商談または取引先向けのフォローToDoを作る、という設計に読み替えられます。
活動オブジェクト（ToDo／行動）そのものの設計やEinstein活動キャプチャ（EAC）との関係は、次の記事で解説しています。
関連記事>>Salesforceの活動とは？ToDo・行動との違いと記録・設定の方法
出典>>Salesforce Help「レコードが作成または変更されたときの自動化の開始」
キャンバス上の最小構成は次のとおりです。
【公式仕様＋実務判断】 サクセスナビの「レコードを作成」解説では、トリガーレコードを起点にToDoを1件作るパターンが示されています。本シナリオ向けの項目例は次です。
| ToDo項目 | 設定例 | ねらい |
|---|---|---|
| 件名（Subject） | 「【訪問後フォロー】」＋商談名 など | 一覧で目的が分かるようにする |
| 状況（Status） | Not Started（未着手） | 未着手で渡す |
| 優先度（Priority） | 決定結果、または固定値 | 緊急度のばらつきを抑える |
| 期日（ActivityDate） | Flow.CurrentDate＋数日、または「次回アクション日」 | 期日なしToDoを増やさない |
| 割り当て先（OwnerId） | Record.OwnerId | 商談所有者に寄せる（マネージャへ振る判断も可） |
| 関連先（WhatId） | Record.Id | 商談の活動タイムラインに載せる |
【実務判断・落とし穴】
出典>>Salesforceサクセスナビ「レコードを作成」
出典>>Salesforce Help「Flow Builder の概要」
【実務判断】 デバッグで通っても、実行ユーザのオブジェクト／項目権限不足で本番だけ失敗することがあります。Sandboxでの再現と、プロファイル／権限セットの確認をセットにしてください。有効化したフローを削除するには、先に無効化する必要があります。
出典>>Salesforceサクセスナビ「日々の定型業務を自動化し時短&効率化！「フロー」を使いこなそう」
このセクションでは、百科的なクリック解説ではなく、前節の一貫例を再現するための最小手順に絞ります。詳細UIは公式Helpの「フローの作成」「Flow Builderの概要」をご確認ください。
画面フロー（Screen Flow）で「訪問結果入力そのもの」を短くしたい場合は、別フローとしてクイックアクションに置き、画面の値で商談更新とToDo作成を一連で行う設計に拡張できます。最初の1本はレコードトリガーに閉じた方が、失敗原因の切り分けが容易です。
出典>>Salesforce Help「フローの作成」
出典>>Salesforce Help「Flow Builder の概要」
このセクションでは、SEO上よく求められる「種類」を短い早見表に圧縮します。詳細な種別百科ではなく、きっかけから選ぶための索引として使ってください。
| やりたいこと | おすすめの種別 | 本シナリオとの関係 |
|---|---|---|
| 訪問直後に短い入力フォームを出したい | 画面フロー（Screen Flow） | 入口の補助（任意） |
| 商談／行動の更新を契機にフォローToDoを作りたい | レコードトリガー・保存後 | 本編 |
| 保存前に必須項目や値を補正したい | レコードトリガー・保存前 | ToDo作成には使わない |
| 毎朝、条件に合うレコードを一括処理したい | スケジュールトリガーフロー（Schedule-Triggered Flow） | 未着手フォローの洗い出しなどに後から検討 |
| 他フローやApexから共通処理を呼びたい | 自動起動フロー（Autolaunched Flow） | 共通化が必要になったら |
| イベント連携で複数処理を動かしたい | プラットフォームイベントトリガーフロー（Platform Event-Triggered Flow） | 発展形 |
出典>>Salesforceサクセスナビ「フロー作成の最初のステップ！フローの種類を学ぶ」
このセクションでは、一貫例を運用したあとに残りやすいギャップと、補完の考え方を整理します。フローの置き換えではなく、標準自動化が効くための前提データの話です。
レコードトリガーは、「CRM上でレコードが更新されたあと」の自動化が得意です。本シナリオも、訪問結果が商談／行動に入力されて初めて動きます。
次のような点は、標準フローだけでは埋まりにくいことがあります。
標準フローで「条件がそろったあとのToDo・画面入力」を固めたうえで、訪問や活動の蓄積そのものを補う連携を並行検討する、という分け方が現実的です。UPWARDのSalesforce連携では、フィールドセールス向けに訪問や活動をSalesforceへ寄せる構成が紹介されています。フローの代替ではなく、本シナリオのエントリ条件が現場で成立しやすくするためのデータ前提を整える位置づけです。
関連記事>>CRMへの登録が面倒？Salesforceを”自動更新するAIエージェント”という選択肢
このセクションでは、一貫例を本番運用したときに起きやすいつまずきを、運用判断として整理します。
原因の多くは、開始条件の「毎回／条件一致時のみ」の取り違えです。動かなすぎる場合は、エントリ条件が現場の入力語彙と一致していない（例：選択リスト値の表記ゆれ）ことが多いです。デバッグでは「満たすケース」と「満たさないケース」の両方を残してください。
関連レコード作成は保存後の領域です。Helpの対比に戻り、最適化を「アクションと関連レコード」に切り替えてください。
出典>>Salesforce Help「保存前と保存後のレコードトリガーフローの決定」
権限、共有ルール、割り当て先ユーザの違いが典型です。画面フローを併用する場合は、有効化だけでなくLightningページ／クイックアクションへの配布までがセットです。
フォローはToDo、訪問予定は行動、という役割が組織内で揃っていないと、フローの関連先やレポート母数がずれます。オブジェクト設計の深掘りは活動の解説記事に委譲し、フロー側は「どの更新をきっかけに、どのToDoを作るか」に集中してください。
このセクションでは、読み終わったあとに取る行動をチェックリストにします。公式ページの要約ではなく、自社での次の一手を決めるための一覧です。
まずは保存後の小さなレコードトリガー（フォローToDo）1本から始めるのが現実的です。
このセクションでは、検索やAI要約で拾われやすい疑問に短く答えます。用語は各質問で正式名称を示します。詳細は本文の各節と公式Helpを参照してください。
Salesforceフロー（Flow）は、業務プロセスを自動化する仕組みそのものです。Flow Builder（フロービルダー）は、そのフローをポイント＆クリックで設計・作成・編集するためのツールです。フローが「成果物」、Flow Builderが「作る場所」と捉えると分かりやすいです。
出典>>Salesforce Help「Flow Builder の概要」
ユーザーが画面で入力・確認しながら進めたいなら画面フロー（Screen Flow）です。レコードの作成・更新・削除をきっかけにバックグラウンドで動かしたいならレコードトリガーフロー（Record-Triggered Flow）です。本記事の訪問後フォローToDoは、原則レコードトリガーです。
出典>>Salesforceサクセスナビ「フロー作成の最初のステップ！フローの種類を学ぶ」
保存前のレコードトリガーフロー（高速項目更新）は、レコードがデータベースに保存される前に実行され、主にトリガーレコード自身の更新・検証向きです。保存後（アクションと関連レコード）は保存後に実行され、関連レコードの作成・更新やメール送信などが可能です。ToDo自動作成は保存後を選びます。
出典>>Salesforce Help「保存前と保存後のレコードトリガーフローの決定」
Salesforceは、ワークフロールールおよびプロセスビルダーからフローへの移行を推奨しています。移行ツールやサクセスナビの移行ガイドが公開されています。既存設定のサポート範囲は時期により変わるため、最新の公式案内を確認し、新規自動化はフローで設計してください。
出典>>Salesforceサクセスナビ「フローへの移行」
出典>>Salesforceサクセスナビ「ワークフロールールのフローへの移行について」
はい。Flow Builderはポイント＆クリックで要素を配置・接続するツールであり、多くの定型自動化はコードなしで作成できます。複雑なロジックや既存Apexとの連携が必要な部分だけ、開発者と分担するのが一般的です。
デバッグでの正常実行、エントリ条件の再実行タイミング（毎回／条件一致時のみ）、保存前／保存後の選択、実行ユーザの権限、画面フローの配布先（ページ／アクション）を確認してください。本番前はSandbox検証を推奨します。有効化後に削除する場合は、先に無効化が必要です。
Q: 訪問営業の活動記録もフローだけで自動化できますか
レコードが更新されたあとのToDo作成や、画面フローによる短い入力支援まではフローが得意です。一方、訪問そのものの検知や、移動中の記録を自動でCRMに寄せる部分は標準フローの外側になりがちです。活動オブジェクトの詳細は活動の解説記事を参照し、現場データの蓄積はUPWARDのSalesforce連携のような補完も検討対象にしてください。
関連記事>>CRMへの登録が面倒？Salesforceを”自動更新するAIエージェント”という選択肢
