Acuerdos de tratamiento de datos: qué cambia al cambiar de proveedor
Cambiar de proveedor de datos de ubicación no es solo una decisión técnica. Esto es lo que debes revisar en el tratamiento de datos y la privacidad al hacer el cambio.
Migrar una automatización de Zapier o Make a un nuevo host de geocodificación
Las automatizaciones creadas en Zapier o Make suelen incluir un paso de geocodificación dentro de un flujo de trabajo más amplio: llega un nuevo cliente potencial a través de un formulario, su dirección se geocodifica para comprobar la asignación de territorio y el resultado activa una decisión de enrutamiento más adelante en la cadena. Con frecuencia, estos flujos los crea alguien sin formación en ingeniería de software, con el conector prediseñado o el módulo HTTP genérico que ofrecía la plataforma en ese momento, lo que cambia cómo es realmente una migración en comparación con un código a medida.
Si tu paso de geocodificación actual usa un conector dedicado, una integración oficial creada por Zapier o Make específicamente para ese proveedor, migrar a un proveedor sin un conector dedicado equivalente implica cambiar ese paso por un módulo HTTP o webhook genérico, configurado para llamar directamente a la API del nuevo proveedor. Es un cambio real en cómo está construida la automatización, no un simple cambio de credenciales, y conviene probar a fondo el paso de sustitución en un escenario de prueba aislado antes de tocar una automatización en producción de la que dependen otras partes de un negocio.
Pasos concretos para hacer este cambio:
- Duplica la automatización existente en el editor de la plataforma en lugar de editarla directamente, para que la versión que funciona siga ejecutándose hasta que la versión de sustitución esté totalmente probada
- Sustituye el paso de geocodificación por un módulo HTTP genérico, configurado con el endpoint y la autenticación del nuevo proveedor, ya que una clave en un parámetro de consulta o una cabecera
Authorization: Bearer(ambas admitidas aquí) son fáciles de configurar en un módulo HTTP genérico sin necesidad de un conector dedicado - Asigna los campos de la respuesta manualmente en el paso de mapeo de datos de la automatización, ya que un módulo HTTP genérico devuelve datos de respuesta en bruto que hay que asignar explícitamente a los campos que esperan los pasos posteriores de la automatización, a diferencia de un conector dedicado, que a menudo hace esta asignación automáticamente
- Prueba con una variedad de entradas reales, incluidos casos límite como direcciones incompletas o con formato inusual, ya que es exactamente el tipo de prueba que resulta fácil saltarse en una herramienta sin código, donde el «código» en sí no está a la vista para revisarlo como lo estaría un script
- Cambia el disparador de la versión de prueba a la automatización duplicada y verificada, y solo entonces desactiva la original, una vez que hayas confirmado que la nueva funciona correctamente con datos reales durante un breve periodo
Como un host compatible reproduce la forma de respuesta exacta de un proveedor conocido, si el paso de geocodificación de tu automatización original llamaba a un proveedor que tiene aquí un host compatible equivalente, el mapeo de campos del paso 3 anterior puede parecerse mucho al que tu conector original ya usaba internamente, lo que puede acortar notablemente esta migración. La lista completa de hosts compatibles está en /compatibility/, y conviene consultarla antes de dar por hecho que hace falta un mapeo de campos desde cero.
Para una automatización crítica para el negocio, la precaución adicional de probar en un duplicado en lugar de editar en producción merece el poco tiempo extra de configuración, ya que una automatización de enrutamiento de clientes potenciales rota suele notarse rápido, y la notan personas ajenas al equipo técnico.