Qué construí y por qué
Construí Privacy Operations: una app para administradores que permite buscar registros, organizar listas, exportar información, redactar contenido y eliminar tickets seleccionados. La desarrollé con Zendesk App Builder, las APIs de Zendesk y Custom Objects, sin desplegar un backend externo.
Quería conseguir dos cosas: ofrecer una base de uso libre que otros administradores y empresas puedan adaptar sin pagar una suscripción adicional por una app de terceros, y comprobar el alcance real de App Builder con un caso que incluyera lectura, almacenamiento, exportación y operaciones sobre tickets.
Qué problema resuelve
La app reúne varias tareas que un administrador puede necesitar cuando revisa la información almacenada en su instancia:
- Encontrar tickets, usuarios u organizaciones mediante filtros o IDs.
- Guardar selecciones de IDs y combinar listas.
- Exportar registros y comentarios a JSON o CSV.
- Crear un índice de adjuntos con sus enlaces.
- Redactar un texto exacto o adjuntos seleccionados dentro de comentarios.
- Eliminar tickets mediante el proceso nativo de Zendesk.
Un ejemplo: un administrador identifica un grupo de tickets, revisa la selección y exporta la información que necesita conservar. Después puede redactar un dato concreto o eliminar tickets descartables, siempre mediante un preview y una confirmación explícita.
La app no decide qué información debe conservar una empresa, qué datos corresponde borrar ni cuál es su política de retención. Esas decisiones pertenecen a la organización.
La arquitectura: qué permanece dentro de Zendesk
La interfaz se ejecuta como una app de navegación lateral, en la ubicación nav_bar. Usa React, componentes de Zendesk Garden y Zendesk Apps Framework (ZAF) para trabajar con la sesión del administrador.
Las APIs consultan y modifican los recursos autorizados. Los Custom Objects almacenan listas, presets y parte de la infraestructura de procesos. Los previews, exportaciones y resultados de las operaciones principales permanecen en la memoria del navegador.
Desliza horizontalmente para ver el diagrama completo.
Ten en cuenta: almacenar un proceso no equivale a ejecutarlo en segundo plano. Los Custom Objects no son un scheduler y la memoria del navegador no es una cola persistente.
En este MVP, Export, Redaction y Delete tickets no guardan sus ejecuciones en los objetos de jobs y checkpoints. Si recargas, pierdes el estado de esas sesiones. Un trabajo nativo de eliminación que ya fue enviado a Zendesk puede continuar aunque cierres la app.
Qué hace cada pestaña
| Pestaña | Para qué sirve |
|---|---|
| Overview | Presenta el objetivo de la app y los accesos a sus flujos principales. Resume las condiciones que conviene conocer antes de empezar. |
| Discovery | Busca tickets, usuarios u organizaciones con filtros, consultas e IDs; también admite entrada de IDs por CSV. Permite revisar y seleccionar resultados para las operaciones siguientes. |
| Export | Genera JSON o tablas CSV con los registros y las opciones elegidas. Los adjuntos se incluyen como índice y enlaces, no como archivos incorporados. |
| Redaction | Busca un texto exacto o muestra los adjuntos de comentarios para seleccionar qué redactar. Permite revisar el alcance antes de confirmar una operación irreversible. |
| Delete tickets | Prepara y ejecuta la eliminación inicial de tickets seleccionados por lotes. Muestra el estado de los trabajos nativos y los resultados por ticket cuando pueden determinarse. |
| Saved Lists | Guarda conjuntos de IDs para volver a utilizarlos. Las listas permanecen en Custom Objects; un ID puede seguir siendo información vinculable a una persona. |
| Combine Lists | Calcula unión, intersección o diferencia entre listas compatibles. Permite conservar el resultado como una nueva lista de IDs. |
| Presets | Guarda opciones reutilizables para preparar una selección. Un preset no ejecuta por sí mismo una exportación, redacción o eliminación. |
| Process Preparation | Prepara una selección a partir de una lista y un preset, aplicando exclusiones. Es un paso de preparación: no ejecuta las acciones de las otras pestañas. |
| Processes | Muestra jobs y checkpoints almacenados por la infraestructura de procesos y los diagnósticos. En este MVP no representa un historial persistente de todas las exportaciones, redacciones o eliminaciones. |
| Settings | Comprueba y configura los objetos propios de la app, ejecuta diagnósticos y permite limpiar su historial terminado. Incluye los detalles de acceso, almacenamiento y ejecución. |
| Help | Reúne la guía de uso, límites, pruebas y notas para desarrollo. Permite copiar o descargar la documentación en Markdown. |
Cómo la construí: una app, varias fases y pruebas entre versiones
No intenté generar toda la app en una sola respuesta. Separé la construcción en etapas y mantuve la misma conversación de App Builder para continuar sobre la versión existente.
El patrón fue:
Hubo iteraciones que necesitaban corrección: funcionalidades descritas como terminadas que no estaban verificadas, filtros clasificados incorrectamente y cambios simultáneos sobre un mismo archivo que sobrescribieron otros cambios. La solución fue pedir lecturas del estado real, aplicar los cambios dependientes de forma secuencial y exigir evidencia antes de dar una etapa por validada.
Los bloques siguientes traducen y consolidan los prompts principales y las correcciones que utilizamos. Están adaptados al alcance final del MVP y eliminan datos de la instancia. No son una transcripción literal de cada mensaje ni garantizan una regeneración idéntica: App Builder puede producir código, nombres de componentes y versiones diferentes.
Copia un bloque por vez. Cada fase debe detenerse para que puedas revisar su resultado.
Fase 1. Base, acceso y configuración
Primero construimos la estructura y los objetos propios de la app. En esta etapa las escrituras debían limitarse a esos objetos, sin alterar tickets, usuarios u organizaciones.
Ver prompt 1: estructura y base de la app
Crea una app de Zendesk llamada “Privacy Operations”, ubicada en Side Navigation (nav_bar), para administradores. Utiliza React, Zendesk Garden, ZAF y APIs documentadas de Zendesk. Trabaja con la sesión autenticada del administrador, sin pedir tokens. No utilices backend externo, servicios de pago adicionales, bases de datos externas, telemetría ni procesamiento externo de información. Esta es la fase 1. Implementa solo la base. ACCESO Comprueba el usuario mediante ZAF y GET /api/v2/users/me.json. Exige rol admin e identidad coincidente. Ante errores, bloquea el acceso. Revalida antes de las escrituras y acciones de ejecución. Explica cómo restringir la app a administradores en la configuración de instalación. No confundas visibilidad de la app con permisos sobre registros. CUSTOM OBJECTS Usa las APIs actuales de Custom Objects. Comprueba cuotas y esquemas antes de crear nada. Define estos objetos versionados: - privacy_ops_definitions: listas y presets. - privacy_ops_jobs: estado de jobs, propietario de ejecución y heartbeat. - privacy_ops_items: elementos de cada job, etapas y checkpoints. Campos iniciales: - Definitions: kind (texto), schema_version (entero), definition_json (texto multilínea). - Jobs: operation, status, actor_id, executor_token, heartbeat_at, started_at y finished_at (texto); schema_version (entero); config_json y counters_json (texto multilínea). - Items: job_id, resource_type, resource_id, stage, status y submitted_job_id (texto); attempts (entero); result_json (texto multilínea). Verifica tipos y propiedades con la documentación vigente. Usa nombres e identificadores externos estables. Mantén cada registro por debajo de 24 KB y respeta también los límites de sus campos. Divide estados grandes en registros acotados. Crea un setup explícito e idempotente. No modifiques objetos ajenos. Si un campo existente tiene un tipo incompatible, informa el problema y detente. Revisa los permisos configurables, el acceso anónimo y la unicidad de identificadores. No declares acceso exclusivo de administradores sin comprobar los permisos efectivos. Si un rol tiene permisos predefinidos no modificables, informa la limitación. ALMACENAMIENTO Guarda solo lo necesario: IDs, opciones, marcas de tiempo, contadores, checkpoints y errores depurados. No guardes comentarios originales, archivos exportados, URLs de adjuntos, tokens ni términos sensibles de búsqueda. INFRAESTRUCTURA Crea un adaptador compartido para llamadas API, paginación, Retry-After y errores. Al inicio, permite escribir únicamente en los tres objetos propios. Implementa estados de job: draft, preparing, ready, running, paused, interrupted, awaiting_review, completed, completed_with_errors y cancelled. Un heartbeat es una comprobación de mejor esfuerzo, no un bloqueo atómico. No reanudes automáticamente jobs antiguos ni reintentes escrituras de resultado incierto. PANTALLAS Crea Overview, Saved Lists, Presets, Processes y Settings. Implementa listas de IDs y presets con lectura, creación, edición y eliminación en los objetos propios. Incluye checks de solo lectura y un diagnóstico con registros sintéticos descartables. Limpia solo los registros creados por ese diagnóstico. Compila e informa qué implementaste, qué probaste realmente y qué permanece pendiente. No alteres datos de clientes. Detente antes de la fase 2.
El primer aprendizaje fue de acceso: una comprobación de administrador en la interfaz no demuestra que otros roles carezcan de acceso directo a los Custom Objects. Esa evaluación requiere pruebas con identidades reales y permisos de la cuenta.
Fase 2. Búsquedas, listas y preparación
Después incorporamos Discovery y la preparación de selecciones. El objetivo era evitar operaciones sobre un conjunto que cambiara silenciosamente entre la búsqueda y la ejecución.
Ver prompt 2: búsqueda completa, listas y previews
Continúa sobre Privacy Operations y conserva la fase anterior. Implementa solo Discovery, combinación de listas y preparación de selecciones. DISCOVERY Admite tickets, usuarios y organizaciones mediante: - IDs introducidos manualmente. - CSV de IDs con tipo de recurso elegido. - Búsquedas nativas con filtros documentados. Deduplica IDs y distingue entradas inválidas, inaccesibles, no encontradas y de tipo incorrecto cuando la información permita determinarlo. Un ID numérico aislado no identifica por sí solo el tipo de recurso. Carga los metadatos reales de los campos. Presenta filtros apropiados para cada recurso y muestra la consulta generada. Usa Export Search Results con paginación por cursor para enumerar resultados: GET /api/v2/search/export Envía filter[type] como parámetro separado, usando ticket, user u organization. No añadas type: dentro de la consulta de ese endpoint. Sigue las páginas hasta el final. Muestra progreso, IDs únicos, duplicados, páginas, fecha y estado de completitud. Distingue resultados completos, parciales, interrumpidos y fallidos. Configura un límite interno de Discovery de 20.000 IDs, informándolo y marcando el resultado como parcial si se alcanza antes del final. Para entrada de IDs usa un máximo de 3.000. No presentes el límite de la búsqueda estándar de 1.000 resultados como un conjunto completo. No declares que una simulación evalúa consultas reales si devuelve resultados fijos. LISTAS Mantén compatibilidad con las listas existentes y guarda IDs y metadatos mínimos de origen, sin texto de consulta ni contenido de registros. Implementa unión, intersección y diferencia A menos B entre listas completas del mismo tipo. Bloquea listas incompletas, incompatibles o con fragmentos faltantes. Diseña listas para hasta 3.000 IDs y respeta los límites de tamaño de almacenamiento. PREPARACIÓN Permite elegir lista y preset, aplicar exclusiones por ID o etiquetas y revisar conteos reconciliados y los IDs seleccionados. La preparación no ejecuta exportaciones ni acciones sobre tickets. Mantén la selección fija en memoria e invalídala si cambian la fuente, las opciones o las exclusiones. Conserva bloqueada la persistencia de selecciones congeladas de objetivos reales mientras esté pendiente la evaluación de acceso. No afirmes que ese bloqueo se aplica automáticamente a Saved Lists: verifica y explica cada ruta por separado. PRUEBAS Comprueba las operaciones de conjuntos con datos sintéticos superpuestos. Añade una prueba de paginación que cree siete registros descartables, los recupere en varias páginas y los elimine. Ofrece una prueba explícita de recarga y recuperación, sin confundir un recorrido ininterrumpido con una recuperación real. No habilites exportación ni escrituras sobre tickets, usuarios u organizaciones. Compila, presenta evidencia real, simulada y pendiente, y detente.
Un ajuste importante consistió en separar «no está implementado» de «Zendesk no lo permite». En la primera tabla de metadatos, campos que sí tenían sintaxis documentada aparecían como no soportados.
Ver ajuste: clasificación de campos y consultas
Corrige de forma puntual los metadatos y filtros de Discovery. Conserva la paginación y las operaciones de conjuntos que ya funcionan. Distingue campos nativos, personalizados, especiales standard:: y no clasificados usando las propiedades documentadas. No clasifiques todos los IDs numéricos como campos personalizados. Consulta las referencias oficiales: https://support.zendesk.com/hc/en-us/articles/4408882086298-Search-reference-for-tickets https://developer.zendesk.com/api-reference/ticketing/ticket-management/search/ Implementa priority, group, tags y búsquedas aplicables de campos personalizados. Usa valores y etiquetas reales. Respeta las diferencias entre tipos y operadores; no generes una sintaxis universal para todos. Mantén filter[type] fuera de la consulta de exportación. Muestra estados correctos: soportado, no soportado con motivo documentado o todavía no implementado. No conviertas una función pendiente en una supuesta limitación de Zendesk. Inspecciona los handlers de guardado: documenta exactamente qué rutas escriben listas y cuáles bloquean selecciones congeladas. Aplica cambios dependientes de un mismo archivo de forma secuencial. Lee el contenido final, comprueba que los componentes estén conectados en App.jsx, compila e informa lo que no hayas probado.
Fase 3. Exportación con un alcance explícito
La exportación debía hacer algo sencillo y comprobable: leer los objetivos elegidos, aplicar las opciones y producir archivos descargables.
Decidimos mantener los adjuntos como índice y enlaces. No es un ZIP ni una copia de los archivos. La limitación de binarios de client.request fue una razón para acotar ese flujo sin añadir servicios externos.
Ver prompt 3: exportación JSON y CSV
Continúa Privacy Operations con un flujo de exportación MVP. Conserva lo existente y añade una pestaña Export conectada a App.jsx. FUENTES Admite una lista guardada completa, resultados seleccionados de Discovery o todos los resultados de una búsqueda completa. Rechaza fuentes parciales. Muestra el tipo y la cantidad exacta antes de comenzar. OPCIONES Incluye casillas independientes, desactivadas inicialmente: - Comentarios del ticket. - Notas internas. - Perfiles relacionados de solicitante y organización. - Índice y enlaces de adjuntos. Cuando las notas internas estén desactivadas, tanto los comentarios exportados como el índice de adjuntos deben limitarse a comentarios públicos. Para usuarios y organizaciones, exporta los perfiles seleccionados. No amplíes automáticamente a sus tickets relacionados. ARCHIVOS Genera JSON y tablas CSV de registros, comentarios, perfiles relacionados, adjuntos y errores, según corresponda. Conserva IDs de relación, autoría, fecha, orden y visibilidad. Usa UTF-8, escape CSV y protección frente a fórmulas de hojas de cálculo. Serializa los campos personalizados sin perder sus claves o IDs. ADJUNTOS La opción debe llamarse “Attachment index and download links”. Exporta ticket ID, comment ID, attachment ID, nombre, tipo MIME, tamaño, indicador inline y content_url. Obtén imágenes inline mediante la opción documentada al listar comentarios. Ofrece enlaces individuales mediante el flujo normal de Zendesk. Explica que los archivos no están incorporados, pueden requerir autenticación y sus enlaces pueden dejar de funcionar tras una redacción o eliminación. No implementes ZIP, descarga binaria con client.request, proxies externos ni extracción de URLs desde el texto. EJECUCIÓN Pagina todos los comentarios y procesa solicitudes con concurrencia limitada. Respeta Retry-After. Muestra progreso, éxitos y fallos. Cancelar detiene nuevas solicitudes. Conserva los datos recuperados si otro registro falla y genera un manifiesto de errores. Marca una cancelación o recuperación parcial como incompleta. Divide la salida en partes de hasta 200 objetivos y maneja los errores de memoria sin truncamiento silencioso. Ese límite no garantiza un tamaño máximo en bytes. Mantén archivos, contenido y URLs solo en memoria. No uses Custom Objects ni almacenamiento del navegador para esos payloads. No dependas de la persistencia de selecciones congeladas. Recargar interrumpe la exportación y requiere reiniciarla. No prometas reanudación persistente. PRUEBAS Prepara casos sintéticos con más de una página de comentarios, una nota interna y adjuntos. Comprueba exportaciones pequeñas, opciones, errores y cancelación cuando el entorno lo permita. Etiqueta resultados simulados y reales por separado. No habilites modificaciones de tickets, usuarios u organizaciones. Compila, reporta las limitaciones y detente.
Fase 4. Redacción de texto y adjuntos
Aquí pasamos de consultar información a modificar contenido. Por eso añadimos previews, confirmaciones y una autorización limitada a los comentarios elegidos.
Ver prompt 4: redacción nativa con confirmación
Continúa Privacy Operations con una pestaña Redaction conectada a App.jsx.
ALCANCE MVP
Permite introducir un ticket ID o usar tickets seleccionados de un Discovery completo. Limita cada preview a 50 tickets y el texto buscado a 500 caracteres.
Ofrece dos acciones independientes:
1. Redactar un texto exacto indicado por el administrador.
2. Redactar adjuntos seleccionados explícitamente.
No implementes detección automática de datos personales, anonimización de perfiles, borrado de tickets ni ejecución programada.
PREVIEW
Carga todas las páginas de comentarios con metadatos de adjuntos inline. Por defecto revisa comentarios públicos; las notas internas requieren opt-in.
Para texto, usa coincidencia literal y sensible a mayúsculas. Muestra ticket/comment IDs, coincidencias y previews escapados antes/después. Permite excluir comentarios.
Para adjuntos, muestra IDs, nombre, tamaño y condición inline. No selecciones archivos automáticamente.
REDACTAR
Utiliza PUT /api/v2/comment_redactions/{comment_id} con ticket_id.
Para texto, envía el html_body existente con marcas <redact> precisas.
Para adjuntos, envía external_attachment_urls solo de los archivos seleccionados de ese comentario.
Trabaja sobre nodos de texto del DOM. No reemplaces cadenas sobre HTML sin analizar. Conserva el resto del contenido. En este MVP, omite coincidencias entre nodos o en elementos no soportados y explica esos casos.
Reporta comentarios/canales no compatibles o sin html_body utilizable. No uses actualización normal del ticket, eliminación o recreación del comentario como alternativa.
CONFIRMACIÓN
Exige revisar el preview, aceptar la irreversibilidad y escribir REDACT.
Cambiar entradas invalida el preview y la confirmación. Cambiar exclusiones o archivos invalida la confirmación.
Antes de ejecutar, revalida al administrador y vuelve a leer los comentarios. Si cambió el contenido, la visibilidad o los adjuntos, exige un nuevo preview.
Procesa un comentario por vez. Respeta Retry-After. No reintentes a ciegas una escritura incierta. Cancelar solo detiene nuevas operaciones.
Amplía el guard de escritura únicamente para el endpoint y los pares ticket/comentario confirmados. Mantén bloqueadas las otras modificaciones de datos.
Vuelve a leer para comprobar resultados y distingue verificado, fallido, omitido e incierto. Permite descargar un reporte depurado de IDs y resultados.
Mantén el contenido original y los términos en memoria. No añadas persistencia ni prometas reanudación tras recarga. Advierte que la operación puede activar reglas existentes de la cuenta.
VALIDACIÓN
Incluye pruebas sintéticas de repeticiones, sensibilidad a mayúsculas, HTML, coincidencias entre nodos, notas internas, alcance de adjuntos, exclusiones, errores, cancelación y guard de escritura.
No ejecutes redacciones reales durante el desarrollo. Las pruebas reales deben iniciarse manualmente sobre contenido descartable mediante el flujo de confirmación.
Compila, informa la evidencia y detente antes de la fase 5.Para la prueba controlada utilizamos una frase ficticia repetida en un comentario y archivos descartables. Revisamos tanto la selección previa como la lectura posterior que reportaba la operación.
Fase 5. Eliminación inicial de tickets
El último módulo funcional usa el borrado nativo por lotes. El MVP no implementa borrado permanente, eliminación de usuarios u organizaciones ni cascadas sobre registros relacionados.
Una solicitud aceptada todavía no es una eliminación completada. El flujo debe consultar el trabajo nativo y distinguir resultados exitosos, fallidos, pendientes e inciertos.
Ver prompt 5: eliminación básica por lotes
Continúa Privacy Operations con una pestaña Delete tickets conectada a App.jsx. Conserva los flujos y controles existentes.
Implementa únicamente eliminación inicial de tickets mediante Zendesk. No añadas eliminación permanente, restauración, usuarios, organizaciones, cascadas ni scheduling.
FUENTES Y PREVIEW
Admite IDs manuales, tickets seleccionados de Discovery completo o una lista completa de tickets. Limita a 1.000 tickets por sesión.
Deduplica y lee los datos actuales. Muestra ID, asunto, estado y updated_at en un preview paginado mantenido en memoria.
Distingue elegibles, no elegibles, ya eliminados, inaccesibles, no disponibles y errores cuando exista evidencia. Un 404 inexplicado no confirma eliminación.
Respeta restricciones nativas, incluidas las de tickets de AI Agent no resueltos o cerrados. No cambies estados para hacerlos elegibles.
Permite exclusiones. Fija los IDs elegibles e invalida la confirmación al cambiar la selección.
CONFIRMACIÓN
Exige revisar la selección, aceptar el ciclo de eliminación y escribir DELETE N TICKETS con la cantidad exacta.
Explica el ciclo nativo de Zendesk, sus límites de recuperación y que esta app no restaura ni elimina permanentemente. Ofrece acceso a Export y aclara que un índice de enlaces no es una copia de los adjuntos.
EJECUCIÓN
Usa DELETE /api/v2/tickets/destroy_many?ids={ids}.
Envía hasta 100 IDs por solicitud. Procesa un lote y espera su resultado antes de enviar el siguiente.
Captura job_status y consulta el endpoint de estado hasta su finalización. Usa la estructura real de resultados; no inventes éxitos individuales.
Revalida al administrador antes de ejecutar y antes de cada lote. Vuelve a leer los tickets. Omite objetivos que cambiaron desde el preview y pide revisión.
Amplía el guard únicamente para DELETE a esa ruta, sin host externo, sin body ni parámetros adicionales y con los IDs confirmados. Conserva los permisos previos de redacción y objetos propios. Bloquea las rutas de eliminación permanente.
ERRORES Y RESULTADOS
Respeta límites y Retry-After. Una respuesta de red o servidor incierta no debe causar un reenvío automático.
Cancelar detiene nuevos lotes; los ya enviados pueden seguir en Zendesk. Si un trabajo continúa al vencer el tiempo de espera, mantén sus tickets pendientes y detén los siguientes lotes.
Si el resultado es ambiguo, usa comprobaciones documentadas de lectura. No interpretes ausencia de un listado como prueba de eliminación.
Muestra cantidades reconciliadas: seleccionados, excluidos, omitidos, enviados, pendientes, éxitos, fallos e inciertos. Exporta JSON/CSV con IDs, jobs, fechas y códigos, sin contenido original.
Mantén el estado en memoria. Explica que recargar lo pierde y que los trabajos enviados pueden continuar. No prometas rollback ni reanudación persistente.
Incluye pruebas sintéticas para entradas, exclusiones, confirmaciones, lotes, jobs, restricciones, reintentos, cancelación, cambios de objetivos, reportes y guard.
No borres tickets reales automáticamente durante el desarrollo. Compila, reporta lo probado y detente antes del cierre.Fase 6. Documentación, uso libre y entrega
La última fase organiza la experiencia y deja instrucciones para que otra persona pueda revisar y extender el trabajo.
Ver prompt 6: cierre, atribución y documentación
Finaliza la presentación y documentación de Privacy Operations. No añadas módulos ni reescribas la lógica que funciona. Usa “Privacy Operations” como nombre y añade: “Desarrollada por Jhoan Zabala. De uso libre para que empresas y administradores la adapten a sus necesidades”. No inventes una licencia ni términos adicionales. Explica brevemente en Overview que la app demuestra flujos prácticos y el alcance de Zendesk App Builder, las APIs de Zendesk y Custom Objects sin backend externo. Simplifica los textos de las pestañas. Deja instrucciones de acción y límites inmediatos. Mueve explicaciones largas a Help o secciones desplegables de Settings. Conserva las confirmaciones y advertencias necesarias al redactar o eliminar. Añade Help con opción de copiar y descargar Markdown: - Funciones y requisitos reales. - Setup de los tres objetos propios. - Guía de cada flujo. - Datos en memoria frente a datos almacenados. - Límites tomados del código, distinguiendo los internos de los de Zendesk. - Evaluación pendiente del acceso de otros roles. - Pruebas realmente observadas y pendientes. - Mapa de módulos, esquema, rutas de escritura permitidas y puntos de extensión. - Receta ordenada de reconstrucción, sin garantizar resultados idénticos. REGISTRO DE EVIDENCIA Marca como evidencia aportada, no como pruebas ejecutadas por esta versión: - Setup y paginación real de objetos propios. - 14 comprobaciones de conjuntos. - Una búsqueda controlada con conteo coincidente. - Exportación JSON de tres tickets y otra con seis comentarios públicos. - 14 comprobaciones sintéticas de redacción. - Redacción de texto y tres adjuntos distribuidos en dos comentarios de prueba. - 19 comprobaciones sintéticas de eliminación. - Eliminación inicial de un ticket descartable con job completado, un éxito y sin resultados inciertos. No incluyas IDs, nombres, dominios de instancia, payloads ni datos reales. No declares probado CSV, índice de adjuntos exportado, grandes volúmenes, recuperación real tras recarga o acceso de otros roles si no existe evidencia. RESPONSABILIDAD Incluye en Help que la app es una base adaptable. La empresa debe revisar código, permisos y datos con sus equipos de desarrollo y seguridad antes de utilizarla. El administrador y la organización son responsables de su configuración, modificaciones y tratamiento de información. Jhoan Zabala no asume responsabilidad por uso indebido o manejo inadecuado de información mediante la app. No presentes el aviso como garantía jurídica o certificación. CONTACTO Email: jzabalacx@gmail.com Web: https://www.jhoanzabala.com LinkedIn: https://www.linkedin.com/in/jhoanzabala/ Comprueba textos, navegación y guía descargable. Compila. Reporta qué verificaste realmente, sin ejecutar modificaciones reales ni publicar automáticamente.
El prompt de control que utilizamos entre fases
Cuando la respuesta de App Builder describía más de lo que podíamos comprobar, volvíamos a pedir una revisión del código y de la evidencia.
Ver prompt de revisión: confirmar lo construido antes de continuar
Antes de avanzar, inspecciona el código actual y contrástalo con los requisitos de esta fase. Confirma que los archivos existen, contienen la versión esperada y están conectados a la navegación. Aplica secuencialmente los cambios dependientes sobre un mismo archivo para evitar sobrescrituras. Si falta algo, completa únicamente esa parte y conserva lo que funciona. No presentes una función ausente como una limitación de Zendesk sin verificarlo. Devuelve una tabla con requisito, ubicación en la UI, estado, evidencia y acción pendiente. Distingue: - Compilación. - Prueba sintética ejecutada. - Prueba real ejecutada. - Inspección de código. - Prueba pendiente. No digas que una prueba pasó si no la ejecutaste. No confundas la creación de una versión con funcionamiento verificado. No uses datos reales durante las pruebas automáticas de modificación. Compila y detente al terminar la fase. Espera la validación antes de la siguiente.
Cómo desarrollarla e instalarla en tu cuenta
Recomiendo comenzar en sandbox o con casos de prueba controlados. El botón Test utiliza datos reales del entorno seleccionado: no convierte por sí solo una operación destructiva en una simulación.
- Comprueba los requisitos. Necesitas acceso de administrador, App Builder, Custom Objects, cuotas suficientes y las capacidades que utilicen las APIs. Para redacción, revisa Agent Workspace y los permisos correspondientes.
- Abre Admin Center → Apps and integrations → Apps → App Builder. Inicia una conversación y selecciona Side Navigation, correspondiente a
nav_bar. - Envía el prompt de la fase 1. Revisa el plan propuesto, el código y la interfaz antes de continuar.
- Ejecuta los checks de Settings. Revisa permisos y esquema antes del setup. Luego configura los objetos propios y utiliza registros sintéticos para los diagnósticos.
- Continúa con los prompts en orden, en la misma conversación. Usa el prompt de control cuando haya dudas o diferencias entre el reporte y lo que observas.
- Prueba cada fase y conserva versiones útiles. Distingue los mocks de Preview de las pruebas de Test. Comprueba el archivo exportado, el contenido redactado y el resultado del job de eliminación, según corresponda.
- Haz la revisión de la empresa. Desarrollo y seguridad deben evaluar permisos efectivos, manejo de datos y rutas de escritura antes de usar información operativa.
- Publica solo cuando decidas habilitarla. En App Builder, Publish permite configurar roles o grupos y completar la instalación en esa cuenta. Restringe esta app a administradores.
- Verifica la instalación con una prueba pequeña. Comprueba navegación, acceso y operaciones permitidas en el entorno donde realmente se utilizará.
No asumas que la app de sandbox se traslada automáticamente a producción. La documentación actual de App Builder indica que la construcción está vinculada a un entorno y debe recrearse en otro cuando corresponda. Conserva los prompts y registra los ajustes propios de cada cuenta.
Qué llegamos a comprobar
Para esta base realizamos pruebas pequeñas y controladas. El objetivo fue verificar recorridos concretos, sin presentar el resultado como una prueba de carga o una evaluación completa de seguridad.
| Área | Evidencia disponible |
|---|---|
| Configuración y paginación | Creación de los objetos propios y recuperación de siete registros sintéticos a través de tres páginas, seguida de su limpieza. |
| Operaciones entre listas | 14 comprobaciones en memoria de unión, intersección, diferencia y validaciones de compatibilidad. |
| Discovery | Consulta conectada a Zendesk con resultados y conteo coincidentes en una muestra pequeña. |
| Exportación | JSON válido de tres tickets; una segunda exportación incluyó seis comentarios públicos. |
| Redacción | 14 comprobaciones sintéticas y una prueba controlada de texto, además de tres adjuntos distribuidos en dos comentarios. |
| Eliminación | 19 comprobaciones sintéticas y un ticket descartable eliminado con trabajo nativo completado y resultado exitoso. |
Quedaron pendientes pruebas de grandes volúmenes, acceso efectivo de otros roles, recuperación real tras recarga, contenido de salida CSV e índice exportado con adjuntos reales. Tampoco comprobamos todos los canales y casos de redacción ni una eliminación real con varios lotes.
Límites de esta versión
Estos son límites del MVP construido, no una lista de límites generales de Zendesk.
| Área | Límite o comportamiento de esta base |
|---|---|
| Discovery | Hasta 20.000 IDs; si se detiene antes del fin, el resultado debe mostrarse como parcial. |
| Entrada y listas | Entrada de hasta 3.000 IDs; listas y selecciones diseñadas para ese tamaño. Los límites de campos y registros siguen aplicando. |
| Redacción | Hasta 50 tickets por preview y texto de búsqueda de hasta 500 caracteres. Coincidencia literal sensible a mayúsculas; algunos casos de HTML y tipos de contenido se omiten. |
| Eliminación | Hasta 1.000 tickets por sesión y 100 por solicitud. Solo eliminación inicial de tickets; las restricciones nativas siguen vigentes. |
| Exportación | Limitada por la memoria del navegador. Se divide por cantidad de objetivos, lo que no garantiza un tamaño máximo de archivo. |
| Adjuntos exportados | Se genera un índice con enlaces; los archivos no se incorporan a la exportación. |
| Persistencia operativa | Exportaciones, previews y resultados principales permanecen en memoria y se pierden al recargar. |
| Procesos en segundo plano | La app no programa tareas ni garantiza continuidad con el navegador cerrado. Los jobs nativos ya enviados pueden continuar. |
| Permisos | El acceso de otros roles a los objetos propios requiere una evaluación específica de la cuenta. La visibilidad de la UI no demuestra aislamiento de datos. |
Además, una redacción es irreversible y puede generar actualizaciones que activen reglas existentes. No redacta automáticamente copias externas del mismo contenido. La eliminación de tickets sigue el ciclo nativo de Zendesk, con sus reglas de recuperación y posterior eliminación permanente.
En esta base, Process Preparation prepara selecciones y Processes conserva infraestructura de diagnóstico; no deben interpretarse como una orquestación persistente de todas las acciones. El guardado de listas y la persistencia de una selección congelada son rutas diferentes y deben revisarse por separado.
Cómo podría extenderla una empresa
El límite del MVP ayuda a decidir qué desarrollar después. Si la necesidad es una acción manual, con un volumen controlado, la app puede ser una base útil dentro de Zendesk. Si se necesita ejecución continua, grandes archivos o coordinación entre varios administradores, conviene cambiar la arquitectura.
Una extensión con backend propio podría incorporar:
- Cola de trabajo persistente: ejecución y reanudación independientes del navegador.
- Scheduler: tareas programadas según políticas de retención aprobadas.
- Procesamiento de archivos: descarga autorizada de adjuntos, empaquetado y exportaciones por tamaño real.
- Coordinación entre sesiones: control de concurrencia y prevención de ejecuciones simultáneas.
- Trazabilidad protegida: historial persistente con permisos y retención definidos.
- Controles adicionales: aprobaciones por operación, exclusiones por política y validaciones específicas de cada negocio.
Ese backend tendría costos y responsabilidades propios. Habría que definir autenticación, gestión de credenciales, permisos mínimos, almacenamiento, retención y eliminación de los archivos generados. Añadir infraestructura no elimina la obligación de revisar la solución; amplía su superficie y sus decisiones de diseño.
También es posible extender primero lo que permanece dentro de la app: filtros adicionales, una navegación más compacta, más casos de prueba o mejores reportes, siempre comprobando las capacidades reales de las APIs.
Uso libre y responsabilidad sobre la información
Esta app la desarrollé yo, Jhoan Zabala, y es de uso libre para que empresas y administradores la adapten a los casos de uso que necesiten.
Es una base de desarrollo. Antes de construirla, modificarla o utilizarla con información de la empresa o de sus clientes, la organización debe revisar su implementación con sus equipos de desarrollo y seguridad, además de las áreas responsables de los datos cuando corresponda.
La configuración, los permisos, las modificaciones, las decisiones de exportación, redacción o eliminación y el tratamiento de la información son responsabilidad del administrador y de la empresa que utilizan la app. No asumo responsabilidad por el uso indebido de la herramienta ni por el manejo inadecuado de información en una instancia mediante su utilización.
Este aviso no convierte la app en una solución certificada ni sustituye las políticas, validaciones y obligaciones de la organización. Empieza en sandbox o con registros descartables y verifica cada operación antes de utilizar datos operativos.
Lo que este ejercicio muestra sobre App Builder
App Builder permitió construir una interfaz, conectar APIs, almacenar configuraciones y ejecutar flujos con confirmación sin desplegar servicios propios. Eso amplía el espacio de soluciones que un administrador puede explorar dentro de Zendesk.
El trabajo no terminó al recibir código generado. Hubo que acotar el alcance, revisar archivos, corregir interpretaciones, probar resultados y documentar lo que permanecía pendiente.
Documentación oficial consultada
- Using App Builder
- Crear, publicar y gestionar apps con App Builder
- Búsquedas y exportación de resultados
- Referencia de búsquedas de tickets
- Registros de Custom Objects
- Permisos de Custom Objects
- Peticiones desde una app y restricción de binarios
- Comentarios y API de redacción
- Redacción de contenido
- API de tickets
- Estados de trabajos nativos
- Eliminación de tickets
Documentación consultada el 5 de noviembre de 2026. Las capacidades, límites y requisitos pueden cambiar; comprueba la documentación vigente para tu cuenta.
Contacto
Si necesitas ayuda para adaptar esta app, revisar un caso de uso o desarrollar una solución sobre Zendesk: