Welche HubSpot-Tabellen laden — und welche skippen

Ein HubSpot-Portal ist eine konfigurierte Revenue-, Marketing- und Service-Anwendung und kein universelles Analytics-Modell. Objekte und Properties werden erst dann zu freigegebenen Quellen, wenn sie eine benannte Entscheidung auf einem definierten Grain unterstützen.

Das Ziel ist keine generische Tabellenliste, die jede HubSpot-Portal laden sollte. Das Ziel ist ein prüfbarer Source Scope für eine Entscheidung oder eine kompatible Gruppe von Entscheidungen. Er dokumentiert, warum jedes Objekt, jede Tabelle, Beziehung oder jedes Feld eingeschlossen, konditional, zurückgestellt, ausgeschlossen oder getrennt wird.

Herausforderung

Der Connector listet Contacts, Companies und Deals. Alles wird geladen „für Pipeline-Reporting“. Wochen später fehlen Stage-Semantik und Owner-Grain — der Mart ist breit, die Vertriebsentscheidung unbeantwortet.

Ein kataloggetriebener Ansatz startet mit dem Katalog aus CRM-Objekten, Properties und Associations, einem Connector-Inventar oder einer Exportvorschau. Weil eine Struktur existiert und abgefragt werden kann, wird sie „für später“ ausgewählt. Das Ergebnis ist eine breite Landing Zone, deren Business-Bedeutung, Grain und Access Grenze erst geklärt werden, wenn Downstream-Teams bereits Daten verbinden.

Ein typisches Inventar kann enthalten:

• Contacts, Companies, Deals und Tickets
• Products, Line Items und aktivierte Commerce-Objekte
• verantwortliche Person, Teams, Pipelines, Stages und Referenz-Properties
• Aktivitäten wie Calls, Meetings und Communications
• Custom Objects, Custom Properties und Association Labels
• Property History, archivierte Datensätze, Merges und Löschsignale
• Notes, Messages, Files, Attachments und technische Datensätze

Diese Kategorien führen nicht automatisch zu Include oder Exclude. Ihre Bedeutung hängt von der konfigurierten Anwendung, aktivierten Features, Custom Extensions und dem gewählten Geschäftsprozess ab.

Typische Fehlermuster sind vorhersehbar:

• technisch verfügbare Strukturen werden mit freigegebenen analytischen Quellen verwechselt;
• Current State, History, Events und Snapshots werden ohne Zeitvertrag vermischt;
• Parent-, Child-, Header-, Line- oder Association-Strukturen werden ohne Ziel-Körnung verbunden;
• Display Labels gelten als stabile Business-Definitionen, obwohl die konfigurierte Semantik abweicht;
• personenbezogene Daten, Freitext und Attachments erweitern Access- und Retention-Grenze;
• Custom Process Structures werden ignoriert, weil Standardnamen vertrauter wirken;
• jedes Downstream-Produkt erfindet eigene Interpretationen, Duplication Rules und Exception Handling.

Unterschiedliche Entscheidungen benötigen unterschiedliche Scopes

• Pipeline-Steuerung nach Deal Stage und verantwortliche Person benötigt Deal-fachliche Ebene, governte Stage-Daten sowie die relevanten verantwortliche Person- und Company-Associations.
• Revenue nach Produkt benötigt Line-Item-fachliche Ebene und eine kontrollierte Beziehung vom Deal zum Line Item sowie bei Bedarf zu einer wiederverwendbaren Product Reference.
• Lifecycle Conversion nach Quelle benötigt ein abgestimmtes Lifecycle-Modell, Event- oder Property-History-Semantik und explizite Contact-Company-Association-Regeln.
• Ticket Resolution nach Team benötigt Ticket-Ebene, Status- und Datumssemantik, Category-Referenzen und nur die Aktivitäten, die die Kennzahl tatsächlich verwendet.

Der richtige Source Scope ist deshalb kontextabhängig. Er wird aus der Entscheidung abgeleitet und gegen die reale Konfiguration validiert.

Approach

Definiere den Scope in der folgenden Reihenfolge. Connector- und Extraction Design folgen später.

1. Entscheidung, Population und Ziel-Grain formulieren

Beschreibe die Anforderung als Entscheidung mit Nutzer, Handlung, Population, Zeithorizont und Grain. „Ein Dashboard aus HubSpot-Portal bauen“ ist zu schwach, weil damit nicht feststeht, welche Datensätze, Beziehungen oder historischen Zustände erforderlich sind.

Beschreibe für jeden vorgesehenen Fakt eine Zeile in Business-Begriffen. Definiere das Event, das den Fakt erzeugt, die interpretierenden Dimensionen und das steuernde Reporting Date. Eine Quellzeile ist nicht automatisch ein analytischer Fakt.

