Arquitectura de sincronización nativa de HubSpot

Contexto y Problema

La sincronización nativa entre HubSpot y Airtable fallaba anteriormente debido a desajustes estructurales. Ambas plataformas carecían de metadatos obligatorios compartidos (Nombre del Deal, Etapa del Deal, Marca de tiempo de última modificación y un ID único de registro) y utilizaban distintas convenciones de nomenclatura para las etapas del pipeline. Esta falta de alineación obligó a la empresa a depender de un middleware de terceros costoso (Pipedream) que actuaba como traductor de datos entre ambos sistemas.

Solución

Se diseñó un motor de sincronización nativa utilizando un sistema de espejo de "Ghost Property":

• Capa de Metadatos: Creación de campos puente en Airtable (RecordID, Timestamps, AWS UUID) para activar los pulsos de sincronización nativa.
• Propiedades de Traducción: Construcción de "Ghost Properties" espejo tanto en Airtable (tablas de Engagement y Transaction) como en HubSpot para capturar los datos de sincronización.
• Traducción Automatizada: Implementación de automatizaciones en Airtable (AT $\rightarrow$ HS) y workflows en HubSpot (HS $\rightarrow$ AT) que traducen automáticamente los nombres internos de las etapas a formatos que la otra plataforma puede interpretar.
• Integración de AWS UUID: Solicitud de UUIDs independientes de la plataforma desde Amazon Web Services para utilizarlos como clave principal de sincronización.

Impacto Esperado

• Reducción de Costes: Sustituye y elimina la necesidad de middleware de alto coste (Pipedream).
• Alineación Operativa: Garantiza que las etapas en HubSpot y Airtable se mantengan perfectamente sincronizadas sin intervención manual.
• Escalabilidad y Preparación a Futuro: Al incorporar UUIDs de AWS como clave primaria, la arquitectura está diseñada para el largo plazo. Si Airtable se descontinúa en el futuro, HubSpot ya estará mapeado de forma nativa con la base de datos en AWS, permitiendo una transición fluida.