Respuesta breve
Un campo ausente, null, texto vacío, cero y false no deben tratarse automáticamente como el mismo dato. Define conservar, borrar o actualizar según el contrato de la API. Prueba cada caso sobre un registro ficticio y comprueba el destino, no solo el valor mostrado por el módulo.
Comprobación clave: Los cinco casos producen el resultado contractual y cero o false no se sustituyen por defecto involuntariamente.
Fuentes y límites de esta guíaUna actualización sin teléfono borra el número existente; otra cambia una cantidad cero por el valor anterior. Ambas pueden venir de una regla genérica de vacío. Esta guía propone un contrato de campos y una prueba pequeña, sin modificar un CRM real ni presentar una fórmula universal para cualquier conector.
Definir intención antes de mapear
| Entrada ficticia | Significado propuesto | Resultado contractual |
|---|---|---|
| Campo ausente | Sin actualización de ese campo | Conservar |
| null | Petición explícita de borrado | Borrar solo si la API lo admite |
| Texto vacío | Dato inválido en este ejemplo | Revisar |
| 0 | Cantidad válida | Guardar cero |
| false | Opción desactivada | Guardar false |
Son reglas del ejercicio, no comportamiento garantizado de todas las API. Algunas no permiten borrar con null; otras omiten campos vacíos. Separa tipo y presencia antes de enviar. La cadena «0» tampoco es necesariamente el número cero: valida el tipo esperado en destino.
Funciones documentadas de Make
Make documenta ifempty, omit y la palabra erase, con efectos diferentes. El tipo del campo influye en erase. Consulta la definición y comprueba salida real del módulo; no uses el nombre de una función como prueba de cómo la API procesa una petición.
Prueba pequeña y reversible
Crea un registro ficticio con valores conocidos y aplica por separado las cinco entradas. Guarda cuerpo enviado, respuesta y lectura posterior del registro. Repite desde el mismo estado inicial: probar sobre lo que dejó el caso anterior dificulta detectar errores. Evita colocar claves o datos personales en capturas.
Aceptar sin falsa universalidad
CallsIQ no ha ejecutado esta prueba en Make. La aceptación exige cambios previstos y ausencia de borrados accidentales; cambia el contrato cuando cambie el conector. Con poco volumen, revisión manual puede bastar. Automatizar un campo mal definido multiplica errores en vez de resolverlos.
Fuentes y límites de esta guía
Revisión documental: . Tipo de contenido: Guía documental con ejercicio original.
Las fuentes describen condiciones y funciones declaradas por sus responsables. Los protocolos propuestos y los ejemplos ficticios no acreditan pruebas de producto realizadas por CallsIQ.
- ifempty, omit y la palabra erasehelp.make.com
Consulta las condiciones actuales
Valora estas opciones si resuelven el problema descrito. Confirma funciones, límites y contratación en tu país.
MakeEnlace de afiliaciónLos enlaces comerciales identificados pueden generar una comisión o recompensa por referido para CallsIQ. Nuestra política comercial.
Fuentes oficiales, cálculos explicados y ejemplos identificados. Consulta la metodología y el uso de IA en la redacción.