べにおブログ

学んだことを、ゆっくり深く。

承認プロセスとは何か:「上司の承認をもらう」を仕組み化する

「値引きが20%を超える商談は、部長の承認を取ってから進めてください」。 この手のルールはどの会社にもありますが、メールやチャットで回していると承認の記録や進捗が分散します。Salesforceには、従来のClassic承認プロセスと、Flow Builderで構成するFlow承認プロセスがあります。どちらも人による承認を管理しますが、開始方法、構成要素、実行できる処理が異なります。


結論:まずこれだけ覚える

📌 承認プロセスは、対象レコード、承認者、承認順序、承認/却下時の処理を定義する機能です。 Classic承認プロセスは設定画面で構成し、Flow承認プロセスはFlow Builderでステージ、承認ステップ、バックグラウンドステップ、判断を構成します。

Classic承認プロセスとFlow承認プロセス

  • Classic承認プロセス:ユーザーの承認申請、またはフローの[承認申請]アクションなどから対象レコードを申請する。標準アクションはレコードロック、項目更新、メールアラート、タスク、アウトバウンドメッセージなど。
  • Flow承認プロセス:自動起動型またはレコードトリガー型として作成できる。承認ステップには人の操作が必要で、バックグラウンドステップは自動起動フローを実行できる。各Flow承認プロセスには少なくとも1つの承認ステップが必要。 以下の「エントリ基準」「承認ステップ」「承認アクション」の説明は、主にClassic承認プロセスを対象とします。

Classic承認プロセスで何ができるのか

Classic承認プロセスを作成し、ページレイアウトに[承認申請]アクションを配置すると、ユーザーはレコードを手動で申請できます。Flow Builderの[承認申請]アクションからClassic承認プロセスへ自動送信することもできます。申請されると、次の処理が行われます。

  1. レコードがロックされる(承認者と管理者以外は編集できなくなる)
  2. 指定された承認者に依頼が飛ぶ(メールとアプリ内の通知)
  3. 承認者が承認・却下すると、次のステップへ進むか、終了する
  4. 結果に応じて項目更新やメール送信などのアクションが実行される
  5. 誰がいつ承認したかが承認履歴に残る ロックされるというのが地味に重要です。承認待ちの間に金額を書き換えられては、承認の意味がなくなってしまうからです。

Classic承認プロセスの三つの構成要素

1. エントリ基準(開始条件)

「どのレコードがこの承認プロセスに入るのか」を決める条件です。例:「金額 > 1,000,000」「レコードタイプ = パートナー商談」。 重要なのは、承認プロセスは1オブジェクトに複数作れるということです。並べた順番に上から評価され、最初にエントリ基準を満たしたプロセスが適用されます。この性質を使えば、「条件によって違う承認者に振り分ける」という要件を、コードなしで実現できます。

2. 承認ステップ

「誰に、どの順番で承認を求めるか」を定義します。ステップは複数作れ、例えば「1段階目:直属の上司 → 2段階目:部長」という連鎖を組めます。 ステップごとに**「このステップに入る条件」を別途指定できる**のもポイントです。条件に合わないステップは飛ばせるので、一つのプロセスの中でもある程度の場合分けができます。 なお、1つの承認プロセスに作れるステップ数や、組織全体の承認プロセス数には上限があります。大規模な設計をするときは、公式の制限ページを必ず確認してください。

3. アクション

各タイミングで自動実行される処理です。

タイミング
初期申請時レコードをロック(既定)、ステータスを「承認中」に更新
承認時ステータスを「承認済み」に、関係者にメール
却下時ロックを解除して差し戻し、申請者に通知
取下げ時申請を取り消したときの後始末

承認者に指定できるもの

ここが試験の高頻出ポイントです。

  • 特定のユーザー(名前を直接指定)
  • 申請者のマネージャ項目に入っている人(「直属の上司に回す」がこれで実現できる)
  • レコード上のユーザー項目に入っている人
  • 申請者に選ばせる
  • キュー

キューを承認者にするとどうなるか

キューとは、レコードや仕事を一旦受け止める「共同の受け皿」です。これを承認者に指定すると、振る舞いは次のようになります。

📌 キューのメンバー全員に承認依頼が届き、そのうちの誰か1人が承認または却下すれば、そのステップは完了します。 公式ヘルプも「キューのメンバーのうちの一人がレコードを承認した瞬間に、その承認ステップは完了とみなされ、レコードは次へ進む」と明記しています。 つまりキューは**「全員の承認が必要」という意味ではなく、「手の空いている人が対応すればよい」という意味になります。サポートチームのシフト勤務や、担当者が休むと承認が止まってしまうケースに有効です。 ⚠️ 「全員の承認を取りたい」場合はキューでは実現できません。ステップの承認者として個々のユーザーを複数指定し、「全員が承認する必要がある(一致)」を選ぶ**のが正解です。


他の自動化ツールとの使い分け

やりたいこと使うもの
比較的単純な承認経路を構成したいClassic承認プロセス
レコード更新で自動開始し、判断やバックグラウンド処理を含む承認経路を構成したいFlow承認プロセス
間違った値の保存をその場で止めたい検証ルール
人の判断を介さず自動で項目更新やレコード作成をしたいレコードトリガーフロー
ユーザーに入力画面を見せて対話的に進めたい画面フロー
複数部署・複数工程の業務全体を連携させたいフローオーケストレーション

💡 設問に承認者の判断、承認/却下、承認履歴、承認中のロックが含まれる場合は承認機能を検討します。単にレコードを自動作成・更新するだけなら、承認経路を追加せずレコードトリガーフローを使用します。


Classic承認プロセスとFlow承認プロセスの選択

Classic承認プロセスは、エントリ基準、承認ステップ、標準承認アクションで表現できる承認に適します。Flow承認プロセスは、レコード変更による自動開始、複数のステージや判断、承認者の操作を伴わないバックグラウンド処理が必要な場合に適します。 ただしFlow承認プロセスは、一般的なレコード自動化の代替ではありません。各プロセスに少なくとも1つの承認ステップが必要です。人の承認が不要で、レコード作成や更新だけを自動化する要件では、通常のレコードトリガーフローを使用します。


よくあるつまずき

[承認申請]ボタンが見当たらない

Lightning レコードページの場合、ボタンはページレイアウトの[Salesforce モバイルおよび Lightning Experience のアクション]に追加する必要があります。また、承認履歴を見せるには関連リストの追加も必要です。

承認中なのにレコードを編集できてしまう

ロックは「初期申請時のアクション」で行われます。ここを外してしまっていないか確認してください。なお、管理者はロックされたレコードを編集できます。

キューの人数が多すぎてメールが届かない

公式によると、承認ステップあたりのメール通知先には上限があります。大きすぎるキューは分割するのが推奨されています。


出典(Salesforce公式)