Flujos de revisión y aprobación con InDesign Server: PDFs de prueba automáticos y gestión de correcciones
En cualquier proceso editorial hay un momento inevitablemente humano: alguien tiene que revisar, aprobar y devolver correcciones antes de que el documento salga al mundo. El problema es que ese momento suele ser también el más caótico: PDFs que se mandan por email, comentarios en hilos interminables de respuestas, versiones que se pisan unas a otras y aprobaciones que llegan —o no llegan— sin registro alguno.
InDesign Server no solo genera documentos automáticamente: también puede integrarse en un flujo de revisión y aprobación completamente estructurado. Esto significa enviar PDFs de prueba de forma automática en cuanto se genera un borrador, recoger correcciones anotadas por los revisores y relanzar la composición con los cambios aplicados, todo sin que el equipo de diseño tenga que hacer de mensajero.
Este artículo describe el flujo completo: qué herramientas se combinan, cómo se estructuran los scripts, qué formatos de corrección funcionan mejor y cómo garantizar que cada versión aprobada quede trazada con fecha y autor. Una guía de validación editorial real, no un manual de Adobe.
100%
trazabilidad de aprobaciones con fecha y autor
−65%
tiempo medio de ciclo de revisión editorial
0
versiones perdidas o aprobaciones sin registrar
Por qué los flujos de revisión editorial se rompen
Antes de construir la solución, conviene identificar exactamente dónde se rompe el proceso habitual. No es un problema de personas — es un problema de infraestructura. Los equipos editoriales sin flujo automatizado suelen sufrir una combinación de estos síntomas:
Los 6 síntomas del flujo de revisión roto
- El PDF correcto no llega al revisor correcto. Se manda manualmente, a veces al email equivocado, a veces tarde.
- Las correcciones llegan en formatos dispares: capturas de pantalla con anotaciones hechas a mano, correos con texto plano, llamadas de teléfono.
- No hay versión única: el diseñador trabaja sobre la v3, el revisor comenta la v2 y el director aprueba la v1.
- Sin deadline automático: si el revisor no contesta, el proceso se para sin que nadie lo note.
- Sin registro de aprobación: en caso de error post-publicación, nadie sabe quién aprobó qué ni cuándo.
- El rediseño de correcciones vuelve a empezar el ciclo desde cero, sin automatización, con el mismo riesgo de error.
Arquitectura del flujo automatizado
El sistema se articula alrededor de tres momentos clave: generación del PDF de prueba, distribución y recogida de correcciones y aplicación de cambios y nueva ronda. InDesign Server es el motor de generación; el orquestador del flujo puede ser tan sencillo como un script Python con envío por email o tan sofisticado como una integración con una plataforma de revisión PDF dedicada como Aproove o Ziflow.
Flujo completo
Datos actualizados
XML / DB / ERP
InDesign Server
Genera PDF prueba
Envío automático
Al/los revisor/es
Correcciones
Anotaciones PDF
Aprobación
Registro con firma
Stack tecnológico mínimo viable
Motor de composición
Adobe InDesign Server (v19+), ejecutando scripts ExtendScript o vía SOAP API
Orquestación del flujo
Script Python/Node.js, o plataforma de revisión PDF (Aproove, Ziflow, GoProof)
Distribución de PDFs
Email con enlace (SMTP/SendGrid) o carpeta compartida con notificación
Recogida de correcciones
Anotaciones PDF nativas (Acrobat Reader), formulario web o plataforma XFDF
Registro de aprobaciones
Base de datos (PostgreSQL/SQLite) o hoja de cálculo con webhook
Almacenamiento de versiones
Carpeta con nomenclatura estructurada + copia inmutable en S3/NAS
El proceso paso a paso
Generación del PDF de prueba con InDesign Server
Composición automática del borrador revisable
El PDF de prueba no es el PDF final. Tiene marcas visuales que lo identifican inequívocamente como borrador: una marca de agua diagonal con el número de versión, la fecha y hora de generación en el pie de página, y opcionalmente un código de color en los márgenes para identificar de qué sección del flujo de aprobación se trata (revisión técnica, revisión de precios, revisión legal…).
InDesign Server genera este PDF usando un preset de exportación específico para pruebas — resolución reducida (150 dpi), perfil sRGB, sin marcas de imprenta — lo que hace los archivos ligeros y fáciles de revisar en pantalla. El preset de producción final se aplica solo tras la aprobación definitiva.
// ExtendScript — generación de PDF de prueba con marca de agua
function generarPDFPrueba(doc, versionNum, revisorId) {
var timestamp = new Date().toISOString().slice(0,16).replace('T',' ');
// Insertar marca de agua de borrador
var masterSpread = doc.masterSpreads.item(0);
var watermark = masterSpread.textFrames.add();
watermark.geometricBounds = ['20mm','10mm','280mm','200mm'];
watermark.contents = 'BORRADOR v' + versionNum + ' — NO IMPRIMIR';
watermark.textFramePreferences.verticalJustification = VerticalJustification.CENTER_ALIGN;
watermark.parentStory.texts[0].appliedFont = 'Helvetica';
watermark.parentStory.texts[0].pointSize = 72;
watermark.parentStory.texts[0].fillColor = doc.colors.add({
model: ColorModel.PROCESS, colorValue: [0,0,0,15], name:'WatermarkGray'
});
watermark.rotationAngle = -45;
// Añadir metadata de revisión en pie
doc.epSFields.add({ name:'revision_version', value: String(versionNum) });
doc.epSFields.add({ name:'revision_timestamp', value: timestamp });
doc.epSFields.add({ name:'revisor_id', value: revisorId });
// Exportar con preset de prueba (150 dpi, sRGB, sin sangrado)
var presetPrueba = app.pdfExportPresets.item('Prueba_Revisores');
var outputPath = '/revisiones/prueba_v' + versionNum + '_' + revisorId + '.pdf';
doc.exportFile(ExportFormat.PDF_TYPE, File(outputPath), false, presetPrueba);
// Eliminar marca de agua del master antes de cerrar (no afecta al INDD maestro)
watermark.remove();
return outputPath;
}Importante: dos presets, no uno
Mantén siempre dos presets PDF distintos en InDesign Server: uno para pruebas (ligero, pantalla, con marca de agua) y otro para producción (CMYK, sangrado, alta resolución). El preset de producción nunca debe activarse hasta recibir la aprobación final registrada en el sistema.
Distribución automática a los revisores
Quién recibe qué y cuándo — sin intervención manual
Cada publicación tiene asociada una tabla de revisores en la base de datos del flujo: qué personas deben revisar qué secciones, en qué orden y con qué plazo. El orquestador lee esta tabla en cuanto InDesign Server confirma que el PDF de prueba está listo y lanza los envíos.
El email incluye el PDF adjunto o un enlace a la carpeta compartida, la lista de cambios respecto a la versión anterior (generada automáticamente comparando el XML actual con el anterior), el plazo de respuesta y un enlace de un solo clic para marcar «Sin correcciones — Aprobado» si el revisor no tiene comentarios.
Plantilla de email automático de revisión
Asunto: [Revisión pendiente] Catálogo Primavera 2026 — v3 — Responder antes del 29/03 12:00h
Hola Marta,
Se ha generado automáticamente la versión 3 del Catálogo Primavera 2026. Necesitamos tu aprobación como responsable de la sección Moda Mujer antes del viernes 29 de marzo a las 12:00h.
Cambios respecto a la versión anterior (v2):
- Página 14 — precio del artículo REF-2847 actualizado de 39,90€ a 34,90€
- Página 17 — imagen de producto REF-3012 sustituida por nueva fotografía
- Páginas 18–20 — textos traducidos al inglés revisados por traducción
Recordatorios automáticos
El orquestador envía un recordatorio a las 24h si no se ha recibido respuesta, y una alerta al responsable editorial a las 4h del deadline si todavía hay revisores pendientes. Esto elimina el seguimiento manual y garantiza que el proceso nunca se bloquee silenciosamente.
Recogida estructurada de correcciones
Cómo convertir comentarios libres en datos procesables
El punto más crítico de cualquier flujo de revisión es transformar los comentarios humanos — que son naturalmente caóticos — en instrucciones que el sistema pueda procesar. Hay tres enfoques posibles, de menor a mayor estructuración:
Anotaciones PDF nativas (Acrobat)
El revisor abre el PDF en Adobe Acrobat Reader, hace anotaciones directamente sobre el documento (notas, resaltados, tachados, rectángulos de área) y devuelve el PDF anotado. El sistema extrae los comentarios mediante la librería pdfminer o PyMuPDF en Python, los estructura por página y los registra en la base de datos del flujo.
Formulario web de correcciones estructurado
El link del email lleva a una interfaz web donde el revisor ve el PDF renderizado página a página y puede añadir correcciones en campos predefinidos: tipo de cambio (precio / texto / imagen / layout), número de página, referencia de elemento, valor actual y valor propuesto. Cada corrección queda guardada como registro JSON.
Plataforma de revisión PDF especializada
Herramientas como Aproove, Ziflow o GoProof gestionan todo el ciclo: envío, versionado, anotaciones, comparación de versiones, checklists de aprobación y registro de auditoría. Se integran con InDesign Server vía API REST. Es la solución más robusta para equipos grandes o publicaciones regulares de alto volumen.
// Python — extracción de anotaciones de un PDF revisado (Nivel 1)
import fitz # PyMuPDF
def extraer_correcciones_pdf(pdf_path: str) -> list[dict]:
"""Extrae anotaciones de un PDF revisado por Acrobat."""
doc = fitz.open(pdf_path)
correcciones = []
for page_num, page in enumerate(doc, start=1):
for annot in page.annots():
if annot.type[0] in (8, 9, 10, 11): # Text/FreeText/Square/Highlight
correcciones.append({
'pagina': page_num,
'tipo': annot.type[1],
'autor': annot.info.get('title', 'Desconocido'),
'fecha': annot.info.get('modDate', ''),
'contenido': annot.info.get('content', '').strip(),
'rect': list(annot.rect), # coordenadas del área anotada
})
doc.close()
return correcciones
# Uso:
correcciones = extraer_correcciones_pdf('/revisiones/prueba_v3_marta.pdf')
# Guardar en DB para procesamiento posterior
registrar_correcciones_en_db(correcciones, version=3, revisor='marta')Aplicación de correcciones y regeneración
Cerrar el ciclo: del comentario al PDF corregido
Una vez recogidas todas las correcciones, el orquestador presenta al diseñador (o al responsable editorial) una pantalla de revisión consolidada: todos los comentarios de todos los revisores, agrupados por página, con el revisor que los emitió y marcados como pendientes de aplicar. Para correcciones de datos puros (precios, textos de producto, referencias) el sistema puede aplicarlas directamente actualizando el XML de origen y relanzando InDesign Server sin intervención humana.
Clasificación de correcciones por tipo de aplicación
Corrección de dato
Ej: Precio de REF-2847 pasa de 39,90€ a 34,90€
Automática — actualización en XML + relanzar IDS
Corrección de texto editorial
Ej: Cambiar «Disponible en tienda» por «Solo online»
Semiautomática — edición en tabla de textos + relanzar IDS
Sustitución de imagen
Ej: La foto de REF-3012 no tiene fondo blanco, sustituir
Manual — el diseñador actualiza el asset en DAM, luego relanzar IDS
Cambio de layout
Ej: Mover la caja de precio al lado derecho de la imagen
Manual en plantilla INDD — requiere diseñador + re-parametrizar IDS
Re-generación encadenada
Cuando se aplican correcciones y se relanza InDesign Server, el sistema debe incrementar automáticamente el número de versión del PDF, actualizar el registro en la base de datos y enviar la nueva prueba solo a los revisores que tenían correcciones pendientes. Los revisores que ya habían aprobado no reciben nuevo email salvo que los cambios afecten a su sección.
Registro de aprobación y trazabilidad
La parte más olvidada — y la más importante
Cada aprobación debe quedar registrada con cuatro datos mínimos: quién aprobó, cuándo, qué versión del PDF y desde qué IP o dispositivo. Este registro no es burocracia — es la diferencia entre poder demostrar que un documento fue aprobado conforme a un proceso reglado y depender de la memoria de las personas.
// Esquema de tabla de registro de aprobaciones (PostgreSQL)
CREATE TABLE aprobaciones_revision (
id SERIAL PRIMARY KEY,
publicacion VARCHAR(255) NOT NULL, -- 'catalogo-primavera-2026'
version INTEGER NOT NULL, -- número de versión del PDF
revisor_id VARCHAR(100) NOT NULL, -- identificador del revisor
revisor_name VARCHAR(255),
decision VARCHAR(20) NOT NULL -- 'aprobado' | 'correcciones' | 'rechazado'
CHECK (decision IN ('aprobado','correcciones','rechazado')),
timestamp TIMESTAMPTZ DEFAULT NOW(),
ip_address INET,
pdf_hash CHAR(64), -- SHA-256 del PDF aprobado
notas TEXT,
UNIQUE (publicacion, version, revisor_id)
);
-- Vista consolidada: estado actual de aprobación por publicación
CREATE VIEW estado_aprobacion AS
SELECT publicacion, version,
COUNT(*) FILTER (WHERE decision = 'aprobado') AS aprobados,
COUNT(*) FILTER (WHERE decision = 'correcciones') AS con_correcciones,
COUNT(*) FILTER (WHERE decision = 'rechazado') AS rechazados,
MAX(timestamp) AS ultima_actividad
FROM aprobaciones_revision
GROUP BY publicacion, version;Firma digital del PDF aprobado
Calcula el SHA-256 del PDF de prueba en el momento de la aprobación y guárdalo en la tabla. Si en el futuro alguien altera el archivo, el hash no coincidirá y podrás detectar la manipulación. Es la versión minimal de la firma digital, sin necesidad de certificados.
Historial inmutable
Nunca sobreescribas registros de aprobación — solo inserta. Si una versión es rechazada y luego aprobada, deben existir dos filas en la tabla: una con «rechazado» y otra con «aprobado». El historial completo de decisiones es más valioso que el estado final.
Exportación del PDF final de producción
Solo cuando todo está aprobado — y con bloqueo de seguridad
El PDF de producción —el que va a imprenta o se publica en web— debe generarse mediante un script separado que primero verifica que todos los revisores requeridos han aprobado la versión correspondiente. Si falta alguna aprobación, el script se detiene y alerta al responsable editorial. Esto impide que un operador con acceso al servidor exporte el PDF final saltándose el proceso de validación.
// Python — bloqueo de exportación hasta aprobación completa
def exportar_pdf_produccion(publicacion: str, version: int):
"""Solo exporta si TODOS los revisores requeridos han aprobado."""
revisores_requeridos = db.query(
"SELECT revisor_id FROM revisores_requeridos WHERE publicacion = %s",
(publicacion,)
)
aprobaciones = db.query(
"""SELECT revisor_id FROM aprobaciones_revision
WHERE publicacion = %s AND version = %s AND decision = 'aprobado'""",
(publicacion, version)
)
aprobados = {row['revisor_id'] for row in aprobaciones}
requeridos = {row['revisor_id'] for row in revisores_requeridos}
pendientes = requeridos - aprobados
if pendientes:
raise AprobacionIncompleta(
f"Faltan aprobaciones de: {', '.join(pendientes)}. "
"No se puede generar el PDF de producción."
)
# Todas las aprobaciones confirmadas — exportar con preset de producción
ids_client.run_script('exportar_produccion.jsx', {
'publicacion': publicacion,
'version': version,
'preset': 'Produccion_CMYK_300dpi'
})
# Registrar exportación
db.execute(
"INSERT INTO exportaciones_produccion VALUES (%s, %s, NOW())",
(publicacion, version)
)
enviar_notificacion_exportacion_completada(publicacion, version)Gestión de múltiples rondas de revisión
En la práctica, pocas publicaciones se aprueban en la primera ronda. Un flujo maduro debe gestionar múltiples iteraciones sin perder el control de qué se cambió en cada versión y quién lo solicitó.
v1 — Borrador inicial
InDesign Server genera el primer PDF con los datos actuales. Se envía a todos los revisores primarios. Plazo: 48h.
v2 — Primera corrección
Se recogen correcciones de revisores. Las automáticas se aplican inmediatamente; las manuales pasan al diseñador. IDS regenera el PDF. Solo reciben la v2 los revisores con correcciones pendientes.
v3 — Corrección de correcciones (si aplica)
En publicaciones complejas puede haber una tercera ronda, normalmente de ajuste fino. Si supera las 3 rondas, el sistema escala automáticamente al responsable editorial para intervención.
vN — Aprobación final
Todos los revisores han aprobado la misma versión. El sistema desbloquea la exportación del PDF de producción y envía confirmación a toda la cadena de aprobación.
Casos de uso reales: qué tipo de publicaciones lo necesitan
Catálogos de retail y distribución
Revisión de precios por categoría de producto, aprobación legal de comunicaciones de oferta, validación de imágenes de producto por el departamento de marca.
Documentos financieros regulados
Informes trimestrales y anuales con aprobación obligatoria del director financiero y revisión de cumplimiento normativo. La trazabilidad es requisito legal.
Publicaciones farmacéuticas y reguladas
Prospectos, fichas técnicas y material de marketing con revisión médica y aprobación regulatoria. Cada versión debe estar firmada y fechada por el responsable médico.
Publicaciones internas corporativas
Newsletters, guías de empleado, materiales de onboarding. Revisión de RRHH y comunicación interna antes de distribución a toda la plantilla.
Errores frecuentes al implementar el flujo
Usar el mismo PDF para prueba y producción
Es la trampa más común. Si el PDF de revisión y el de producción se generan con el mismo preset, es inevitable que antes o después alguien mande a imprenta un PDF con marca de agua de borrador. Usa siempre dos presets y que el de producción solo sea accesible via el script con bloqueo de aprobación.
No versionar las plantillas INDD junto a los PDFs
Si cambias la plantilla InDesign entre la ronda 1 y la ronda 2 de revisión, los cambios de layout pueden romper secciones aprobadas. Guarda siempre una copia de la plantilla con el mismo identificador de versión que el PDF generado.
Aceptar aprobaciones por email informal
Un «Ok, aprobado» en un hilo de WhatsApp no es una aprobación trazable. El sistema de registro debe ser la única fuente de verdad. Cualquier aprobación que no pase por él no existe a efectos del flujo — aunque tengas el screenshot.
Diferencia entre «aprobado con condiciones» y «aprobado»
Algunos revisores aprueban pero con comentarios menores que asumen serán incorporados. Considera añadir un estado intermedio «aprobado con cambios menores» en tu tabla: permite continuar el flujo pero registra que el revisor dejó notas que deben incorporarse antes de la exportación final.
Notificar el cierre del flujo a todos los participantes
Cuando el PDF de producción se exporta, envía un email de confirmación a todos los revisores con el número de versión final aprobado y la fecha. Esto cierra el ciclo formalmente y evita que revisores sigan enviando correcciones sobre un documento ya publicado.
Soluciones de revisión PDF: comparativa rápida
| Herramienta | Tipo | Trazabilidad | Integración IDS | Coste aprox. |
|---|---|---|---|---|
| Acrobat + email | Manual | ★★☆☆☆ | Ninguna (manual) | Gratis (Acrobat Reader) |
| Formulario web propio | Semi-auto | ★★★★☆ | Webhook custom | Desarrollo único ~1.500–4.000€ |
| GoProof (Enfocus) | Plataforma | ★★★★☆ | Plugin InDesign | Desde ~€80/mes |
| Ziflow | Plataforma | ★★★★★ | API REST | Desde ~€150/mes |
| Aproove | Enterprise | ★★★★★ | API REST + IDS nativo | Desde ~€300/mes |
El flujo de revisión es tan importante como la automatización
Es tentador centrarse en la magia de InDesign Server generando documentos automáticamente y dejar el proceso de revisión como «ya lo resolveremos luego». No hagas eso. Un PDF generado en 45 minutos que luego tarda 4 días en aprobarse por un proceso de revisión caótico no mejora nada — simplemente mueve el cuello de botella.
Implementa el flujo de revisión desde el primer día, aunque sea en su versión mínima (PDF por email + registro de aprobaciones en una hoja de cálculo). Después irás sofisticándolo. Lo que no puedes permitirte es no tener registro de quién aprobó qué — ni el día que todo funciona ni, sobre todo, el día que algo sale mal.
Consultar sobre implementación →Artículos relacionados

InCopy para equipos editoriales: edita textos de catálogos sin tocar el diseño
Guía práctica de Adobe InCopy para perfiles no técnicos: aprende a editar textos de catálogos, fichas de producto y folletos directamente en el flujo de maquetación sin necesitar InDesign ni conocimientos de diseño.
Informes financieros personalizados para 12.000 clientes: cómo lo resuelve InDesign Server
Caso práctico detallado: cómo una compañía financiera automatiza la generación de informes personalizados en PDF para miles de clientes en 4 idiomas antes del cierre trimestral. Arquitectura completa, scripts y resultados reales con InDesign Server.

InDesign Server + DAM: cómo actualizar miles de imágenes de producto en catálogos automáticamente
Caso práctico completo: cómo conectar Adobe InDesign Server con un sistema DAM para automatizar la actualización de imágenes de producto en publicaciones masivas. Arquitectura, webhooks, scripts ExtendScript y resultados reales con 4.800 SKUs y 340 documentos activos.