Campos de tu mapeo
El mapeo que creaste para la importación se lee al revés para decidir qué sale. No hay una segunda lista que mantener, y un campo que nunca mapeaste no puede salir.
Sincronización bidireccional de CRM
Aquí, sincronización bidireccional significa que tus cambios de CRM vuelven al otro sistema solo después de que una persona lea la lista exacta y la apruebe. Nada se mueve como efecto de una edición. Cubre nueve sistemas, envía los campos que nombra tu mapeo y registra lo que respondió el proveedor. Los cambios en sentido contrario llegan con una importación repetida.
Está construido y probado en nuestro propio entorno. No se ha ejecutado contra una cuenta real de ningún proveedor y sigue apagado hasta que eso ocurra. Si quieres estar entre los primeros, escríbenos y te diremos cuándo puede abrirse para tu cuenta.
Cada campo que nombra el mapeo guardado de la conexión, incluidos los personalizados, y nada que no nombre.
El mapeo que creaste para la importación se lee al revés para decidir qué sale. No hay una segunda lista que mantener, y un campo que nunca mapeaste no puede salir.
HubSpot, Pipedrive, Dynamics 365, Salesforce, Zoho y Fireberry aceptan los tres. monday.com, Zebra y MyBusiness aceptan contactos.
Se quedan fuera a propósito. Son identidad, relaciones y dinero, y el mismo límite se aplica a la entrada, así que una sincronización no puede reasignar un cliente ni cambiar el valor de un acuerdo.
Un valor vacío nunca se envía. Borrar un campo aquí no lo borra en el otro sistema, de modo que un registro a medias no puede eliminar los datos buenos que hay al lado.
Cada fila en espera muestra el registro y los campos que enviaría. Editar un registro que ya espera actualiza la fila, así que sale su valor actual.
Cada fila guarda lo enviado y lo que contestó el proveedor. Una fila fallida sigue visible con su motivo y se puede reintentar sin empezar de nuevo.

La cobertura depende de lo que acepta la API de cada proveedor. Un tipo de registro que no aparece aquí no se puede escribir.
| Sistema | Registros que recibe | Cómo se encuentra un registro | Campos personalizados |
|---|---|---|---|
| HubSpot | Contactos, empresas, acuerdos | El vínculo de tu importación | Sí, desde el mapeo |
| Pipedrive | Contactos, empresas, acuerdos | El vínculo de tu importación | Sí, desde el mapeo |
| Microsoft Dynamics 365 | Contactos, empresas, acuerdos | El vínculo de tu importación | Si tu mapeo nombra alguno |
| Salesforce | Contactos, empresas, acuerdos | El vínculo de tu importación | Sí, desde el mapeo |
| Zoho CRM | Contactos, empresas, acuerdos | El vínculo de tu importación | Sí, desde el mapeo |
| Fireberry | Contactos, empresas, acuerdos | El vínculo de tu importación | Si tu mapeo nombra alguno |
| monday.com | Contactos | El vínculo de tu importación | Si tu mapeo nombra alguno |
| Zebra | Contactos | Un campo que eliges, como el correo | Todavía no |
| MyBusiness | Contactos | Correo, solo con una coincidencia exacta | Todavía no |
Zebra y MyBusiness reciben cambios, pero no se puede importar desde ellos. En Fireberry, monday.com y MyBusiness la ruta de actualización aún debe confirmarse en una primera ejecución real, y MyBusiness necesita un ID de aplicación del proveedor.
Un propietario o administrador la activa. La primera revisión empieza en ese momento, así que activarla no lista todo lo que una importación tocó alguna vez.
Una revisión lista los registros vinculados que cambiaron desde la anterior, hasta doscientos cada vez, y continúa donde se detuvo. No envía nada.
Una persona lee las filas y aprueba. La aprobación queda ligada a una huella de esa lista exacta, así que una lista que cambió después necesita otra aprobación.
Cada fila muestra la respuesta del proveedor. Las filas fallidas siguen en la lista con un código, para que corrijas la causa y las reintentes.
Una sincronización continua parece cómoda hasta el día en que una importación mala o un mapeo equivocado reescribe miles de registros en un sistema del que depende otro equipo. Cuando alguien lo nota, los valores antiguos han desaparecido y los dos sistemas coinciden en la respuesta incorrecta. Escribir en el sistema de otra empresa es lo más arriesgado que hace una integración, así que aquí se trata como enviar una campaña: lo prepara el software y lo libera una persona.
Por eso hay tres cierres y no uno. El servicio tiene que permitirlo, la conexión tiene que activarlo y una persona tiene que aprobar una lista cuya huella coincide con lo que leyó. No hay ninguna ruta de API ni herramienta MCP que envíe. Un asistente puede mostrarte lo que espera y ayudarte a decidir, y ahí se detiene.
El otro sentido también es deliberado. Los cambios hechos en el otro sistema llegan cuando repites la importación. Los campos vacíos se rellenan, tus valores existentes se quedan y un nombre de contacto distinto va a la cola de conflictos. Así tienes dos sistemas que se mantienen cerca, con personas al mando de las diferencias, y no dos sistemas compitiendo por sobrescribirse.
Si necesitas alguna de estas cosas, es mejor saberlo ahora.
Esto es trabajo por lotes con una aprobación en medio. Si un cambio debe llegar a otro sistema al instante, usa los webhooks firmados y la API, y construye ese flujo por tu lado.
Están excluidos por diseño y la exclusión no es un ajuste. Si tu proceso necesita cambiarlos en el otro sistema, cámbialos allí.
No está activado y ningún proveedor se ha probado con una cuenta real. Preferimos decirlo antes de que tu primer lote sea la prueba.
Clear answers
Nombra el sistema y los registros que importan. Te diremos qué está probado, qué no y cuándo puede abrirse para ti.