Flujos de revisión y aprobación con InDesign Server: PDFs de prueba automáticos y gestión de correcciones

LS

Laura Sanz

Especialista en Autoedición Editorial

28 de marzo de 2026 · 18 min de lectura

Compartir:
Flujo de revisión y aprobación de publicaciones con InDesign Server

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

1

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.

2

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
Ver PDF de prueba →Aprobar sin correcciones ✓

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.

3

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:

Nivel 1

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.

Cero fricción para el revisor — cualquiera sabe usar Acrobat.
Los comentarios siguen siendo texto libre; alguien tiene que interpretarlos.
Nivel 2

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.

Las correcciones son datos estructurados desde el primer momento.
Requiere desarrollar o contratar el formulario web.
Nivel 3

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.

Solución completa out-of-the-box con trazabilidad legal.
Coste de licencia adicional (desde ~€200/mes para equipos pequeños).

// 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')
4

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

Auto

Corrección de dato

Ej: Precio de REF-2847 pasa de 39,90€ a 34,90€

Automática — actualización en XML + relanzar IDS

Semi

Corrección de texto editorial

Ej: Cambiar «Disponible en tienda» por «Solo online»

Semiautomática — edición en tabla de textos + relanzar IDS

Manual

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

Manual

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.

5

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.

6

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.

Marketing, Legal, Responsable de Compras

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.

CFO, Compliance, Auditoría

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.

Medical Affairs, Regulatory, Marketing

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.

RRHH, Comunicación, Dirección

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

HerramientaTipoTrazabilidadIntegración IDSCoste aprox.
Acrobat + emailManual★★☆☆☆Ninguna (manual)Gratis (Acrobat Reader)
Formulario web propioSemi-auto★★★★☆Webhook customDesarrollo único ~1.500–4.000€
GoProof (Enfocus)Plataforma★★★★☆Plugin InDesignDesde ~€80/mes
ZiflowPlataforma★★★★★API RESTDesde ~€150/mes
AprooveEnterprise★★★★★API REST + IDS nativoDesde ~€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