ポートフォリオデータが HubSpot の Deal レコードと並んで存在しなければならないとき、スキーマはリレーションシップマネージャーが期待する形にほぼ並びません。ポートフォリオは Contact に乗り、Deal は 1 ホップ先に乗り、Deal レコード上のネイティブな関連付けテーブルは静かに何も返しません。配線の 3 つの方法。2 つはよりきれいに感じます。本番で持ちこたえるのは、レコードを失わない代わりにノイジーな表面を受け入れるものです。ネイティブが最初、レポート埋め込みが 2 番目、カスタム UI 拡張は最後。
なぜ今これが重要なのか
金融サービスや PE スタイルのデータモデルが、以前より頻繁に HubSpot 内に登場するようになっており、データアーキテクチャは最初のビルドで運用モデルにめったに追いつきません。McKinsey のリファレンスワークは、モダンスタックの成否は単一の柱の深さではなく、その柱がどれだけよく接続されているかにかかっている、と論じています。アジリティはオブジェクトではなく結合から来ます（Castro、Machado、Roggendorf、Soller、「How to build a data architecture to drive innovation、today and tomorrow」、McKinsey Digital、2020 年 6 月）。CRM 内でも同じロジックです。クリーンなポートフォリオオブジェクトとクリーンな Deal オブジェクトは必要ですが、十分ではありません。結合のところに運用モデルが住んでおり、それを間違えるのが、2 四半期にわたって平然と隠れる失敗モードです。
システムの現状
何かを推奨する前に、スキーマが実際に何をしているかを再構築してください。典型的なウェルスプラットフォームのセットアップでは、関連オブジェクトは大体 4 つです。Contact、Deal、カスタムの Portfolio オブジェクト、Company。投資家は Contact です。アクティブなセールスの会話、オンボーディング、追加投資、マンデート変更、は Deal です。Portfolio はカスタムオブジェクトで、投資家ごとに 1 つまたは複数あり、財務状態（AUM バンド、マンデートタイプ、入金日、ステータス）を保持します。
関連付けは通常こう見えます。Contact ↔ Portfolio はソース・オブ・トゥルースの関連付けです。すべてのポートフォリオは正確に 1 人の投資家 Contact が所有します。Contact ↔ Deal は直接：Deal の Primary Contact が投資家。Deal ↔ Portfolio が興味深いところです。私たちが引き継ぐほとんどのビルドでは、この関連付けはネイティブプリミティブとして存在しないか、存在しても手動でのみ入力されます。
つまり、リレーションシップマネージャーが Deal を開きポートフォリオのネイティブ関連付けカードを見ると、何も見えません。1 ホップ先で投資家が明らかに 3 つのポートフォリオを持っていてもです。データはシステムにあります。Deal レコードがそれを見られないだけです。
ポートフォリオを Deal に配線する 3 つのオプション
実行可能なオプションは 3 つで、それぞれ異なる複雑さプロファイルと失敗モードを持ちます。正しいものはほぼ常に、制約を満たす最もネイティブなものです。
オプション 1：Deal 上のネイティブ関連付けテーブル
原則として最もきれいな答えです。HubSpot は直接の Deal ↔ Portfolio 関連付けをサポートします。オンにし、関連付けカードを Deal レコードのサイドバーに追加すれば、リレーションシップマネージャーは Deal ページでポートフォリオを見られます。レポートなし、拡張なし、開発作業なし。最後までネイティブプリミティブ。
落とし穴：このオプションは直接関連付けられたレコードのみを表面化させます。Contact 上にあるが Deal に明示的に関連付けられていないポートフォリオは出てきません。ネイティブサイドバーカードには 2 段目の関連付けトラバーサルがありません。だからネイティブ関連付けテーブルは正しい表面ですが、それを入力する責任を持つ何かがある場合に限ります。放っておくと、空であることの方が多くなります。
オプション 2：Deal レコード上のレポートテーブル埋め込み
「この Deal の Primary Contact」でフィルタしたポートフォリオを引っ張る単一オブジェクトまたはクロスオブジェクトのレポートを構築し、それを Deal レコードに埋め込みます。これは機能します。ネイティブレポートを使い、Contact ホップをトラバースし、カスタムコードはありません。
ダウンサイドはリアルです。働く表面ではなくレポートとして読まれます。Deal 上のリレーションシップマネージャーは、クリックスルー付きの関連付けカードを期待しており、表形式のリストではありません。埋め込みレポートのフィルターロジックは制約され、Deal ページのロード挙動はネイティブ関連付けカードより明らかに遅いです。エグゼクティブ概要ダッシュボードには正しいツールですが、リレーションシップマネージャーが日に 50 回当たる表面ではありません。
オプション 3：カスタム UI 拡張
HubSpot UI 拡張、Deal レコードのサイドバーの React コンポーネント、を構築し、Deal の Primary Contact に基づいて API 経由でポートフォリオを照会し、カスタムカードでレンダリングし、それぞれをポートフォリオレコードにリンクします。最大のコントロール。リレーションシップマネージャーは、ワークフローが必要とするフィルター、グルーピング、ビジュアル階層を持つ、まさに望む表面を得ます。
コストは開発作業、継続的なメンテナンス、表面への変更ごとのデプロイメント依存です。UI 拡張はまた、チームを別の運用モデルにロックインします。本来 5 分の設定編集だった変更が、開発者チケットを必要とするようになります。ほとんどのチームにとって、メンテナンス負担が磨きを上回ります。UI 拡張は、ネイティブまたはレポートベースのパスが制約を満たさないときの正しい答えであり、最初の答えではありません。
推奨
オプション 1、ネイティブ関連付けテーブル、を使い、ワークフローで配線します。Deal 作成時に、Deal の Primary Contact に紐づくすべてのポートフォリオを Deal 自体に自動関連付けするワークフローに Deal を登録します。Deal レコードは、ネイティブ関連付けカードを完全に入力された状態で表示し、各ポートフォリオへのクリックスルーを持ちます。
トレードオフ：一部の Deal は、リレーションシップマネージャーが 1 つしか気にしないところで 4〜5 件のポートフォリオを表面化させます。それで構いません。少ないより多い方が良い。リレーションシップマネージャーは視覚的に 2 秒でフィルタします。代替はクリーンな UI と欠けたレコードであり、それは毎回より悪い失敗モードです。欠けたレコードは見えません。ノイジーなカードは明らかです。
実装の詳細が 2 つ重要です。第一に、ワークフローを Contact 変更イベントでも再実行してください。作成時だけではありません。Primary Contact はオンボーディング中に再割り当てされ、関連付けセットはそれに従わなければなりません。第二に、Deal-to-Portfolio の関連付けにラベルを付けて（存在させるだけでなく）、レポートが自動関連付けと手動キュレーションを区別できるようにします。ラベルは無料です。その不在は 6 か月以内にデバッグ税になります。
現場で見たパターン
ポートフォリオ・オブ・ポートフォリオのデータモデルを持つ EU 拠点のウェルスマネジメントプラットフォームから、Deal レコードに 0 件のポートフォリオが表示される投資家がいる、というご相談がありました。彼らは明らかに複数を持っているのに。チームの本能はオプション 3、UI 拡張、でした。開発者がいて、表面はシニアリレーションシップマネージャーに見えるからです。実際の直し方は午後で構築した 6 ステップのワークフローでした。Deal 作成と Primary Contact 変更でトリガー、Primary Contact 上のポートフォリオを照会、反復、ラベル付き関連付けで各々を関連付け、QA 用に件数を Deal プロパティにログ。チームは前四半期の Deal について Deal-Portfolio 件数を Contact-Portfolio 件数と照合して検証しました。一致したら、ワークフローを Pipeline 全体で回しました。UI 拡張は出荷されませんでした。ネイティブ関連付けカードが働く表面で、それは 2 つの Pipeline 再構築を経て入力されたままです。
解決策：プレイブック
HubSpot の Deal レコードにポートフォリオ（または任意の 1 ホップカスタムオブジェクト）を配線するなら。
- まずスキーマを再構築してください。どのオブジェクトが存在し、どの関連付けがネイティブで、ソース・オブ・トゥルースの関連付けがどこに住むかを確認します。推奨ではなく、結合グラフから始めてください。
- ネイティブの Deal-to-Portfolio 関連付けを有効化してください。関連付けカードを Deal レコードのサイドバーに追加します。それに対する自動化を配線する前に、空でレンダリングされることを確認します。
- 自動関連付けワークフローを構築してください。Deal 作成と Deal Primary Contact 変更でトリガー。Primary Contact 上のポートフォリオを反復します。ラベル付き関連付けで各々を Deal に関連付け、レポートが自動と手動を区別できるようにします。
- 過剰関連付けのトレードオフを受け入れてください。一部の Deal は 4〜5 件のポートフォリオを表面化させます。それが正しい挙動です。リレーションシップマネージャーは視覚的にフィルタします。代替はクリーンなカードと欠けたレコードです。
- 履歴 Pipeline に対して照合してください。稼働前に、前四半期のクローズ Deal に対してワークフローを回し、Deal あたりのポートフォリオ件数を Primary Contact のポートフォリオ件数と照合します。不一致は通常、ワークフローロジックではなく関連付けラベルのギャップです。
- 件数を Deal プロパティにログしてください。シンプルな整数、「Deal 作成時の関連付けポートフォリオ数」、が、6 か月後にチームに無料のデバッグシグナルを与えます。
- UI 拡張は、ネイティブパスが実際に失敗するケースに留保してください。ワークフローが制約を満たすなら、出荷して進みます。UI 拡張の開発作業は最初ではなく、最後に手を伸ばすオプションです。
Checkpoint がどう関わるか
Checkpoint で行う HubSpot アーキテクチャ作業のほとんどは、まさにこの形です。ほぼ機能するカスタムオブジェクトスキーマ、ほぼ正しいデータを表示するリレーションシップマネージャー表面、そして誰も配線したがらない欠けたネイティブ関連付け。ネイティブプリミティブはほとんどのチームが評価する以上の重みを持ちます。ポートフォリオ、契約、サブスクリプション、その他の 1 ホップカスタムオブジェクトが Deal レコードから静かに欠けているなら、より簡単なやり方がほぼ常に正しいやり方であり、ほぼ常に最初に試すべきものです。
出典
- Castro, Antonio; Machado, Jorge; Roggendorf, Matthias; Soller, Henning. 「How to build a data architecture to drive innovation、today and tomorrow.」 McKinsey Digital、2020 年 6 月 3 日。mckinsey.com
- Lemkin, Jason. 「Which CRM in 2026/2027?」 SaaStr、2026 年 4 月。saastr.com
Noah Charak