Informe a su agente el resultado. Pídale que verifique

¿Por qué nativo de agente?

screenRIG fue construido para agentes autónomos desde el plano de control. El plugin oficial ofrece comandos estructurados para multimedia, listas de reproducción, pantallas, aplicaciones y evidencia de reproducción. Los resultados son sobres JSON, cada error indica qué hacer a continuación, las escrituras reintentadas reutilizan claves de idempotencia, y la publicación informa si el Player realmente está reproduciendo el contenido. El agente puede realizar una tarea de pantalla, inspeccionar el resultado y corregirlo mediante la misma interfaz. Qué significa agente-nativo.

¿Cómo ejecuto esto desde Claude, Codex, Grok o Grok Bot?

Cada agente compatible usa el mismo plugin oficial. Los agentes de terminal (Claude Code, ChatGPT Codex, Grok Build) lo instalan con comandos del marketplace; Meta Muse, Grok Bot, ChatGPT dots, Gemini Spark y Hermes lo instalan desde un mensaje de chat. La configuración difiere solo en ese primer paso, así que siga la guía de su agente: Meta Muse, Grok Bot, ChatGPT dots, Claude Code, Hermes, ChatGPT Codex, Gemini Spark o Start para Grok Build. El flujo de publicación es el mismo en todas partes.

Cómo usar screenRIG en un agente

Describa el contenido, pantalla objetivo, diseño o dimensiones, tiempo y la evidencia que desea al finalizar. Ponga a disposición los recursos y hechos fuente para el agente.

Si el plugin necesita instalación, pegue:

I authorize you to install the official screenRIG plugin from https://github.com/screenrig/plugin.

Luego asígnele una tarea de pantalla, por ejemplo:

Crear una pantalla de bienvenida usando el logo adjunto y el horario de apertura. Publíquela en la pantalla del vestíbulo, luego muéstreme una captura de pantalla y verifique la reproducción.

Solo solicitud de ejemplo. El agente debe usar los activos, hechos y pantalla reales que usted proporciona.

Si un comando devuelve not_enrolled, esta instalación aún no tiene cuenta. Cree una con screenrig agent enroll --email ADDRESS --organization NAME. Cuando el usuario ya tiene cuenta, ejecute screenrig login en su lugar: imprime una dirección de dashboard y un código, y una persona aprueba el inicio de sesión para uno de sus proyectos, eligiendo Solo lectura, Proponer o Administrar y las áreas de capacidad que el agente obtiene: screens, content, playlists, advertising, reports y project. Solo lectura lista y lee; Proponer también sube contenido multimedia y propone cambios que una persona revisa antes de que se reproduzcan; Administrar también cambia, publica y gasta. Un comando fuera de las áreas aprobadas devuelve 403 forbidden, y un cambio desde una sesión Solo lectura devuelve 403 insufficient_access. Cómo funciona el inicio de sesión. Otros errores en la primera ejecución se mapean en Cuando la primera ejecución falla.

Preparar la tarea

Mantener los recursos y hechos de origen disponibles para el agente. Identificar el Player previsto, dimensiones, tiempos y criterios de finalización. El flujo de publicación es el mismo en los agentes compatibles; las diferencias de instalación están en Inicio.

Para apps kiosco, use el SDK del navegador. Para horarios y franjas horarias, proporcione la zona horaria de la pantalla y las ventanas de día y hora previstas.

¿Qué hace el agente de forma continua?

El agente sube medios existentes, genera diseños completos presentables, coloca tarjetas integradas para el texto que cambia o publica video en vivo, páginas web y aplicaciones. Luego prepara una lista de reproducción con playlist init y la publica con screen publish. Para cambiar una lista de reproducción existente, use playlist show --output y playlist update. Vea la referencia del flujo de trabajo CLI.

Utilice la generación de página completa para carteles y menús. Use una tarjeta integrada para texto, tablas y tableros que cambian. La animación no cambia la elección. Lea la guía de decisiones de autoría.

