Salesforceの承認プロセスは、レコードを「誰が・どの条件で・何が起きたら終わるか」をあらかじめ決め、申請から最終承認・却下までを同じレコード上で回す仕組みです。
訪問営業では、値引きの口頭確認がマネージャーとのあいだでボトルネックになりがちです。稟議をメールではなくレコード上の経路に乗せると、承認待ちの所在が見えるようになります。
この流れを例に、Salesforceの承認プロセスの定義、フローとの違い、訪問営業チームが最初に組む設計、作り方の順序、外出先での承認、つまずき、訪問記録とのつなぎまでを整理します。設定を自分で触らない訪問営業チームの方でも、依頼時にどんな設定を依頼するかが明確になるように紹介します。
本記事は2026年9月21日時点の情報です。画面ラベル・権限名・エディション表記は変更されることがあります。最新はSalesforce Helpおよび自組織の承認プロセス（Approval Process）画面でご確認ください。
オススメの資料
UPWARDで成果を出している企業の成功事例をご紹介
資料ダウンロードはこちら
目次
Salesforce承認プロセス（Approval Process）とは、組織でのレコード承認方法を自動化する機能です。エントリ条件、承認ステップ、各ステップの承認者、申請時・承認時・却下時などのアクションを指定し、申請から最終結果までを一連の経路として動かします。
Trailheadでは、承認の方法をあらかじめ定義し、レコードが条件に入ったときにその経路へ乗せる、と説明されています。
申請が始まると、既定では対象レコードがロックされます。承認者や管理者は、編集可否の設定に応じてレコードを編集できますが、申請者側は途中で割引率や条件を勝手に書き換えにくくなります。
承認ステップでは「誰が判断するか」を順番に置き、最終承認アクションや最終却下アクションで項目更新、メールアラート、ToDo作成、アウトバウンドメッセージ、フロー起動などを走らせられます。
設備メンテナンス会社のフィールドセールスチームで、訪問先で値引き案が固まった商談を起点にした例で解説します。担当が割引率を更新して承認申請し、所有者のマネージャーが承認または却下する。最終承認で「承認済み」などの状況項目を更新し、却下なら理由を残して再交渉に戻す。
稟議の経路と結果が商談レコードに残るため、後から「いつ誰が通したか」を追えます。メールのスレッドを探す必要がなくなり、次の訪問前の確認も短くなります。
承認プロセスが使えるのは、Enterprise、Performance、Unlimited、Developerなどのエディションが中心です。設定には「アプリケーションのカスタマイズ」権限が必要です。訪問営業チームが依頼する側でも、この前提を知っておくと、情シスや管理者への依頼が具体になります。
値引き稟議を「メールの習慣」から「レコード上の経路」に移すだけで、承認待ちの所在が可視化され、滞留の会話が短くなります。
出典>>Salesforce Trailhead「承認について（Guide to Salesforce Record Approval Processes）」
承認プロセスとフロー（Flow）は、どちらも業務を自動化しますが、主に答える問いが違います。承認プロセスは「誰がこのレコードを承認するか」を経路として決めます。フローは「レコード操作や画面入力をどう自動で進めるか」を組み立てます。
同じ自動化という言葉でも、現場の困りごとが稟議なのか、入力後の後続処理なのかで選ぶ道具が変わります。
| 観点 | 承認プロセス | フロー |
|---|---|---|
| 主な問い | 誰が承認するか | レコード操作をどう自動化するか |
| 例 | 割引率が閾値を超えた商談をマネージャーへ | 訪問後にフォローのToDoを自動作成 |
Spring ’25以降では、フロー承認プロセスという、フロー側で承認経路を組む選択肢も増えています。クラシックの承認プロセスと機能範囲は重なりますが、できること・できないことのセットは一致しません。
値引き稟議のように「誰が何段階で通すか」がはっきりしている経路は、従来の承認プロセスのまま組む判断も実務では多いです。
フロー承認プロセスの詳細手順やオーケストレーション設定はここでは扱いません。境界だけ押さえて、実装の深掘りは必要になった時点で別途確認してください。
訪問後のフォローToDo作成や画面入力の自動化は、フローの記事で解説しています。
出典>>Salesforce Trailhead「承認について（Guide to Salesforce Record Approval Processes）」
関連記事>>Salesforceフローとは？種類と作り方を訪問営業の自動化例で解説
訪問営業チーム向けの承認プロセスに、最初から合議や多段承認を全部載せると、設定も現場の運用も重くなります。先に組むなら、値引き・特別条件の1本に絞るのが現実的です。
稟議が本当に止まる場面は、多くの場合「割引率や特別条件を誰が通すか」に集中しているからです。
オブジェクトは商談を想定します。エントリ条件は、割引率が一定以上、または特別条件フラグがオン、のどちらか（あるいは両方）です。TrailheadのJump Start例でも、割引率が40％を超える商談をマネージャーへ回す、という形がよく使われます。
承認者は商談所有者のマネージャーを基本にし、代理承認が必要な組織では代理人も許可します。最終承認・最終却下のアクションでは、状況項目の更新と通知（メールアラートなど）を最低限そろえます。
設備メンテナンスの現場では、割引率40％超ならマネージャー承認、という一本を先に有効化し、運用が回ってから合議や二段承認を足す順が扱いやすいです。最初から全部を完成させようとするより、申請とモバイル承認が日常で動く状態を先に作るほうが、現場の納得も早いです。
特別条件フラグだけ先に動かし、割引率の閾値は翌四半期に足す、という分け方でも構いません。訪問営業チームが「この条件なら申請する」とルール化できる粒度に落とすことが先です。
閾値やフラグの定義が曖昧なまま有効化すると、申請すべきでない商談まで経路に乗ったり、逆に申請漏れが起きたりします。条件文は短く、例外は運用メモに残すほうが現場は動きやすいです。
出典>>Salesforce Trailhead「承認プロセスを最適化する（Optimize Approval Processes）」
承認プロセスの作り方の順序は、準備、ウィザードでの骨格作成、承認ステップ、最終アクション、有効化、の流れで進めるのが安全です。Jump Startウィザードや標準ウィザードに沿った手順です。
この順序は作り方そのものの順序であり、業務上の優先順位の話ではありません。
準備では、対象オブジェクト（商談）に割引率や特別条件の項目があること、ユーザーにマネージャー項目が入っていること、申請後に更新したい状況項目の値を決めておくことを確認します。
割引率の項目名や単位（パーセントか小数か）が現場と管理者で食い違っていると、エントリ条件が意図どおり動きません。先に項目定義を揃えてください。
設定から承認プロセスを開き、オブジェクトを選んでJump Startまたは標準ウィザードを起動します。エントリ条件（例: 割引率が40％より大きい）、承認者、メールテンプレートなどを指定し、骨格を作ります。
Jump Startは最短で動く経路を作る向き、標準ウィザードはステップやアクションをより細かく指定する向きです。訪問営業チームが最初の1本を依頼するなら、Jump Startで骨格を出し、足りない部分だけ標準側で足す依頼でも十分です。
続いて承認ステップで承認者を確定し、最終承認アクションと最終却下アクションに項目更新や通知を足します。ページレイアウトやLightningの動的アクションに「承認申請」を置き、担当が商談画面から申請できるようにします。
申請ボタンを押し忘れるケース向けに、レコードトリガーのフローアクション「承認申請」で自動申請するやり方もあります。フロー側の組み立てはフローの記事を参考にしてください。
最後にプロセスを有効化します。有効化前に、テスト用ユーザーで申請から承認、却下まで一度通すと、現場投入後の手戻りが減ります。却下時の状況値やコメント必須の有無も、この段階で決めておくと、マネージャー側の迷いが減ります。
有効化後にエントリ条件だけを頻繁に変えると、どの版のルールで通ったか追いにくくなるため、変更は四半期単位など区切りを決めておくのも一つのやり方です。
出典>>Salesforce Trailhead「承認プロセスを最適化する（Optimize Approval Processes）」
出典>>Salesforce Help「標準ウィザードを使用した従来の承認プロセスの作成」
関連記事>>Salesforceフローとは？種類と作り方を訪問営業の自動化例で解説
訪問営業チームのマネージャーは、デスクにいる時間より外出や移動の時間のほうが多いことがあります。承認プロセスで申請されたレコードは、モバイルの承認ナビや、ホームの未承認申請から確認し、承認または却下を返せます。
メールやChatter経由の応答オプションがある組織もあります。
設備メンテナンスの営業チームの例では、担当が訪問直後に商談を更新して申請し、マネージャーが移動中のスマートフォンで割引率とコメントを見て返す、という動きになります。
顧客の前で本日中に社内確認しますと約束したあと、帰社を待たずに返答できるかどうかが、次の訪問の約束にも影響します。未承認の一覧に自分の件が出ているかを、移動の合間に一度見る習慣にすると、滞留が減ります。
権限やレコードへのアクセス権がないと、未承認の一覧に出ないことがある点だけは先に押さえてください。承認者に指名されていても、共有設定で商談が見えないと処理できません。
外出先での1日のアプリ動線の深掘りは、Salesforceアプリの記事で解説しています。通知メールだけを見て承認したつもりになり、実際は未処理のまま残っている、という取り違えも起きやすいので、未承認一覧を正とする運用が安心です。
出典>>Salesforce Help「組織内で従来の承認プロセスの申請に応答できるようにする」
関連記事>>Salesforceアプリとは？モバイルでできることと1日の使い方
承認プロセスで現場が止まりやすい箇所は、だいたい次の4つに集まります。設定画面では問題がなく見えても、初回の本番申請で表面化することが多いため、有効化前の通しテストで潰しておく価値があります。
申請中はレコードがロックされるため、申請者が割引率を後から直そうとしても編集できないことがあります。差し戻しや却下後に直す運用か、承認者・管理者が編集できる設定にするかを、開始前に決めておきます。
申請した直後に顧客から条件が変わる展開は訪問営業では珍しくないので、ロック中の直し方を口頭ルールにしておくと安心です。
許可された申請者以外が申請するとエラーになります。プロファイルや権限セット、申請者の範囲設定を見直してください。代理店ユーザーや兼任マネージャーが申請する組織では、想定外のプロファイルが混ざっていないかも確認します。
承認者に「所有者のマネージャー」を使う場合、ユーザーレコードのマネージャー項目が空だと経路が止まります。人事異動のたびにマネージャーが更新されているかも、運用ルールに含める必要があります。
新任のフィールドセールス担当のユーザーにマネージャーが未設定のまま、というケースは特に多いです。
同じオブジェクトに複数の承認プロセスがある場合、申請者側にはどのプロセスに入ったかが見えないことがあります。Helpの考慮事項でも触れられている点です。エントリ条件の重なりを減らすか、プロセス名と条件をドキュメントで共有しておくと問い合わせが減ります。
値引き用と契約条件用を分けたあと、条件の境界が曖昧だと、意図しない経路に乗ることもあります。現場からの問い合わせが「申請ボタンが押せない」「誰に飛んだか分からない」に集中するなら、まずこの4つを点検すると解決が早いです。
出典>>Salesforce Help「従来の承認プロセスの制限と考慮事項」
値引き稟議の質は、承認プロセスの経路設計だけでは決まりません。訪問で何を話し、どの根拠で割引率を置いたかが商談や活動に残っているかどうかが、マネージャーの判断速度を左右します。
活動や商談更新の母数が薄いと、なぜこの割引なのかが口頭頼みになり、承認が遅れます。逆に、訪問メモと競合状況、顧客の予算感が残っていれば、外出中でも承認か却下の判断が早くなります。
訪問記録を先に整え、商談の割引率や特別条件を更新してから承認申請する順が、現場では扱いやすいです。設備メンテナンスの担当が、現場で合意した条件をその日のうちに商談へ反映し、根拠コメントを残してから申請する。マネージャーは未承認一覧から開き、記録を見て返す。
この短いループが回ると、稟議は「紙の手続き」から「次の訪問の前提」に変わります。
SalesforceのAgentExchangeで提供されているUPWARDは、訪問先での入力情報を厚くし、承認申請前の根拠データをそろえる役割としても活用できます。
承認者・条件・最終アクションはSalesforceの承認プロセス側で決め、訪問記録の厚みは入力側で補う、という役割分担がはっきりしているほど、導入後の期待値のズレが減ります。
訪問後の自動化や活動の考え方は、それぞれの記事とSalesforce連携のページを参考にしてください。
関連記事>>Salesforceの活動とは？ToDo・行動との違いと記録・設定の方法
関連記事>>Salesforceフローとは？種類と作り方を訪問営業の自動化例で解説
関連ページ>>Salesforceとの連携サービス
訪問先の値引き稟議をSalesforceの承認プロセスで回すなら、次の順で進めると迷いが少ないです。作り方の順序（ウィザードから有効化まで）と、現場で依頼する順番を重ねたチェックリストです。
フローでのレコード自動化や活動の母数づくりは、すでに公開している各記事に任せ、稟議経路に集中するのが安全です。1本が日常で回るようになってから、合議や多段承認を足してください。
上のチェックリストの最初の4つが止まらず動く状態が、訪問営業チームにとっての最初のゴールです。
訪問営業チームが承認プロセスを依頼・運用するときに、よく出る疑問をまとめました。
組織の設定により、メールやChatterから承認・却下できる場合があります。ただし権限やレコードアクセスがないと、メール経由でも処理できません。
外出が多い営業マネージャー向けには、モバイルの承認ナビやホームの未承認申請とあわせて運用するのが確実です。メールだけに依存すると、通知の見落としや権限不足で滞留しやすいです。
出典>>Salesforce Help「組織内で従来の承認プロセスの申請に応答できるようにする」
フロー承認プロセスは、フロー側で承認経路を組む比較的新しい選択肢です。クラシックの承認プロセスと役割は近い一方で、機能の境界は一致しません。
値引き稟議のように条件と承認者がはっきりしている経路は、従来の承認プロセスで十分なことが多いです。詳細な作り方や要素の一覧は範囲外とします。導入を検討するときは、サクセスナビやHelpで最新の差分を確認してください。
出典>>Salesforce サクセスナビ「フロー承認プロセスを学ぶ」
なりません。承認プロセスは「誰がレコードを承認するか」の経路です。フローはレコード操作や画面の自動化が主領域です。訪問後のToDo自動作成などはフロー側で扱い、値引き稟議の経路は承認プロセスで組む、という分担が分かりやすいです。
両方を組み合わせることはあっても、どちらか一方で他方の役割を丸ごと代替する関係ではありません。稟議が止まったときにフローを増やしても、承認者不在の問題は解けない、というのが現場でよくある取り違えです。
関連記事>>Salesforceフローとは？種類と作り方を訪問営業の自動化例で解説
はい。本番に有効化する前に、サンドボックスで申請から承認、却下まで一通り試すのが安全です。エントリ条件の境界値や、マネージャー未設定時の挙動も、サンドボックスで先に確認できます。
サンドボックス自体の考え方や使い分けは、Sandboxの記事を参考にしてください。検証環境の詳細にはここでは踏み込みません。
関連記事>>Salesforce Sandboxとは？種類・作り方と訪問営業向け検証の進め方
