Un proyecto pequeño que puedes revisar
El objetivo es copiar solicitudes ficticias completas a una tabla de salida. No enviaremos mensajes ni usaremos IA. Así puedes aprender disparadores, campos y filtros antes de añadir pasos más difíciles. Necesitas acceso autorizado a Make y a hojas de cálculo de prueba; los planes y límites son independientes del curso.
Los nombres de módulos y pantallas pueden variar. Comprueba en la documentación actual el conector y el disparador disponibles en tu cuenta. Si no puedes conectar herramientas, diseña el recorrido en papel y verifica primero la lógica.
Prepara dos hojas distintas
Entrada: código, categoría y descripción. Salida: los mismos campos más estado. Utiliza solo datos inventados. Crea PR-001 con descripción, PR-002 sin descripción y PR-003 con descripción. No utilices la misma hoja como entrada y salida: podrías volver a procesar tus propios resultados.
Construye la versión mínima
1. Crea un escenario de prueba con un disparador del conector de hojas que observe nuevas filas, si tu acceso lo permite. 2. Selecciona únicamente la hoja de entrada y comprueba una muestra de datos. 3. Añade un filtro antes de la escritura: código y descripción deben existir y contener información útil. 4. Añade una acción que cree una fila en la hoja de salida. 5. Mapea cada campo de origen a su columna y establece estado «pendiente de revisión». 6. Ejecuta una prueba controlada y revisa entrada, filtro y salida antes de programar ejecuciones.
La documentación de Make explica que un filtro permite continuar solo a los datos que cumplen sus condiciones. Comprueba además qué entiende tu conector por vacío: una celda con espacios podría requerir otra validación.
Qué deberías observar
PR-001 y PR-003 deben tener una fila de salida. PR-002 no debe recorrer la ruta normal. El estado es pendiente; no has aprobado una solicitud. Compara las columnas para detectar si descripción ha acabado accidentalmente en categoría.
La prueba no termina con el caso correcto
Añade una fila con espacios en descripción y revisa el resultado. Prueba una fila nueva después de configurar el disparador, porque el punto de inicio puede afectar qué filas se leen. Anota también qué ocurre al repetir una ejecución: esta versión mínima no garantiza evitar duplicados.
Antes de utilizar el flujo de forma habitual, añade identificación de registros ya procesados y tratamiento de errores. Mantén la programación desactivada mientras validas y guarda instrucciones para detener el escenario. Errores y duplicados en automatizaciones: pruebas antes de activar un flujo enseña cómo pensar estos controles.
Cuándo profundizar
Curso de Automatizaciones Básicas con Make (Platzi) cubre filtros y errores en Make. Curso de Make - Automatiza con Make (Udemy) ofrece un recorrido más extenso, con partes técnicas y precio actual sin confirmar. Masterclass de automatizaciones con IA (Raiola Networks) permite explorar herramientas gratuitamente. No añadas un paso de IA hasta poder explicar y revisar este flujo sin él.
Prueba guiada: registrar solicitudes una sola vez
Ejemplo ficticio. Los tiempos son estimaciones editoriales de práctica, no tiempos medidos ni garantías de resultado.
Datos de prueba
| Código | Categoría | Descripción |
|---|---|---|
| PR-001 | material | Solicito dos carpetas para el archivo. |
| PR-002 | material | [vacío] |
| PR-003 | [vacío] | Solicito etiquetas para organizar documentos. |
| PR-001 | material | Solicito dos carpetas para el archivo. |
Regla exacta
Una solicitud válida debe tener código, categoría y descripción. El código identifica la solicitud. Si ya existe en la hoja de salida, no se crea otra fila. Una solicitud incompleta se envía al registro de revisión. Dos eventos con el mismo código se tratan como la misma solicitud en esta práctica; no como una corrección. Si quisieras permitir modificaciones, necesitarías otra regla explícita.
Pasos de ensayo
- Crea una hoja de salida con Código, Categoría, Descripción y Estado.
- Crea un registro separado de revisión con Código y Motivo.
- Define un disparador de ensayo que reciba los cuatro eventos uno a uno. Puedes usar un formulario y una hoja de entrada si tienes autorización y acceso.
- Comprueba primero que los tres campos estén presentes; un texto de espacios debe tratarse como vacío.
- Para una entrada completa, busca si el código ya aparece en la salida.
- Si no existe, añade una fila con Estado = pendiente de revisión. Si existe, conserva la fila y registra el evento duplicado para comprobarlo.
- Ejecuta el ensayo de forma secuencial. Antes de permitir ejecuciones paralelas, añade una garantía de unicidad o bloqueo adecuada: buscar y después insertar no evita por sí solo una carrera entre dos ejecuciones simultáneas.
Resultado esperado
La hoja principal termina con una fila: PR-001, material, «Solicito dos carpetas para el archivo.», pendiente de revisión. PR-002 y PR-003 van al registro de revisión porque les falta un campo. El cuarto evento se identifica como duplicado y no crea una segunda fila.
Diagrama del proceso
Un evento por solicitud
Código, categoría y descripción
Indicar el campo que falta
Buscar en la hoja de salida
No añadir otra fila
Estado: pendiente de revisión
Qué debes revisar en la herramienta
Comprueba qué campos expone el conector que uses y adapta el mapeo a sus nombres actuales. Este ejemplo define la lógica; no presupone un módulo universal que funcione igual con cualquier cuenta o conector. Mantén el ensayo manual y evita envíos automáticos de mensajes. Consulta los permisos y costes antes de conectar servicios de trabajo.
Después conviene estudiar Errores y duplicados en automatizaciones.
Lección editorial con ejemplos ficticios. Los cursos recomendados se describen a partir de sus fichas públicas; no implica que los hayamos completado. Revisión inicial: 4 de octubre de 2026.