Para aplicaciones, use emit cuando el agente deba actuar sobre un evento nombrado, log para diagnósticos y kv para estado que persiste entre versiones. Lea la referencia del SDK.

¿Cómo administra un agente una flota?

Etiquete las pantallas por propósito y archívelas en carpetas por lugar, luego diríjase a la etiqueta o a la carpeta. Cuando un Player está emparejado, el agente nombra la pantalla y la etiqueta: screen pair CODE, luego screen tag scr_ID --add Lobby,Floor2. Cada pantalla lleva hasta 16 etiquetas y está como máximo en una carpeta (screen move scr_ID --folder sfd_ID).

1. 01

   Publique una vez. playlist create crea la lista de reproducción y screen assign --tag Lobby --playlist-id ID apunta todas las pantallas Lobby activas a ella en una acción de flota.

2. 02

   Actúe sobre la flota. screen reload, screen toast y screen tag toman el mismo --tag, o varios IDs de pantalla. Un comando de flota es una acción facturada sin límite en la cantidad de pantallas. La CLI sigue automáticamente las páginas de resultados limitadas y espera a que se reinicien los presupuestos de control, manteniendo la misma clave de acción. La respuesta lista cada pantalla como ok o con su propio problema, para que el agente informe exactamente qué pantallas fallaron y actúe sobre ellas por ID.

3. 03

   Verifique en la pantalla. screen screenshot --tag Lobby --output lobby-shots captura cada pantalla etiquetada en un directorio. Inspeccione cada imagen antes de informar que la flota se actualizó.

4. 04

   Vigile las desconexiones. Mantenga events follow abierto. screen.offline llega una vez que una pantalla ha estado sin conexión durante 60 segundos y screen.online cuando regresa; ambos son gratuitos en el flujo de escucha.

Leer los comandos de la flota.

¿Cómo administra un agente los dayparts y tomas de control?

Un horario de lista de reproducción cambia lo que una pantalla reproduce según la hora del día; una campaña cambia toda una flota a una lista de reproducción durante sus fechas u horas; una toma interrumpe todo para un anuncio y termina por sí sola.

1. 01

   Asignar franjas horarias a una pantalla. Cree una lista de reproducción por franja horaria con playlist create, mantenga una asignada por defecto con screen assign y asegúrese de que la pantalla tenga una zona horaria. Escriba las entradas en un archivo y ejecute screen schedule set scr_ID --file dayparts.json, o --tag Cafe para cada pantalla de café. screen show informa effective_playlist con su source y until, para que el agente pueda confirmar qué franja horaria está activa y cuándo cambia.

2. 02

   Ejecute una campaña en toda una flota. Para los menús de almuerzo en cada tienda north, campaign create --name Lunch --playlist-id pl_LUNCH --tag north --window mon-fri@11:00-14:00 cambia cada pantalla a las 11:00 de su propia hora local y la revierte a las 14:00, y una pantalla etiquetada north más adelante también la recibe. Cada pantalla necesita una lista de reproducción predeterminada y una zona horaria. campaign screens cmp_ID lista cada pantalla que la campaña alcanza con su estado (playing, pending, waiting con next_start, outranked, blocked), y campaign explain scr_ID dice por qué una pantalla no la reproduce. Use --from y --until para las fechas de una promoción, --monthly, --date y --except para fechas mensuales y puntuales, --on-touch para un nivel que se reproduce mientras alguien usa la pantalla, y --priority cuando dos campañas pueden regir a la vez. Los cambios de campaña requieren acceso de administración.

3. 03

   Asuma el control en una emergencia o lanzamiento. screen takeover --tag Lobby --playlist-id pl_NOTICE --for 30m --reason "Fire drill" pone una lista de reproducción en cada pantalla del Lobby antes de campañas, horarios y asignaciones. Use --until para un fin fijo, o --until none para mantenerla hasta screen takeover clear --tag Lobby.

