English
Tiếng Việt割引の承認をメッセージで依頼し、2日後にようやく返事が来て、誰が同意したのか誰も覚えていない。思い当たるなら、Salesforce Approval Processが、署名を追いかける作業を、明確な流れに置き換えます。条件に応じて適切な承認者に申請が届き、承認者は何を承認するかが分かり、すべての判断が記録されます。
簡単に言うと、Approval Processは3つの部分で構成されます。申請がプロセスに入る条件、承認ステップ（誰が、どの順で承認するか）、そして承認、却下、取り消しのときにシステムが自動で行うことです。この記事では、しきい値に基づく割引承認を例に説明します。
【ご注意】記事中の事務機器販売会社と割引のしきい値（10%、20%）は説明用の仮定であり、推奨する基準ではありません。実際の承認レベルは、各組織の価格方針と社内の権限によって決まります。Salesforceには現在、classicとFlowベースの2つの承認の作り方があるため、自社のorgに合うほうを選んでください。メニュー名はEditionやバージョンによって異なる場合があります。
Salesforce Approval Processによる、しきい値に基づく割引承認の流れ。メッセージでの割引承認依頼がうまくいかない理由
メッセージでの承認依頼は速そうに見えますが、3つのものが欠けています。承認者は、情報がメッセージ、見積、スプレッドシートに散らばっているため、何を承認するのか正確に分かりません。期限がないため、依頼は待たされたままになります。そして履歴がないため、後で誰がどの割引に同意したかを確認したくても、調べる手がかりが残りません。
仮の例：事務機器販売会社の営業担当が、大口の注文に割引をつけたいとします。彼はチームリーダーにメッセージを送りますが、リーダーは会議中で、2日後に返事をします。その間、お客様は待たされ、契約が結ばれるころには、最終的な割引を誰が承認したのか、誰も確信が持てません。
| 変更前 | 変更後 | |
|---|---|---|
| 承認の依頼方法 | バラバラなメッセージやメール | Opportunity や Quote のレコード上から直接申請 |
| 承認者 | 思い出した人、または聞いた人 | 条件（例：割引率）に応じて自動で決まる |
| 情報 | 複数の場所に分散 | 承認者が1つのレコードで全体を確認できる |
| 履歴 | 後から調べにくい | 誰が、いつ、どんなコメントで承認したかを記録 |
Salesforce Approval Processの仕組み
Approval Processは3つの層で構成されます。この3つを理解すれば、どんなApproval Processも読み解けます。
Entry criteria（開始条件）
- どのレコードに承認が必要かを決める。例：割引がしきい値を超えるOpportunity
- 条件を満たさないレコードは、承認を経由しない
Approval steps（承認ステップ）
- 誰が、どの順で承認するかを定める。例：まずチームリーダー、次に営業部長
- 特定の承認者、キュー、申請者の上司のいずれかを選べる
結果に応じたアクション
- レコードが承認、却下、取り消しされたとき、システムが項目の更新、通知の送信、レコードのロックなどを自動で行える
- 申請者は、修正が必要な場合に申請を取り消せる
承認者には通知が届き、設定によっては、Salesforceのモバイルアプリ上、またはメールで、その場で承認できます。まずSetupに慣れたい方は、Salesforce Sales Cloud Setup Guide in 10 Minutes（英語）から始めるのがおすすめです。
しきい値に基づく割引承認を設定する3ステップ
経営層とルールを合意する
- どの割引率に承認が必要か、誰が承認できるかを合意する
- しきい値と承認者を、下の例のようなシンプルな表に書き出す
Salesforceでプロセスを構築する
- 関連するオブジェクト（通常は Opportunity または Quote）にプロセスを作成する
- 割引率に応じてEntry criteriaを設定し、承認ステップを順に追加する
- 承認、却下、取り消しのときのアクションを設定する
通知、モバイル承認、履歴
- 承認待ちのレコードがあることを承認者が分かるよう、通知を有効にする
- 承認者に、スマートフォンでの承認方法を案内する
- 承認履歴に、誰が、いつ、どんなコメントで承認したかが表示されることを確認する
しきい値の例（説明用のみ）：
| 割引率 | 承認者 | 備考 |
|---|---|---|
| 10%まで | 承認不要 | 営業担当が権限の範囲内で判断 |
| 10%超〜20% | 営業チームリーダー | Opportunity を保存したときに自動で送信 |
| 20%超 | 営業部長 | チームリーダーを経由する場合もある |
これは推奨するレベルではありません。しきい値と承認者は、貴社の価格方針によって決まります。本記事は一般的な参考情報であり、財務や法務に関する助言ではありません。
classicのApproval ProcessかFlowベースか
Salesforceには現在、承認の作り方が2つあります。自社のorgに合うほうを選びましょう。
| classic | Flowベース | |
|---|---|---|
| 特徴 | 昔からある方法で、ステップごとに設定する | Flow Builderで構築し、並行承認や動的なステップなど、より複雑なロジックに対応 |
| 向いている場面 | シンプルで順番に進む承認 | 分岐が多いプロセスや、他のFlowと組み合わせる場合 |
| 備考 | 情報源によると、Salesforceは新機能への投資を行っていない | 情報源によると、Spring 25で登場し、リリースごとに拡張されている |
| 履歴 | Approval Historyを使用 | Approval Traceを使用 |
公開されている情報源によると、classicのApproval Processは今も動作し、サポート終了の発表もありませんが、新機能はFlowに集中しています。選ぶ前に、最新のSalesforceドキュメントで、名称、対応Edition、制限を確認してください。
自社に適用する際の注意点
シンプルなプロセスから始める。最初の1周には、しきい値1つと、1〜2段階の承認で十分です。チームが慣れてから、複雑な分岐を追加しましょう。
代理の承認者を決める。承認者が不在だと、レコードは待たされたままになります。誰が代わりに承認するか、期限を過ぎたレコードをどう扱うかを、あらかじめ決めておきましょう。
長く待たされているレコードを見る。承認待ちのレコードのレポートやダッシュボードがあれば、滞留している場所がすぐに分かります。最初のレポートのヒントは、CRM Reports: 3 Simple Must-Have Reports to Start With（英語）をご覧ください。
方式を切り替えるときは慎重に。classicの承認向けに作ったレポートは、Flowベースの承認には適用できない場合があります。切り替える前に、レポートを確認しましょう。
本番の前に試す。実データに適用する前に、sandboxや学習用のorgで、架空のデータを使って試してください。
Approval Processを作る前のチェックリスト
設定を始める前に、次の短いリストで、プロセスが貴社の価格承認の実態に合っているか確認しましょう。
☐ 割引のしきい値と承認者を経営層と合意した
☐ 対象のオブジェクト（Opportunity または Quote）を選んだ
☐ 方式（classic または Flowベース）を選んだ
☐ 承認、却下、取り消しのアクションを設定した
☐ 不在時の代理の承認者を決めた
☐ 承認者に、スマートフォンでの承認方法を案内した
☐ 承認履歴に十分な情報が表示されることを確認した
☐ 承認待ちのレコードのレポートを作成した
貴社では、価格や割引の承認を、現在どのチャネルで行っていますか？下のコメント欄でぜひ教えてください。Sonixチームがお待ちしています。
Salesforce CRM
ベストプラクティス
ハウツー
ビジネス
Sonixにご相談ください。現在の価格承認の方法を一緒に見直し、貴社に合ったApproval Processを設計します。
Sonix: Your success is our happiness.
コメントを残す