Packages dbt Fivetran pour le CRM

Les packages dbt Fivetran gèrent la plupart des patterns de modélisation CRM courants — filtrage _fivetran_deleted, renommage des colonnes, logique de jointure, suivi historique — et sont utilisés dans des milliers d’installations. Cette note couvre ce que dbt_salesforce et dbt_hubspot fournissent, leurs options de configuration, et dans quels cas il est plus approprié de construire des modèles personnalisés.

dbt_salesforce

Package : fivetran/dbt_salesforce (v2.0.0) Nombre de modèles : ~23 modèles Dépendances : fivetran/dbt_salesforce_source, fivetran/fivetran_utils

Ce que vous obtenez

Le package produit quatre modèles mart principaux :

• salesforce__opportunity_enhanced — Table d’opportunités large et dénormalisée avec les informations de compte, propriétaire et contact pré-jointes. C’est le pattern one big table appliqué aux données CRM, et c’est ce que la plupart des tableaux de bord commerciaux interrogent.
• salesforce__owner_performance — Métriques agrégées par propriétaire d’opportunité : taux de succès, valeur du pipeline, taille moyenne des deals, jours moyens pour conclure.
• salesforce__manager_performance — Mêmes métriques agrégées au niveau du manager, en utilisant la hiérarchie user.manager_id de Salesforce.
• salesforce__sales_snapshot — Résumé du pipeline à un instant donné par date, utile pour suivre l’évolution du pipeline dans le temps.

Le package source (dbt_salesforce_source) gère la couche de base — un modèle de staging par objet Salesforce avec filtrage _fivetran_deleted, renommage des colonnes et casting des types.

Pass-through columns

Les orgs Salesforce sont fortement personnalisées. Les modèles standard du package gèrent les champs standard, mais votre org possède presque certainement des champs personnalisés (__c) importants pour le reporting. Les pass-through columns vous permettent d’intégrer ceux-ci dans les modèles de sortie du package sans le forker :

vars:
  salesforce__opportunity_pass_through_columns:
    - name: custom_field__c
      alias: opportunity__custom_field
    - name: territory__c
      alias: opportunity__territory
      transform_sql: UPPER(territory__c)

L’option transform_sql est particulièrement utile — vous pouvez renommer, caster ou transformer le champ personnalisé à la volée. Cela évite d’avoir besoin d’un modèle intermédiaire séparé juste pour nettoyer un champ personnalisé.

Les pass-through columns sont disponibles pour les opportunités, les comptes, les contacts et les utilisateurs. Configurez-les pour chaque champ personnalisé dont vos parties prenantes ont besoin dans les rapports.

Support du mode historique

Le package s’intègre avec le mode historique Fivetran pour le suivi des changements dans le temps :

vars:
  salesforce__account_history_enabled: true
  salesforce__opportunity_history_enabled: true
  salesforce__contact_history_enabled: true
  global_history_start_date: '2024-01-01'

Lorsqu’activé, le package produit des modèles d’historique quotidiens qui montrent l’état de chaque enregistrement à chaque date. global_history_start_date limite la profondeur historique, contrôlant ainsi les coûts de stockage.

C’est une alternative à l’exécution de vos propres snapshots dbt. L’avantage est une intégration plus étroite avec le suivi des changements au moment de la synchronisation de Fivetran. L’inconvénient est qu’il est spécifique à Fivetran et ne capture pas les changements de champs de formule.

Support multi-org

Si votre entreprise utilise plusieurs orgs Salesforce (fréquent après des acquisitions ou avec des divisions régionales), le package prend en charge une colonne source_relation qui identifie l’org d’origine de chaque enregistrement :

vars:
  salesforce_sources:
    - database: raw_salesforce_us
      schema: salesforce
    - database: raw_salesforce_eu
      schema: salesforce

Chaque modèle inclut une colonne source_relation, et les modèles mart gèrent la déduplication inter-org le cas échéant.

dbt_hubspot

Package : fivetran/dbt_hubspot (v1.6.1) Nombre de modèles : Jusqu’à 147 modèles (tous les composants activés) Dépendances : fivetran/dbt_hubspot_source, fivetran/fivetran_utils

La configuration est critique

Le package HubSpot est beaucoup plus grand que celui de Salesforce car HubSpot couvre les ventes, le marketing et le service — trois domaines de produits distincts avec leurs propres modèles de données. N’activez que ce que vous utilisez :

vars:
  hubspot_sales_enabled: true
  hubspot_marketing_enabled: false
  hubspot_service_enabled: false

Si vous n’utilisez HubSpot que comme CRM de vente, désactiver le marketing et le service supprime ~100 modèles de votre DAG. Ce n’est pas seulement une question de temps de build — moins de modèles signifie un DAG plus simple, moins de points de rupture potentiels et un débogage plus facile.

Modèles de vente

Lorsque hubspot_sales_enabled: true, vous obtenez :

• Modèles de pipeline de deals — Deals enrichis avec les informations de stade, propriétaire et entreprise
• Modèles de contacts — Contacts avec suivi du stade de cycle de vie et associations d’entreprises
• Modèles d’entreprises — Entreprises avec métriques agrégées de deals et contacts
• Modèles d’engagement — Appels, emails, réunions, notes et tâches liés à leurs objets parents