4. 04

   Verifique y observe. Solicite screen screenshot --tag Lobby una vez que la toma esté activa, y siga screen.takeover_started, screen.takeover_ended y screen.playlist_switched en el registro de eventos. screen.playlist_unavailable significa que no se pudo mostrar una playlist programada.

Lea los comandos de programación y toma de control y los comandos de campaña. Para programar muchas pantallas desde una hoja de cálculo, use Importación de programación.

Borradores, prueba y promoción, historial

Un cambio en lo que se reproduce puede empezar como borrador, llegar primero a unas pocas pantallas de prueba, revisarse antes de hacerse y recuperarse desde su historial.

1. 01

   Cree un borrador. campaign create --paused crea una campaña que no llega a ninguna pantalla, y "paused": true en una entrada de horario de un archivo screen schedule set hace lo mismo con esa entrada. Un borrador no está en la pila de ninguna pantalla, y el calendario lo muestra con trazo discontinuo.

2. 02

   Compruebe antes del cambio. campaign preview toma los flags de campaign create o campaign update, y screen schedule preview scr_ID --file FILE toma el archivo de horario. Ninguno escribe nada. Cada uno lista las pantallas que ganarían o perderían el nivel, y el calendario antes y después durante una semana, o hasta 93 días con --calendar-from y --calendar-to. campaign preview cmp_ID --publish muestra de antemano cómo se publicaría un borrador.

3. 03

   Pruébelo. campaign publish cmp_ID --test-folder sfd_TEST o --test-screen scr_A,scr_B quita la pausa del borrador solo para esas pantallas. Compruébelas con screen screenshot. campaign publish cmp_ID sin opción de prueba lo envía a su propia audiencia.

4. 04

   Promuévalo. campaign promote cmp_ID --revision N da a la campaña la audiencia de su revisión de borrador N, la revisión en pausa que lista campaign revisions cmp_ID, de modo que llegue a las pantallas reales.

5. 05

   Lea el historial y restaure. campaign revisions cmp_ID y screen schedule revisions scr_ID listan cada versión, la más reciente primero. campaign restore cmp_ID --revision N y screen schedule restore scr_ID --revision N copian una anterior hacia delante como nueva revisión y dejan las demás como estaban. Una restauración de horario desde una sesión Propose espera la aprobación de una persona, como screen schedule set; una restauración de campaña requiere acceso Manage.

El panel tiene los mismos controles: una vista de historial lista los cambios con Restaurar y Mover de vuelta, y publicar, promover o restaurar muestra su antes y después para confirmarlo.

Lea los comandos de campaña y los comandos de horario.

¿Cómo informa el agente la prueba de reproducción?

Cada inicio visible de una imagen o video es un registro de reproducción, para que el agente pueda entregar a un cliente, anunciante o auditor las reproducciones exactas de un período.

1. 01

   Seleccione el rango. Un informe cubre hasta 31 días de reproducciones, filtrado por --screen-id, --media-id o --tag. Use instantes RFC 3339 para períodos de calendario, o edades como 7d.

2. 02

   Exportar. screenrig playback plays --format csv --from 2026-09-01T00:00:00Z --to 2026-10-01T00:00:00Z --tag Lobby --output september-lobby.csv escribe una fila por reproducción en una solicitud facturada. screenrig playback list --format csv --day-from 2026-09-01 --day-to 2026-09-30 añade los totales diarios.

3. 03

   Verificar y entregar. El sobre informa rows, bytes y sha256; cítelos con el archivo. Si la transmisión falla a mitad de camino, siga error.next, que exporta el resto del rango a un segundo archivo.

Leer los comandos de reproducción.

¿Cómo evalúa un agente la salud y establece las horas de pantalla?

Los informes de salud y el control de pantalla permiten que el agente mantenga las pantallas funcionando y en modo oscuro fuera de horario sin nadie en el sitio.