2. Strukturen nach Business Role klassifizieren

Core für den gewählten Use Case

• Companies oder Contacts, wenn sie den governten Kundenkontext definieren
• Deals für Pipeline- oder Revenue-Entscheidungen
• Tickets für ein definiertes Service-Produkt
• verantwortliche Person oder Teams, wenn Verantwortlichkeit benötigt wird
• Pipeline-, Stage-, Datums- und Source-Properties der Kennzahl
• Line Items, wenn Revenue explizit auf Positions-Körnung liegt

Conditional

• Products und Product References
• Campaign- und Attributionsobjekte
• Calls, Meetings und Communication Activities
• Quotes, Orders, Invoices, Subscriptions oder Payments, wenn aktiviert und erforderlich
• ausgewählte Property History
• Custom Objects und Custom Association Labels

Skip ohne konkrete Anforderung

• ungenutzte Feature-Objekte
• All-Property-Exporte
• doppelte Convenience-Repräsentationen
• unbeschränkte Notes, Messages, Files und Attachments
• technische Datensätze ohne benanntes Analytics- oder Kontrollregel-Produkt

Die Gruppen sind Muster und keine universellen Listen. Reale Application Configuration, Custom Objects, aktivierte Modules, Security und Business Meaning haben Vorrang vor generischen Beispielen.

3. Relationships vor den Joins modellieren

Nutze ein beziehungszentriertes Modell statt einer flachen Tabellenliste:

Company ↔ Contact
   \       /
      Deal → Line Item → Product Reference
       |
Ticket oder Activity nur bei Bedarf

Für jede Beziehung werden dokumentiert:

• analytischer Zweck der Association
• Richtung, Kardinalität und Optionalität
• Association Label und konfigurierte Business-Bedeutung
• Auswirkung auf den Ziel-Körnung
• Verantwortung für doppelte oder mehrdeutige Beziehungen
• Current- gegenüber Historical-Bedeutung
• personenbezogene Daten-Klassifikation und Permitted Use

Ein Join wird nicht allein deshalb freigegeben, weil beide Keys verfügbar sind. Ein technisch gültiger Join kann Fakten duplizieren, aktuellen Kontext auf historische Events anwenden oder eine ungelöste Many-to-many-Beziehung erzeugen.

Teste explizit diese Failure Cases:

• eine Many-to-many-Beziehung zwischen Contact und Company wird auf eine willkürliche Company reduziert
• ein Deal wird einmal je zugeordnetem Contact gezählt
• Product Definitions und deal-spezifische Line Items werden als derselbe fachliche Ebene behandelt
• Activities werden durch wiederholte Associations aufgebläht
• Custom Objects des tatsächlichen Prozesses werden ausgelassen

4. Current State, Events, History und Snapshots trennen

Der Source Scope unterscheidet:

• aktueller Objektzustand
• Property History für freigegebene Properties
• explizite Lifecycle- oder Business-Events
• plattformseitige Created- und Update-Timestamps
• bewusst erzeugte Snapshots für vollständige Point-in-time-Zustände

Ein generischer Created- oder Updated-Timestamp beweist keine vollständige Business History. Audit Data ist nicht automatisch ein Process Event Log. Für Point-in-time-Rekonstruktion muss feststehen, welcher Zustand erhalten bleibt, wie Corrections erscheinen und ob Plattform-Snapshots benötigt werden.

5. Field-, Privacy- und Access-Controls anwenden

Die Aufnahme eines Objekts oder einer Tabelle autorisiert nicht alle Felder. Erstelle eine Allowlist und entscheide separat über:

• E-Mail-Adressen, Telefonnummern und Contact-Identifier
• Notes, Messages und Communication Bodies
• freie Beschreibungen und Betreffzeilen
• Files und Attachments
• Verhalten archivierter, zusammengeführter und gelöschter Datensätze

Bevorzuge kontrollierte Kategorie, Count, Flag oder abgeleitetes Age, wenn die Entscheidung keinen Raw Content benötigt. Permitted Use, Role- und Domain Access, Masking, Retention, Deletion Propagation und Incident Verantwortung werden vor der Extraktion definiert.

6. Einen expliziten Decision State vergeben

Nutze mehr als eine binäre Load-or-ignore-Entscheidung:

• Include — Bedeutung, Autorität, fachliche Ebene, Zugriff und Quality Kontrollregeln sind freigegeben.
• Conditional — die Quelle wird nur für eine benannte Variante oder Kennzahl mit klarer Aktivierungsbedingung benötigt.
• Defer — der Bedarf ist valide, aber Verantwortung-, History-, Security-, Quality- oder Extraction-Nachweis ist unvollständig.
• Exclude — kein freigegebener analytischer Zweck existiert oder die Struktur ist redundant, instabil oder unverhältnismäßig riskant.
• Separate Product — ein Operational-, Security-, Audit- oder Restricted-Use-Case existiert, darf aber nicht in das allgemeine Business-Produkt gemischt werden.