Le package gère en interne la complexité des associations many-to-many de HubSpot. Les jointures de tables de liaison, la logique d’association primaire et la gestion des labels sont intégrées. Cela seul représente un effort de développement significatif épargné.

Modèles marketing (lorsqu’activés)

Les modèles marketing couvrent les événements email, les formulaires, les campagnes et le suivi UTM. Si vous utilisez HubSpot Marketing Hub, ceux-ci fournissent des modèles prêts à l’emploi pour les performances email, le suivi des soumissions de formulaires et l’attribution des campagnes.

Notez que les données marketing peuvent avoir un volume élevé. Les événements email (ouvertures, clics, rebonds) peuvent produire des millions de lignes. Si vous activez les modèles marketing, configurez la matérialisation incrémentale pour les tables d’événements.

Support multi-portail

Comme le package Salesforce, HubSpot prend en charge plusieurs portails via source_relation :

vars:
  hubspot_sources:
    - database: raw_hubspot_us
      schema: hubspot
    - database: raw_hubspot_eu
      schema: hubspot

Utiliser les deux packages ensemble

Beaucoup d’organisations utilisent simultanément Salesforce et HubSpot — Salesforce pour le CRM de vente, HubSpot pour l’automatisation marketing. Exécuter les deux packages dans le même projet dbt fonctionne, et les couches source ne créent pas de conflit car elles référencent des schémas sources différents.

Le défi se situe au niveau mart : vous pourriez vouloir des modèles unifiés combinant les opportunités Salesforce avec l’engagement marketing HubSpot. Les packages ne fournissent pas cela — vous le construisez vous-même en créant des modèles mart qui référencent les sorties des deux packages :

-- mrt__sales__opportunity_with_marketing.sql
WITH

opportunities AS (
    SELECT *
    FROM {{ ref('salesforce__opportunity_enhanced') }}
),

marketing_engagement AS (
    SELECT
        contact_id,
        COUNT(*) AS marketing_touches
    FROM {{ ref('hubspot__email_events') }}
    WHERE event_type = 'CLICK'
    GROUP BY 1
)

SELECT
    opportunities.*,
    COALESCE(marketing_engagement.marketing_touches, 0)
        AS opportunity__marketing_touches
FROM opportunities
LEFT JOIN marketing_engagement
    ON opportunities.contact_id = marketing_engagement.contact_id

Cette jointure inter-CRM nécessite une clé partagée — généralement l’adresse email ou un ID externe maintenu dans les deux systèmes. La qualité de la jointure dépend entièrement de l’hygiène des données dans les deux plateformes.

Compromis liés aux conventions de nommage

Les deux packages suivent les conventions de nommage de Fivetran : stg_salesforce__opportunity, salesforce__opportunity_enhanced. Si votre projet utilise des conventions différentes (comme le pattern double underscore avec des préfixes base__), vous avez deux options :

Accepter l’incohérence. Dans le namespace du package, les modèles utilisent le nommage Fivetran. Vos propres modèles utilisent votre nommage. C’est pragmatique et ce que la plupart des équipes font. Les modèles du package vivent dans leur propre schéma, donc la différence de nommage est contenue.

Encapsuler les sorties. Créez vos propres modèles mart qui référencent les sorties du package et suivent votre nommage :

-- mrt__sales__opportunity_enhanced.sql
SELECT
    opportunity_id AS opportunity__id,
    opportunity_name AS opportunity__name,
    -- ... renommer toutes les colonnes selon votre convention
FROM {{ ref('salesforce__opportunity_enhanced') }}

Cela ajoute des modèles à votre DAG mais vous donne une cohérence de nommage. Les modèles d’encapsulation servent aussi de frontière — si vous remplacez un jour le package Fivetran par des modèles personnalisés, seuls les modèles d’encapsulation doivent changer, pas chaque référence en aval.

Quand utiliser les packages vs construire en interne

Utilisez les packages lorsque :

• Votre configuration CRM est relativement standard (objets standard, workflows typiques)
• Vous souhaitez obtenir de la valeur rapidement sans partir de zéro
• Les modèles de sortie du package couvrent vos besoins de reporting
• Vous avez des pass-through columns pour gérer les champs personnalisés

Construisez en interne lorsque :

• Vous avez des objets personnalisés complexes que le package ne couvre pas
• Vos conventions de nommage sont non négociables et vous ne voulez pas de modèles d’encapsulation
• Vous avez besoin de patterns de modélisation spécifiques que le package ne prend pas en charge (hiérarchies de comptes complexes, multi-devises, logique d’attribution spécifique)
• Les 23+ modèles (Salesforce) ou 147 modèles (HubSpot) du package ajoutent trop de charge pour votre cas d’usage

Le chemin intermédiaire — utiliser le package source pour des modèles de base propres mais construire vos propres couches intermédiaires et mart — est souvent le meilleur compromis. Vous bénéficiez d’une gestion fiable de l’extraction sans vous engager dans les opinions du package au niveau mart.