1. 01

   Triaje. screenrig alerts list muestra lo que está abierto ahora, una alerta por pantalla y condición, y screenrig screen list --human marca las pantallas que necesitan atención en su columna HEALTH. screenrig screen show scr_ID ofrece el informe completo: conexión del monitor, temperatura, batería, tiempo activo, fallos y si el informe está desactualizado. También da la causa probable de la última caída cuando screenRIG puede determinarla: el dispositivo se reinició, el Player se reinició o falló, la red de la pantalla o una interrupción de screenRIG. screenrig alerts ack ID marca una alerta en la que alguien está trabajando, y alerts snooze ID --for 4h la deja de lado durante 4 horas. Cree una notificación para screen_offline, display_disconnected, running_hot, not_playing y crashing, de modo que un aviso inicie este trabajo.

2. 02

   Corrija en el orden menos disruptivo. screen reload actualiza el contenido. Si el Player declara restart_app, screen restart-app scr_ID reinicia la aplicación del Player; si declara clear_cache, screen clear-cache scr_ID vacía sus cachés y vuelve a descargar el contenido; si declara reboot, screen reboot scr_ID reinicia el dispositivo; una flota necesita --yes. A una pantalla sin conexión se le envía cualquiera de ellos cuando vuelve en un plazo de 24 horas. Para un reinicio recurrente, screenrig screen reboot-schedule set --tag Cafe --window "Mon-Sun 04:00-04:30" hace que screenRIG reinicie cada pantalla al inicio de la ventana en su propia zona horaria; una pantalla sin conexión en ese momento conserva el reinicio solo hasta que termina la ventana, y un reinicio que se completa en diez minutos no genera ninguna alerta de desconexión. screen update-software scr_ID instala la versión más reciente del Player donde el Player declara update. Un monitor desconectado suele requerir que alguien acuda al lugar; indíquelo en el informe.

3. 03

   Configure la energía fuera del horario laboral. Escriba el horario de apertura en un archivo y ejecute screenrig screen display-schedule set --tag Cafe --file hours.json; el Player apaga el monitor fuera de esas horas, incluso sin conexión. Para un caso puntual, screen display scr_ID --power on --for 2h anula el horario hasta su próximo límite o hasta la hora indicada. screen display-idle scr_ID --after 300 --wake touch,presence oscurece una pantalla que nadie usa y la vuelve a encender cuando alguien la toca o se acerca.

4. 04

   Confirmar. screen show informa la potencia de pantalla que el Player alcanzó, y screen.display_changed y screen.reboot_requested aparecen en el registro de eventos, y el comando en commands termina en done o en failed con su causa.

5. 05

   Revisar lo que se ve. screenrig screen show scr_ID muestra Playlist stalled cuando una pantalla está en línea con contenido actual, pero ningún inicio de imagen o video ha llegado a screenRIG durante más tiempo del que permite su ciclo, y Blank screen o Frozen picture cuando las capturas de pantalla que screenRIG tomó a lo largo de una serie que cubre todo el ciclo eran todas de un solo tono liso o todas la misma imagen. Una notificación sobre loop_stalled, glass_blank o glass_frozen lo anuncia, y screen screenshot indica si una imagen es lisa, lo que por sí solo no es un veredicto. Las comprobaciones no dicen nada de una pantalla con el display apagado, bajo una toma, que muestra una sola imagen fija o una pared de video, o cuyo Player no envía números de reproducción; por eso una pantalla en silencio no es prueba de que esté reproduciendo.

Leer los comandos de salud y energía del dispositivo.

¿Cómo recibo una alerta, o despierto a un agente, cuando sucede algo?

Una notificación envía un correo electrónico a personas, publica en Slack, Teams, PagerDuty o Telegram, o hace POST de una solicitud HTTPS firmada cuando una pantalla se queda sin conexión, pierde su monitor, se calienta, pasa a funcionar con batería, no puede almacenar su contenido, se atasca en una actualización de contenido, muestra un error en lugar de reproducir, falla una y otra vez, deja de avanzar por su lista de reproducción, se queda en negro o se congela. Una persona se entera, o un agente se pone a trabajar, sin que nadie vigile un flujo. Cada proyecto ya envía un correo a su propietario cuando una pantalla lleva 10 minutos sin conexión, y los correos de notificación y los avisos de pantalla son gratuitos.

