組織が成長し、商談の規模が大きくなると、営業現場には「多段承認」の壁が立ちはだかります。「課長、部長、そして法務」といった複数のチェックが必要な一方で、人の異動や役職の変更は頻繁に起こります。
また、内部監査を重視する上場企業などでは、RCMやJSOXへの対応などが求められます。
本記事では、HubSpotの標準機能の枠を超え、メンテナンス性を維持し続ける「サステナブルな承認フロー」の具体的な構築方法を解説します。
現場の課題：運用の「硬直化」と標準機能の限界
多くのHubSpotユーザーが、以下のような承認業務の壁に突き当たっています。
- 標準機能の回数制限： HubSpot標準の承認機能は、1つのパイプラインにつき1回しか設定できず、複数のステージにまたがる承認には不向き。
- 多段承認へのハードル： 「Aさんの次にBさんの承認が必要」といった連鎖的なフローを組もうとすると、ワークフローが複雑怪奇になりがち。
- メンテナンスの行き止まり： 承認者の異動や退職のたびに、何十ものワークフローを一つひとつ開いて修正しなければならず、運用が持続しない（サステナブルではない）。
これらを解決するには、ワークフロー内に特定の個人名を直接書き込む（ハードコーディングする）運用から脱却する必要があります。
実現イメージ：マスタデータが承認を動かす「外付けエンジン」
それでは具体的な方法を解説していきます。動画もぜひご覧ください。
今回提案する解決策は、取引（ディール）そのものを動かすのではなく、承認専用の「カスタムオブジェクト」を司令塔にする手法です。
- 分離： 承認が必要になったら、取引に関連付いた「承認レコード」を発行。
- 参照： 承認レコードが、あらかじめ用意した「承認フローマスタ（どの部署・ステージなら誰が承認するかを定義したデータ）」を読みに行く。
- 自走： マスタに記された順番通りに、自動で承認者が切り替わる。
組織変更があった際は、ワークフローを一切触らずに、マスタレコードを1箇所更新するだけで、すべての承認フローが最新の状態に反映されます。
設定方法：5つのステップによる仕組みづくり
1. 準備：オブジェクトとプロパティの定義
- 承認オブジェクト： 承認履歴を管理するカスタムオブジェクト。
- 承認フローマスタ： 承認ルートを定義するレコード。「条件（ステージなど）」「承認順序」「承認者」を保持させます。
- 取引側のトリガー： 「承認依頼（チェックボックス）」などのプロパティを用意。
2. 承認レコードの自動生成
取引ステージが特定の位置に達し、承認依頼がオンになったらワークフローを起動。
- 取引の「現在のステージ」「担当者」などの情報をコピーした状態で、新しい「承認レコード」を作成します。
3. マスタレコードとの自動紐付け
承認レコード側の情報を基に、該当する「承認フローマスタ」を検索し、自動的に関連付けを行います。マスタに定義された「1番目の承認者」を、承認レコードの担当者に割り当てます。
4. 承認アクションとループ処理
承認者に通知を飛ばし、レコード上で「承認」または「差し戻し」を選択してもらいます。
- 承認された場合： マスタの次順（例：順序2）の承認者を呼び出し、担当者を上書き。
- 次順がいない場合： フロー完了と判定します。
5. 取引レコードへの結果同期
承認レコードの最終ステータス（承認済み・否認）を、元の取引レコードのプロパティへ自動的に書き戻します。
導入の効果：長期的な運用安定
この仕組みの構築には、カスタムオブジェクトの設計やワークフローの作り込みなど、相応の初期工数がかかります。しかし、一度完成してしまえば、その後の管理コストは劇的に下がります。
- 属人化の排除： 誰が承認すべきかはマスタが知っているため、設定ミスが起こりません。
- メンテナンスの簡略化： 承認者の追加・変更は「レコードの更新」で完結します。
- プロセスの可視化： 承認の履歴が別オブジェクトに蓄積されるため、監査やプロセス改善に役立ちます。
まさに、組織の拡大や変化に柔軟に対応できる、文字通りのサステナブルな承認フローが実現します。