概要とビジネスシーン
Salesforce Approval Process（承認プロセス）は、特定のレコードが定義されたビジネスルールと条件を満たした際に、一連の承認ステップを経て最終的に承認または却下されるまでを自動化・統制する強力な機能です。これにより、組織はビジネスプロセスの標準化、コンプライアンスの強化、そして効率化を実現できます。
実際のビジネスシーン
シーンA：金融業界 - ローン申請承認
- ビジネス課題：ある銀行では、顧客からのローン申請が手動で承認されており、承認者間の連携不足、進捗の不透明性、承認までのリードタイムの長さが課題でした。特に高額ローンでは複数の部署による承認が必要で、処理の遅延が顧客満足度低下に直結していました。
- ソリューション：Salesforce Approval Processを導入し、ローン申請レコード（カスタムオブジェクト）に対して、申請額に応じた多段階承認プロセスを構築しました。例えば、500万円以下は支店長、500万円以上は本部長、1億円以上は役員会の承認を必須としました。
- 定量的効果：承認までの平均リードタイムが30%短縮され、コンプライアンス違反リスクが低減しました。また、進捗状況がSalesforce上で常に可視化されることで、オペレーションコストが15%削減されました。
シーンB：製造業 - 新規部品サプライヤー承認
- ビジネス課題：製造業の企業で、新規部品サプライヤーの選定と承認プロセスが部門横断的かつ複雑でした。品質管理、調達、設計など、複数の部署がそれぞれの評価を完了し、最終的に承認されるまでに数週間かかることもあり、新製品開発の遅延を招いていました。
- ソリューション：サプライヤー情報レコード（カスタムオブジェクト）に対するApproval Processを設定しました。品質評価担当者、調達担当者、設計担当者それぞれの承認ステップを順に設定し、各ステップで必要な情報入力や添付資料の確認を義務付けました。特定の評価項目で基準を満たさない場合は、自動的に却下されるロジックも組み込みました。
- 定量的効果：新規サプライヤー承認までの期間が平均20%短縮され、市場投入までの時間が短縮されました。承認プロセスの標準化により、サプライヤー選定の品質が向上し、長期的なコスト削減にも寄与しました。
シーンC：SaaS企業 - 割引申請承認
- ビジネス課題：SaaS企業では、営業担当者が顧客に提示する割引率の承認が属人化しており、割引が過度に適用されるケースや、承認フローが不明瞭なために営業機会を損失するケースがありました。これにより、収益性が損なわれるリスクと、承認者への負荷増大が課題でした。
- ソリューション：商談（Opportunity）オブジェクトにApproval Processを導入し、割引率に基づいた承認階層を設定しました。例えば、割引率10%以下は営業マネージャー、10%超25%以下は営業部長、25%超はCFOの承認を必須としました。
- 定量的効果：割引申請の承認プロセスの透明性が高まり、過度な割引が約15%減少しました。これにより収益性が向上し、営業チームは承認にかかる時間を削減し、顧客との商談に集中できるようになりました。
技術原理とアーキテクチャ
Salesforce Approval Processは、レコードが指定された承認基準（Entry Criteria）を満たした際に開始される、オブジェクト固有の自動化機能です。その中核は、承認ステップ、アクション、および承認者（Approver）の割り当てによって構成されます。
基礎的な動作メカニズム
Approval Processの動作は以下のフェーズで進行します。
- ユーザーがレコードを承認のために提出（Submit for Approval）します。
- システムは、レコードがApproval ProcessのEntry Criteria（エントリ条件）を満たすか検証します。
- 条件を満たした場合、Initial Submission Actions（提出時アクション）が実行されます。
- レコードは最初のApproval Step（承認ステップ）に進み、指定されたApprover（承認者）に承認リクエストが割り当てられます。承認者は、個人、キュー、関連ユーザーフィールド、または階層によって指定できます。
- 承認者がリクエストを承認または却下すると、そのステップで定義されたApproval Actions（承認時アクション）またはRejection Actions（却下時アクション）が実行されます。
- 承認された場合、レコードは次の承認ステップに進むか、または最終承認されます。却下された場合、プロセスは終了し、通常は提出者にレコードが返却されます。
- 最終承認または最終却下時には、Final Approval Actions（最終承認時アクション）またはFinal Rejection Actions（最終却下時アクション）が実行されます。
主要コンポーネントと依存関係
- Approval Process（承認プロセス）：承認フロー全体の定義。対象オブジェクト、エントリ条件、提出時・最終承認・最終却下・再呼び出し時のアクション、承認ステップが含まれます。
- Approval Steps（承認ステップ）：承認フローの各段階。ステップ条件、承認者の割り当て方法、そのステップでの承認・却下時アクションを定義します。
- Approval Actions（承認アクション）：承認プロセス内で特定のイベント（提出、承認、却下、再呼び出し）が発生した際に実行される自動化アクション。以下のタイプがあります。
- Field Update（項目自動更新）
- Task Creation（タスク作成）
- Email Alert（メールアラート）
- Outbound Message（アウトバウンドメッセージ）
- Entry Criteria（エントリ条件）：Approval Processを開始するためのレコードの条件。複数のAND/OR条件を組み合わせることが可能です。
- Process Instance（プロセスインスタンス） / ProcessInstanceStep（プロセスインスタンスステップ）：Salesforceの標準オブジェクトで、承認プロセスの実行履歴を保持します。承認のステータス、承認者、コメントなどが記録されます。
データフロー
| イベント | 説明 | 関連コンポーネント |
|---|---|---|
| 1. レコードの提出 | ユーザーがオブジェクトレコードを承認のために提出します。 | 対象オブジェクト |
| 2. エントリ条件の評価 | 提出されたレコードがApproval ProcessのEntry Criteriaを満たすかシステムが評価します。 | Approval Process (Entry Criteria) |
| 3. 提出アクションの実行 | 条件を満たした場合、Initial Submission Actionsが実行されます。 | Approval Actions (Initial Submission) |
| 4. 承認ステップの開始 | レコードは最初のApproval Stepに進み、承認者へのリクエストが生成されます。 | Approval Steps, ProcessInstanceStep |
| 5. 承認者の応答 | 承認者はリクエストを承認、却下、または再割り当てします。 | ProcessInstanceStep |
| 6. ステップアクションの実行 | 承認者の応答に応じて、そのステップのApproval/Rejection Actionsが実行されます。 | Approval Actions (Per Step) |
| 7. 次のステップ/終了 | 承認された場合、次のステップへ。却下された場合、プロセスは終了し、Final Rejection Actionsが実行されます。 | Approval Steps, Final Rejection Actions |
| 8. 最終承認/却下 | 全てのステップを完了し承認されるか、途中で却下された場合、プロセスは最終的に完了します。 | Final Approval Actions, Final Rejection Actions |
ソリューション比較と選定
Salesforceでビジネスロジックを自動化する方法は複数あり、Approval Processはその一つです。以下に他の関連ソリューションとの比較を示します。
| ソリューション | 適用シーン | パフォーマンス | Governor Limits | 複雑度 |
|---|---|---|---|---|
| Approval Process | 標準的な階層型・条件分岐承認、Delegated Approver（承認者代理）設定、承認履歴の自動記録。 | 標準機能として最適化。複雑な条件や多数のステップは表示・処理に多少影響する場合がある。 | 標準機能のため直接的なApex Governor Limitsは少ない。ただし、関連するApproval ActionsがトリガーやFlowを呼び出す場合は考慮が必要。メール送信制限など。 | 設定UIが充実しており、比較的低い。高度な動的ルーティングには限界がある。 |
| Flow (Record-Triggered Flow + Custom Objects) | 非常に複雑な動的ルーティング、カスタムUIでの承認操作、外部システム連携、カスタム承認履歴管理。Approval Processでは難しい多対多の承認や、動的な承認者の追加・削除が必要な場合。 | Flowの複雑性やループ処理に依存。大量レコードの一括処理には不向きな場合もある。 | Flowが実行するDML/SOQL、ループ処理、Apexアクションなど、背後でApex Governor Limitsに抵触する可能性が高い。 | 中～高。Flowの設計スキル、カスタムオブジェクト設計、エラーハンドリングが必要。 |
| Apex Custom Logic (Custom Objects + Email/Task) | Approval ProcessやFlowで実現不可能な、非常に特殊なビジネスロジック、高度な外部システム連携、パフォーマンス要件が厳しい大量承認。 | 開発者の実装に依存。最適化されたApexは高いパフォーマンスを発揮可能。 | Apex Governor Limitsを直接考慮する必要がある。バッチ処理や非同期処理を適切に利用する必要がある。 | 高。Apex開発スキル、テスト、セキュリティ、スケーラビリティの考慮が必須。 |
Approval Process を使用すべき場合：
- ✅ 標準的な多段階承認フローが必要で、承認経路が比較的固定されている場合。
- ✅ 承認履歴の自動記録と、Salesforce標準UIでの可視化が重要。
- ✅ 承認者が明確で、レコードの項目値に基づく条件分岐で対応できる場合。
- ✅ Delegated Approver（承認者代理）や一括承認など、Salesforce標準の承認機能の恩恵を受けたい場合。
❌ 不適用シーン：
- ❌ 承認フローの途中で、承認者に対して複雑な情報入力や動的なUI操作が必要な場合（FlowのScreen Flowが適している）。
- ❌ 承認ロジックが非常に動的で、多数の外部システムとの複雑なリアルタイム連携が求められる場合。
- ❌ 承認プロセス自体を動的に生成・変更する必要がある、または承認プロセスが極めて頻繁に更新される場合。
実装例
Salesforce Approval Processは主に設定（Declarative Configuration）で構築されますが、Apexコードを使ってプログラム的に承認プロセスを開始したり、そのステータスを取得したりすることが可能です。ここでは、Apexから承認プロセスをプログラム的に開始する方法を示します。
この例では、特定のOpportunityレコードを承認プロセスに提出するApexコードを示します。このコードは、例えばカスタムボタンやFlowのApexアクションから呼び出すことができます。
public class OpportunityApprovalService {
/**
* @description 指定されたOpportunityレコードを承認プロセスに提出します。
* @param opportunityId 承認のために提出するOpportunityのID
* @param comments 承認者に送信するコメント
* @return Approval.ProcessResult 承認プロセスの結果
*/
public static Approval.ProcessResult submitOpportunityForApproval(Id opportunityId, String comments) {
// Approval.ProcessSubmitRequest のインスタンスを作成
Approval.ProcessSubmitRequest req = new Approval.ProcessSubmitRequest();
// 承認対象のレコードIDを設定
req.setObjectId(opportunityId);
// 承認プロセスに付随するコメントを設定
req.setComments(comments);
// オプション: 提出者を指定 (省略すると現在のユーザーが提出者となる)
// req.setSubmitterId(UserInfo.getUserId());
Approval.ProcessResult result;
try {
// Approval.process() メソッドを呼び出し、承認プロセスを開始
result = Approval.process(req);
// 成功したかどうかをデバッグログに出力
System.debug('Approval Submission Success: ' + result.isSuccess());
if (result.isSuccess()) {
System.debug('Approval Instance ID: ' + result.getInstanceId());
System.debug('Approval Instance Status: ' + result.getInstanceStatus());
} else {
// エラーが発生した場合、エラーメッセージを出力
for (Approval.ProcessWorkitemRequest pwr : result.getErrors()) {
System.debug('Approval Error: ' + pwr.getMessage());
}
}
} catch (Exception e) {
System.debug(LoggingLevel.ERROR, 'Error submitting opportunity for approval: ' + e.getMessage());
// エラーを適切に処理
throw new AuraHandledException('承認プロセス提出中にエラーが発生しました: ' + e.getMessage());
}
return result;
}
/**
* @description 指定された承認インスタンスの承認をプログラム的に行います。
* @param workitemId 承認アイテム (ProcessInstanceWorkitem) のID
* @param comments 承認コメント
* @return Approval.ProcessResult 承認結果
* ⚠️ 公式ドキュメントの確認が必要: 通常、承認はUIまたはEmailで行われるため、Apexで直接承認アクションを行うケースは限定的です。
* `Approval.ProcessWorkitemRequest` を使用する例は、特定のユースケースに限定されます。
*/
/*
public static Approval.ProcessResult approveWorkitem(Id workitemId, String comments) {
Approval.ProcessWorkitemRequest req = new Approval.ProcessWorkitemRequest();
req.setWorkitemId(workitemId); // ProcessInstanceWorkitem のID
req.setAction('Approve'); // 'Approve' または 'Reject'
req.setComments(comments);
Approval.ProcessResult result;
try {
result = Approval.process(req);
System.debug('Workitem Approval Success: ' + result.isSuccess());
} catch (Exception e) {
System.debug(LoggingLevel.ERROR, 'Error approving workitem: ' + e.getMessage());
throw new AuraHandledException('承認アイテム処理中にエラーが発生しました: ' + e.getMessage());
}
return result;
}
*/
}
実装ロジック解析：
Approval.ProcessSubmitRequestクラスのインスタンスreqを作成します。これは承認プロセスにレコードを提出するためのリクエストを定義します。req.setObjectId(opportunityId)で、承認の対象となるレコードのID（この場合はOpportunityのID）を設定します。req.setComments(comments)で、承認プロセス開始時に承認者に表示されるコメントを設定します。Approval.process(req)を呼び出すことで、定義されたApproval ProcessのEntry Criteriaと一致する最初のプロセスが自動的に開始されます。- 返される
Approval.ProcessResultオブジェクトには、承認プロセスの成功・失敗、インスタンスID、ステータス、エラー情報などが含まれています。これにより、プログラム的に承認プロセスの結果を検証し、後続の処理を行うことができます。 - エラー処理のために
try-catchブロックを使用し、問題が発生した場合には適切なログ出力とエラーメッセージを提供します。
注意点：Apexから Approval Process を操作する際には、実行ユーザーの権限を考慮する必要があります。提出者は対象オブジェクトの「編集」権限と「レコードを承認のために提出」権限を持っている必要があります。
注意事項とベストプラクティス
権限要件
- レコード提出者：対象オブジェクトに対する「参照」および「編集」権限、そしてレコードをApproval Processに提出するための「レコードを承認のために提出」ユーザー権限が必要です。
- 承認者：承認するレコードに対する「参照」権限が必要です。Approval Processの設定により、承認または却下アクションを実行する権限が付与されます。
- Approval Process管理者：Approval Processの作成、編集、有効化を行うには、「アプリケーションのカスタマイズ」権限が必要です。
- メール通知：承認ステップでメールアラートを使用する場合、メール送信権限が必要です。
Governor Limits
Approval Process自体が直接Apex Governor Limitsにカウントされるわけではありませんが、Approval Actionsが間接的にこれらに影響を与える可能性があります。
- DML操作とSOQLクエリ：Approval Actions（例：項目自動更新、タスク作成）がトリガーやFlowを間接的に呼び出す場合、それらが実行するDML操作やSOQLクエリがGovernor Limitsに抵触する可能性があります（例：1トランザクションあたり150 DML操作、100 SOQLクエリ）。
- CPU時間：複雑なApproval Actionsチェーンや、Flow/Apexを呼び出す場合、CPU時間制限（10秒）に達する可能性があります。
- メール送信：Salesforce組織は1日あたり5,000件の外部メール送信制限があります。Approval Processによるメールアラートがこの制限に影響する可能性があります。大量のメール送信には別途制限があります。
- 非同期呼び出し：
@futureメソッドやQueueable Apexなどの非同期Apexは、1日あたり250,000回の呼び出し制限があります。Approval Actionsが非同期Apexをトリガーする場合に考慮が必要です（⚠️ 2025年最新版の正確な制限値については公式ドキュメントで確認を推奨します）。
エラー処理
- Entry Criteria不一致：提出されたレコードがどのApproval ProcessのEntry Criteriaも満たさない場合、承認プロセスは開始されず、エラーメッセージが表示されます。
- 承認者未定義/非アクティブ：承認ステップで指定された承認者が存在しない、または非アクティブなユーザーの場合、承認プロセスはエラーで停止します。承認者を動的に割り当てる場合は特に注意が必要です。
- Final Actionsでのエラー：最終承認/却下アクションで発生するDMLエラー（例：検証ルール違反）は、承認プロセスを完了させない原因となります。エラーメッセージがシステム管理者に送信されるように設定し、定期的にデバッグログを確認することが重要です。
- デバッグログ：Approval Process関連の問題をデバッグするには、ユーザーまたはプロセスビルダーのデバッグログレベルを有効にし、「Workflow」および「Callout」カテゴリを
FINESTに設定すると、詳細な実行フローを確認できます。
パフォーマンス最適化
- Entry Criteriaの最適化：Approval Processが多すぎる場合や、Entry Criteriaが緩すぎる場合、不要なプロセスが評価されパフォーマンスに影響を与える可能性があります。できるだけ具体的な条件を設定し、必要なプロセスのみが開始されるように設計します。
- Approval Actionsの簡素化：Approval Actionsで複雑なFlowやApexを呼び出す場合、パフォーマンスボトルネックになる可能性があります。可能であれば、シンプルかつ効率的なアクションに留めるか、非同期処理を検討します。
- ステップ数の管理：Approval Stepsが過度に多いと、管理が複雑になり、承認に時間がかかります。可能な限りステップを統合し、効率的なフローを設計します。
- 一括承認機能の活用：複数のレコードを一括で承認する必要がある場合、Salesforceが提供する「承認待ち」リストビューの一括承認機能や、Flow/Apexでカスタムの一括承認ソリューションを検討します。
よくある質問 FAQ
Q1：Approval Processで承認者を動的に割り当てるにはどうすればよいですか？
A1：承認ステップでは、以下の方法で承認者を動的に指定できます。
- 関連するユーザー項目：レコード上のユーザー参照項目（例：作成者、所有者、カスタムマネージャーフィールド）を参照して承認者を割り当てます。
- 階層フィールドのユーザー：組織のロール階層に基づいて承認者を割り当てます（例：提出者のマネージャー）。
- カスタムApex/Flow：最も柔軟性の高い方法で、ApexやFlowを使って複雑なロジックで承認者を特定し、そのユーザーIDをカスタムユーザー項目に設定し、その項目を承認ステップで参照します。
Q2：承認プロセスが期待通りに開始されない場合、どうデバッグしますか？
A2：
- まず、提出したレコードが対象のApproval ProcessのEntry Criteria（エントリ条件）を正確に満たしているか確認してください。AND/ORロジックや項目値のタイプミスが原因となることがあります。
- 次に、対象のApproval Processが「有効」になっているか確認してください。
- 提出ユーザーが、対象オブジェクトの「編集」権限と「レコードを承認のために提出」権限を持っているか確認します。
- より詳細なデバッグには、デバッグログを使用します。対象ユーザーに対してデバッグログを有効にし、ログカテゴリ「Workflow」および「Callout」を
FINESTに設定して、承認プロセス開始時のシステム動作をトレースします。
Q3：Approval Processの承認履歴をカスタマイズして表示することはできますか？
A3：標準の承認履歴コンポーネント自体を直接カスタマイズすることはできません。しかし、Approval Processの履歴は、内部的に ProcessInstance および ProcessInstanceStep という標準オブジェクトに保存されています。これらのオブジェクトをSOQLでクエリすることで、カスタムレポートやVisualforceページ、Auraコンポーネント、またはLWC（Lightning Web Component）を使用して、独自の承認履歴ビューを作成・表示することが可能です。
まとめと参考資料
Salesforce Approval Processは、ビジネスプロセスの統制と効率化を実現するための強力なツールです。適切な設計と実装により、組織はコンプライアンスを強化し、承認プロセスの透明性を高め、全体的な運用効率を向上させることができます。
- Approval Processは設定ベースで多段階承認を容易に実現できます。
- FlowやApexと組み合わせることで、より複雑で動的な承認要件にも対応可能です。
- 権限要件、Governor Limits、適切なエラー処理、およびパフォーマンス最適化のベストプラクティスを理解することが、堅牢な承認ソリューションを構築する上で不可欠です。
- ビジネス要件に応じて、Approval Process、Flow、Apex Custom Logicの中から最適なソリューションを選択することが、Salesforceコンサルタントの重要な役割です。
公式リソース
- 📖 公式ドキュメント：Salesforce Approval Process の実装ガイド
https://developer.salesforce.com/docs/atlas.en-us.salesforce_approvals_implementation_guide.meta/salesforce_approvals_implementation_guide/approvals_overview.htm - 📖 公式ドキュメント：Apex 開発者ガイド - プロセス承認の管理
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_process_approvals_submit.htm - 🎓 Trailhead モジュール：承認プロセスの自動化
https://trailhead.salesforce.com/content/learn/modules/approvals
コメント
コメントを投稿