Por Nicho Agencia Digital · Publicado el

1. Delimita qué puede actualizar cada archivo

Define si el lote puede crear registros, actualizar existentes o ambas cosas. Para una actualización semanal, considera empezar con “solo actualizar”: un identificador desconocido queda pendiente en vez de crear un contacto inesperado. La ausencia de una persona en el archivo tampoco debería eliminarla del CRM.

Usa un identificador estable del sistema de origen junto con la cuenta o fuente correspondiente. Conserva su equivalencia con el registro del CRM; no uses la posición de la fila. Si un identificador aparece dos veces con valores incompatibles, rechaza ese caso para revisión.

Acuerda qué campos controla la fuente. Un archivo de cobertura comercial puede actualizar la zona, pero no necesariamente el responsable, las notas o las preferencias de contacto.

2. Separa conservar, reemplazar y borrar un valor

Documenta una política explícita por campo. Como punto de partida para actualizaciones:

  • Columna ausente: no modificar ese campo.
  • Celda vacía: conservar el valor actual, salvo otra regla aprobada.
  • Valor válido: reemplazar únicamente un campo permitido.
  • Borrado solicitado: usar una operación explícita, revisable y limitada a campos que admitan quedar sin dato.

Un texto vacío, un valor nulo y el texto literal “NULL” pueden representar cosas distintas. La documentación de COPY de PostgreSQL explica que CSV no tiene una convención estándar para distinguir nulo de cadena vacía y describe su propia interpretación mediante comillas. Esa regla no se puede trasladar automáticamente a cualquier CRM.

Prueba también espacios y ceros: un espacio no expresa necesariamente un borrado y cero puede ser un valor válido.

3. Valida cada fila antes de proponer cambios

Lee el archivo en un área temporal, sin tocar las fichas comerciales. Comprueba encabezados, separador, codificación y cantidad de columnas. Si la estructura impide identificar filas confiablemente, detén el lote completo en vez de intentar rescatar valores desplazados.

OWASP recomienda validar sintaxis y significado, además de ejecutar controles en el servidor. En este flujo, una fecha debe tener formato aceptado y una etapa debe pertenecer al embudo indicado.

Entrega errores con referencia de fila, identificador, campo, motivo y corrección esperada. Por ejemplo: “Fila 18, zona: código no reconocido; selecciona una zona activa”. Conserva la referencia original aunque el usuario ordene el reporte. Muestra únicamente los datos necesarios a personas autorizadas.

4. Presenta una vista previa que permita decidir

Resume registros por crear, actualizar, conservar sin cambios, rechazar y revisar por conflicto. Para cada modificación, muestra campo, valor actual y valor propuesto. Destaca borrados y cambios de responsable; un contador global no permite evaluar su impacto.

La aprobación debe corresponder al archivo y las reglas revisadas. Guarda su huella, el mapeo de columnas y la versión de las reglas. Si cambia alguno, genera otra vista previa.

Al aplicar, comprueba dentro de la escritura que el registro sigue en la versión revisada. Si alguien lo modificó, detén esa fila para comparar, sin imponer el CSV antiguo. Este control complementa la prevención de sobrescrituras por ediciones simultáneas.

5. Elige entre lote completo y aplicación parcial

Decide antes de confirmar qué ocurre si una fila falla. Si varias filas forman una operación inseparable, agrúpalas para que se apliquen juntas. Si son independientes, puedes permitir aplicar las válidas y dejar las demás pendientes, con un resultado inequívoco por fila.

PostgreSQL describe las transacciones como operaciones de todo o nada. El equipo técnico debe definir si esa unidad será una fila, un grupo o el lote completo. No mantengas una transacción abierta mientras alguien revisa la pantalla.

Revisa también automatizaciones: actualizar una ficha podría disparar avisos o tareas. Define cuáles corresponden a una importación y cómo evitar repetirlos; no supongas que revertir datos deshace mensajes enviados.

6. Ejemplo hipotético de una actualización semanal

Una distribuidora ficticia de Colombia recibe 120 filas para actualizar zonas y teléfonos. La vista previa clasifica 80 como actualizaciones, 30 sin cambios, ocho con códigos inválidos y dos con conflictos de versión. Son cifras inventadas, no resultados de un cliente de Nicho.

Dentro de las 80 actualizaciones, cinco filas traen teléfono vacío y una zona nueva. Según la política acordada, cambian de zona y conservan el teléfono. Los responsables comerciales permanecen intactos porque ese campo no está autorizado.

El equipo aprueba la aplicación parcial: confirma las 80 actualizaciones y conserva diez pendientes identificadas. Las correcciones posteriores generan otro lote vinculado al primero y pasan nuevamente por validación y vista previa.

7. Reintenta lo pendiente sin repetir lo confirmado

Asigna un identificador al lote y conserva el resultado de cada operación. Si la pantalla pierde conexión, consulta ese identificador antes de reenviar el archivo. Un tiempo de espera agotado no demuestra que la escritura falló.

Diseña el reintento para reconocer operaciones ya confirmadas y continuar solo las pendientes. Guarda el resultado y la modificación de forma atómica cuando compartan base de datos. El nombre del archivo o su huella, por sí solos, no sustituyen ese control.

Un archivo corregido debe conservar el vínculo con los errores anteriores, pero requiere nueva revisión. Evita reproducir automáticamente todo el lote original: podría sobrescribir cambios hechos después por el equipo.

8. Prepara una recuperación que respete el trabajo posterior

Guarda quién aprobó, qué campos cambiaron y sus valores anteriores y posteriores, con acceso restringido. Para deshacer un lote confirmado, prepara una propuesta inversa y verifica la versión actual de cada registro. Si hubo modificaciones posteriores, requiere revisión en lugar de restaurar silenciosamente el valor antiguo.

Antes de habilitar el proceso, ensaya celdas vacías, identificadores repetidos, cambios concurrentes y desconexión después de guardar. Comprueba también el reintento y la recuperación de un lote parcial. Si descargas errores para corregirlos en una hoja, aplica las precauciones de exportación CSV segura. Cierra el lote cuando sus resultados y excepciones tengan un destino comprobable, no solo cuando termine la barra de progreso.

El siguiente paso

Revisemos qué archivos alimentan tu CRM, qué campos pueden cambiar y cómo mostrar diferencias y errores antes de aplicar cada lote.

CRM personalizado para empresas · Conversar sobre tu proyecto ↗

Fuentes y alcance

Fuentes consultadas el 21 de octubre de 2026. Las recomendaciones de proceso son propuestas editoriales de Nicho; los ejemplos identificados como hipotéticos no representan resultados de clientes.

Contenido preparado con asistencia de IA y comprobaciones automáticas. No sustituye una evaluación de tu implementación ni garantiza resultados. Escríbenos si encuentras algo que debamos corregir.