Jede nicht eingeschlossene Entscheidung benötigt Rationale und Review Trigger.

7. Gegen das konfigurierte System validieren

Namen und Standardbeispiele sind keine Verträge. Prüfe den tatsächlichen Prozess mit Business Ownern, Application Administrators, Privacy, Security und Integration Team. Bestätige Custom Objects, aktivierte Modules, Statusmodelle, Labels, Keys, Access und Lifecycle-Verhalten im realen Tenant oder in der Instanz.

Checklist

Entscheidung und Grain

• Die Business-Frage benennt Nutzer, Handlung, Grundgesamtheit und Zeithorizont.
• Jeder Fakt besitzt einen deklarierten Business fachliche Ebene.
• Event und Reporting Date sind explizit.
• Current State, Event History und Snapshots sind getrennt.
• Kennzahlen und Status-Semantik besitzen accountable verantwortliche Person.

Quellstrukturen und Relationships

• Jede eingeschlossene Struktur unterstützt eine benannte Anforderung.
• Custom und application-spezifische Strukturen wurden geprüft.
• Keys, Kardinalität und Optionalität sind dokumentiert.
• Duplicate-, Orphan- und Many-to-many-Verhalten ist definiert.
• Reference Labels und Codes besitzen ein freigegebenes Mapping.

Risiko und Lifecycle

• Eine Field Freigabeliste existiert.
• personenbezogene Daten, sensible Attribute und Freitext sind klassifiziert.
• Attachments und Binary Content besitzen eine separate Entscheidung.
• Deletion-, Merge-, Archive- oder Deactivation-Verhalten ist definiert.
• Retention und Permitted Use sind freigegeben.

Betrieb

• Freshness und erwartetes Volumen sind verstanden.
• Completeness, Uniqueness und Relationship Quality sind testbar.
• Business und technischer Betreiber sind benannt.
• Abgleich Kontrollregeln sind definiert.
• Jede Defer-, Exclude- oder Separate-Product-Entscheidung besitzt einen Review Trigger.

Artifact

Erstelle ein governtes Source-Scope-Register je Data Product oder kompatiblem Entscheidungsportfolio. Es ist der freigegebene Vertrag zwischen Business Requirement und späterem Extraction Design.

Pflichtfelder

| Feld | Zweck | | Objekt oder API Resource | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | Business Purpose | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | Target Data Product | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | Beitrag zum Ziel-Grain | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | freigegebene Property Allowlist | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | Association Path, Label, Richtung und Kardinalität | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | Current-, Event-, Property-History- oder Snapshot-Bedarf | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | Verhalten archivierter, zusammengeführter und gelöschter Datensätze | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | PII- und Freitextrisiko | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | Freshness und Retention | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | Business und Technical Custodian | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | Decision: Include, Conditional, Defer oder Exclude | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope | | Rationale und Review Trigger | Erforderliche Entscheidungsevidenz für den freigegebenen Source Scope |

Erforderliche Outputs

• freigegebener Objektumfang
• Property Freigabeliste
• freigegebene Association Map
• explizite Skip-Liste
• History- und Deletion-Vereinbarung
• offene Fragen und Übergabe an Ingestion

Das Artefakt wird versioniert. Neue Modules, Custom Objects, Prozessänderungen, Statusmodelle, Access-Policy-Änderungen oder wesentliche Data-Quality-Incidents lösen einen Review aus. Queryability ist keine Freigabe.

Tools

Nutze den Source Scope Builder, um Include-, Conditional-, Defer-, Exclude- und Separate-Product-Entscheidungen mit Grain, Autorität, Risiko und Review Triggern zu dokumentieren.

Nutze Suppliers für produktspezifischen Kontext und den PII and DSDR Readiness Checker, wenn der Scope personenbezogene Daten, Freitext, Löschungen oder Betroffenenrechte umfasst.

Die Tools strukturieren Evidenz. Sie ersetzen keine Freigabe durch Data Owner, Steward, Application Owner, Privacy oder Security.

Resources

• HubSpot-Dokumentation zu CRM Associations
• HubSpot-Dokumentation zum CRM Object Model
• HubSpot-Leitfaden zu Custom Objects

Die konfigurierte HubSpot-Portal bleibt die entscheidende technische Evidenz. Produktdokumentation beschreibt Capabilities; sie bestimmt nicht Business Authority, Grain oder Permitted Use.