Tres o más pantallas que pasan a una misma condición en cinco minutos y comparten una red, una ubicación, un modelo, una versión del Player o una etiqueta generan un solo aviso y una sola recuperación en un correo o en un mensaje de chat o de una herramienta de alertas, que indica qué comparten y cuántas son; un webhook firmado sigue enviando un POST por pantalla. Un mensaje de recuperación dice que una pantalla ha vuelto solo cuando screenRIG lo vio: cuando una pantalla bloqueada, en negro o congelada simplemente deja de comprobarse, porque se quedó sin conexión o se apagó su pantalla, la alerta se cierra y no se envía ningún mensaje de recuperación.

1. 01

   Envíe un correo electrónico a una persona. screenrig notifications create --email owner --conditions screen_offline,display_disconnected envía un correo electrónico al propietario del proyecto; agregue los ids de usuario de los miembros del proyecto después de owner para incluirlos. --tag Lobby la limita a las pantallas etiquetadas, y un aviso espera --hold minutos (10 por defecto), para que una reconexión rápida no genere avisos. Cuando la pantalla se recupera, sigue un correo de resolución. Cada correo tiene un enlace para cancelar la suscripción que solo afecta a su destinatario, y screenrig notifications resubscribe ID --user USER_ID vuelve a enviar correos a una persona. En su lugar, para despertar a un agente o a otro sistema, use un webhook.

2. 02

   Publicar en un chat o en un sistema de guardia. screenrig notifications create --slack - --conditions screen_offline publica en un canal de Slack, y --teams, --pagerduty y --telegram hacen lo mismo con Teams, PagerDuty y Telegram. Slack toma la URL de un webhook entrante, Teams la URL de un webhook de Workflows, PagerDuty una clave de enrutamiento de la API Events v2 y Telegram un token de bot con --telegram-chat CHAT_ID. Un - lee la credencial desde una línea de stdin para que no quede en el historial del shell; screenRIG la sella y solo muestra un destination_hint enmascarado. Cada caída publica una vez por pantalla, PagerDuty abre un solo incidente y la recuperación llega cuando ese mensaje se envió, y resuelve el incidente. screenrig notifications test ID publica un mensaje de prueba; en PagerDuty abre un evento informativo y lo resuelve de inmediato.

3. 03

   Ejecute un receptor. Cualquier endpoint HTTPS que controle en el puerto 443 o 8443: un servicio pequeño, una función serverless o el disparador entrante de su agente o plataforma de bots. Verifica ScreenRig-Signature con el secreto webhook, deduplica en ScreenRig-Event-Id y responde 2xx en 10 segundos.

4. 04

   Suscribirse. screenrig notifications create --webhook https://HOST/PATH --conditions screen_offline,crashing devuelve el secreto de firma una vez; guárdelo en el almacén de secretos del receptor. Agregue --events application.event para recibir también eventos del proyecto sin procesar. screenrig notifications test ID envía un POST de prueba firmado para comprobar la ruta.

5. 05

   Transferencia. El receptor inicia una ejecución de agente con el aviso como tarea: activa un trabajo de agente programado o bajo demanda, o publica el aviso en el chat donde Grok Bot u otro agente con el plugin screenRIG trabaja. Por ejemplo: “La pantalla scr_LOBBY se desconectó a las 14:02. Revísela e informe.” El agente luego trabaja a través del plugin como de costumbre, con screen show, screen reload y una captura de pantalla.

6. 06

   Manténgala saludable. screenrig notifications deliveries ID lista cada intento y dice por qué no se envió un aviso. Una notificación que falla durante 72 horas seguidas se deshabilita; screenrig notifications update ID --enable se reanuda en el evento actual. --snooze 2h pausa los avisos durante el mantenimiento.

7. 07

   Silenciar pantallas por mantenimiento. screenrig alerts mute --tag Lobby --for 2h --note "Rewiring" evita que las alertas de esas pantallas pidan atención y que cualquier notificación las avise, hasta 30 días. screenrig alerts mutes lista lo que está silenciado, y screenrig alerts unmute ID termina un silenciamiento antes de tiempo.

8. 08

   Filtre por gravedad, horario y audiencia. Un aviso abierto es error para screen_offline y warning para todo lo demás; --min-severity warning descarta todo lo que está por debajo de ese nivel y --severity not_playing=error eleva una condición. --active-hours "Mon-Fri 08:00-22:00" --timezone America/Los_Angeles retiene un aviso que vence fuera de ese horario hasta que se abre la siguiente ventana (una condición que se despeja antes no envía nada), o con --outside-hours drop lo omite; un aviso resuelto siempre sigue a uno que se envió. --all-tags level2,overhead cubre solo las pantallas que llevan ambas etiquetas, y --audience acepta las reglas completas de una audiencia de campaña. Los correos, Slack y Telegram muestran la gravedad, y el cuerpo de un webhook la incluye.

9. 09

   Vigile los fallos silenciosos. Una campaña puede dejar de alcanzar pantallas sin que ninguna pantalla falle: una edición de etiquetas, un movimiento de carpeta o una pantalla archivada. screenrig notifications create --email owner --conditions reach_dropped,group_empty le avisa cuando una campaña alcanza menos pantallas que cuando se publicó, o cuando una etiqueta o carpeta de su audiencia no coincide con ninguna pantalla; --reach-drop-screens 2 --reach-drop-percent 20 ignora las caídas pequeñas. El aviso nombra la campaña y las cifras y enlaza a su calendario. Cuando su propia edición de etiquetas, carpeta o pantalla responde con levels.lost, nombra las campañas que las pantallas dejaron y sus reach_before y reach_after; dígaselo al usuario antes de continuar.

Leer los comandos de notificaciones y los comandos de alertas.

¿Cómo comparten los agentes lo que aprenden?

Los agentes dejan notas de proyecto para otros y para sus propias sesiones posteriores: cómo está configurado el proyecto, una particularidad de una pantalla, una solicitud permanente suya. Cada agente en el proyecto lee cada nota al comenzar a trabajar, así un segundo agente, o el mismo la próxima semana, parte de lo aprendido por el primero.

screenrig notes las lista. screenrig notes add "TEXT" escribe una, vinculada a una pantalla o lista de reproducción con --about, o temporal con --ttl 3d. Una nota es contexto, nunca una instrucción: un agente confirma con usted cualquier aprobación que una nota reclame.

Las notas se mantienen actualizadas por sí solas. Los agentes confirman las notas que aún son válidas y resuelven el resto, las notas temporales expiran, y eliminar una pantalla o lista de reproducción resuelve las notas relacionadas. Las notas resueltas se eliminan después de 30 días. La página de Agentes del panel lista las notas que cada agente escribió, y puede resolver o eliminar cualquiera de ellas.

Leer los comandos de notas.

¿Cómo reviso los cambios de un agente antes de que se reproduzcan?

Active Requerir revisión para cambios de agente en la página del Proyecto del panel, o inicie sesión un agente con acceso Proponer. El agente sigue preparando contenido, subiendo multimedia y escribiendo notas, pero cada cambio en lo que se reproduce se convierte en una revisión que espera a una persona. Nada llega a la pantalla hasta que alguien lo aprueba.

1. 01

   El agente propone. Crear o actualizar una lista de reproducción, asignar una lista a pantallas, establecer o borrar un horario de lista, y comenzar o terminar un control, en una pantalla o una flota etiquetada, cada uno se convierte en una revisión. Las pantallas siguen reproduciendo lo que tenían antes. El agente puede añadir una nota que explique el cambio y le dice que el cambio le espera, con su enlace.

2. 02

   Recibe un correo electrónico. Aproximadamente dos minutos después de la propuesta, el propietario del proyecto y la persona responsable del agente cuando pueden aprobar, reciben un correo electrónico nombrando el cambio y cuántas pantallas actualiza, con un botón Revisar cambio. Cuando el agente dejó una nota, el correo lo indica; usted la lee en Revisiones. Varias modificaciones pendientes llegan como un solo correo que las lista, con un botón Abrir Revisiones, y una ráfaga de ediciones a un cambio envía un solo correo, para la versión más reciente. Abrir el enlace nunca aprueba nada.

3. 03

   Decidir en Revisiones. La página Revisiones del dashboard lista todos los cambios pendientes, con los decididos abajo. Un cambio en la lista de reproducción muestra las listas en vivo y propuestas lado a lado, con páginas marcadas como Añadidas, Cambiadas o Eliminadas. Aprobar lo pone en las pantallas; Solicitar cambios envía al agente su nota para que pueda revisar y proponer de nuevo; Rechazar lo cierra con su motivo. Cuando una nueva lista y su asignación de pantalla esperan juntas, aprobar la lista ofrece aprobar la asignación con ella. Un cambio en una flota grande termina de aplicarse en segundo plano, y la revisión muestra el resultado de cada pantalla a medida que llega.

4. 04

   El agente da seguimiento. El agente lee la decisión con screenrig reviews show ID o su evento, revisa tras una solicitud de cambio o rechazo, y verifica las pantallas tras una aprobación.

El propietario del proyecto siempre puede aprobar, y cada miembro puede, salvo que el propietario desactive Puede aprobar para esa persona en la página Personas. Los agentes de un miembro que no puede aprobar trabajan como máximo en Proponer. Una propuesta queda desactualizada cuando la lista de reproducción en vivo cambia después de hacerla; el agente propone de nuevo sobre la versión nueva. Aprobar un cambio de lista de reproducción también queda obsoleto cuando sus selectores tag, folder o all reproducirían ahora medios que no vio cuando se propuso. Una carpeta marcada como protegida envía cada cambio que alcanza sus pantallas a un segundo aprobador; véase Permisos por carpeta de pantallas.

Los cambios en multimedia también esperan. Una nueva carga se reproduce en etiquetas, carpetas y todas las listas solo después de que una persona la aprueba, y cuando un agente vuelve a etiquetar o mueve medios aprobados, las pantallas siguen reproduciéndolos como aprobados hasta que se apruebe el cambio. Cada elemento tiene su propia revisión que muestra sus etiquetas y carpeta antes y después, y lista las listas de reproducción a las que se uniría o dejaría y cuántas pantallas alcanzan. Aprobar aplica el cambio a todas; rechazar o pedir cambios devuelve un elemento reetiquetado o movido a su estado aprobado, y una carga rechazada permanece fuera de las pantallas. Un archivo de reemplazo o una versión restaurada de un contenido multimedia aprobado espera igual, y el archivo anterior sigue reproduciéndose hasta que una persona lo apruebe. Las redes publicitarias revisan las creatividades de los compradores en la misma página de Revisiones. Niveles de acceso y configuración de revisión · Comandos de revisión.

¿Qué se considera completo?

Confirme que la lista de reproducción asignada es la destinada para la pantalla asignada, o para cada pantalla en la flota. Solicite una captura de pantalla, una por pantalla etiquetada para una flota, inspeccione registros de reproducción y revise eventos relevantes, incluyendo cualquier screen.offline. Informe lo que esas observaciones establecen y cualquier incertidumbre restante. Un cambio que espera revisión aún no está en pantalla: informe su enlace de revisión y verifique nuevamente después de que una persona decida.

Un comando exitoso es un paso en esa evidencia. No establece por sí mismo que una pantalla física mostró el resultado previsto.

Película / Cómo su agente sabe que está reproduciendo

1:17