Documentação

Español

Português
English

Español

Português
English

Appearance

Envío de correo electrónico ​

Requisitos previos de acceso

  • Permiso (módulo): acceso habilitado por el guard administrativo de la ruta (admin). No existe un módulo dinámico específico para esta pantalla — cualquier operador con acceso al BackOffice y al grupo de Comunicación puede abrirla.
  • Licencia/Feature: Ninguna.
  • Ubicación en el menú: GENERAL → grupo Comunicación (ícono campaign) → Envío de correo electrónico.

Qué es / cuándo usar ​

Pantalla para crear y programar envíos masivos de correo electrónico (o a una lista de destinatarios específicos) desde el BackOffice. Úsala para comunicados, campañas promocionales, avisos operacionales y mensajes de relacionamiento, sin necesidad de deploy ni herramienta externa. Cada envío creado se convierte en una "acción en masa" (entidad MassActions, action = 'EMAIL') que entra en una cola y es procesada por un scheduler del CommunicationGateway — no hay envío síncrono en el momento de "Confirmar".

Requisitos previos ​

  • Permiso: el ítem está bajo el guard admin de la ruta. Recuerda que en Axia el permiso es doble (enum CPM en el backend + módulo dinámico en la BD); aquí el gate efectivo es el guard de ruta, por lo que valida que el operador tenga perfil administrativo.
  • Licencia/Feature: no se exige ninguna feature de licencia para abrir la pantalla.
  • Dependencias con otras pantallas: en el modo single (destinatario individual), el correo electrónico ingresado es validado contra la base de usuarios — solo entra en la lista quien posee una cuenta/billetera registrada. Para el contenido visual final de los correos, el Template Master define el "sobre" HTML aplicado a los envíos.

Paso a paso ​

  1. Accede al menú Comunicación → Envío de correo electrónico.
  2. La pantalla lista los envíos ya creados, con las columnas Cuándo, Asunto, Estado y acciones de editar/eliminar.
  3. Haz clic en Nuevo / Crear para abrir el modal de creación.
  4. Elige el público en el selector superior: Todos (all) o Individual (single).
  5. En el modo Individual, escribe cada correo y haz clic en el botón + para validarlo y agregarlo como chip; repite para cada destinatario.
  6. Completa Asunto, Mensaje y Fecha de programación.
  7. Haz clic en Confirmar. El envío se crea con estado inicial y entra en la cola del scheduler.

Campos ​

Listado ​

ColumnaQué muestraOrigen del dato
Cuándo (when)Fecha de creación/programación del envíoCampo when/scheduleTo de MassActions
Asunto (subject)Asunto del correo electrónicoCampo subject
Estado (status)Estado del envío: CREATED/PENDING (en cola), EXECUTED (enviado), CANCELLED (cancelado)Campo status, actualizado por el scheduler
EditarReabre el modal en modo edición—
EliminarCancela el envío (no elimina: marca status = 'CANCELLED')—
CampoQué es¿Obligatorio?Efecto en el sistema/backend
Público (Todos / Individual)Define si el envío va a toda la base o a una listaSíEn el backend, all = true hace que el handler busque todos los usuarios (getAllUsers) y cree un registro mass_actions_users PENDING por usuario; all = false crea un registro por correo de la lista. En modo edición, el toggle queda bloqueado (no es posible cambiar el público de un envío existente).
Correo electrónico (solo en modo Individual)Destinatario a agregarCondicional (≥1 en modo Individual)Al hacer clic en +, el correo se valida contra la base mediante getUserByEmailWallet: solo se acepta si existe un usuario/billetera correspondiente. Se convierte en un chip; el envío no confirma con la lista vacía en modo Individual.
Asunto (subject)Línea de asunto del correoSíGuardado en MassActions.subject (máx. 100 caracteres). Utilizado como subject en el envío real.
Mensaje (message)Cuerpo del correoSíGuardado en MassActions.message. Acepta HTML y el token de personalización @user.name (ver Reglas). Se inyecta tanto en bodyData como en htmlData en el envío.
Fecha (when)Fecha a partir de la cual el envío puede ser procesadoSíMínimo = hoy (no permite fechas pasadas). El scheduler se ejecuta cada 30 minutos y procesa la cola; la fecha determina la programación del envío.

Acciones y modales ​

  • Crear (Confirmar): crea la MassActions (action = 'EMAIL', status = 'CREATED') y los registros de destinatario PENDING. Tras guardar, la pantalla se recarga.
  • Editar: permite ajustar Asunto, Mensaje y Fecha de un envío existente; el público (Todos/Individual) y la lista de correos quedan de solo lectura. Al guardar, el envío vuelve a status = 'CREATED'.
  • Eliminar: no elimina físicamente — marca el envío como CANCELLED, retirándolo del procesamiento.
  • Step-up / MFA: esta pantalla no dispara re-autenticación por defecto. Trata el envío masivo como una acción sensible en la operación (público amplio, irreversible tras el envío).

Reglas de negocio / consideraciones ​

Atención

  • El correo individual solo se acepta si ya existe en la base (validación getUserByEmailWallet). Direcciones externas/desconocidas no se agregan a la lista.
  • El envío no es inmediato: el CommunicationScheduler se ejecuta en el cron */30 * * * * (cada 30 min). Después de "Confirmar", hay latencia hasta que el envío salga.
  • El mensaje acepta HTML. Como el cuerpo se inyecta en bodyData y htmlData, el HTML malformado puede romper el renderizado en proveedores como Mailgun/Brevo/SendGrid (en SES el problema queda enmascarado).
  • Personalización: si el mensaje contiene @user.name, el scheduler busca el primer nombre del usuario y reemplaza el token por destinatario. Sin el token, el mensaje se envía de forma literal.

Irreversible

  • Una vez que el scheduler procesa el envío, no hay rollback del correo enviado. Eliminar/cancelar solo impide envíos aún PENDING — los correos ya EXECUTED permanecen entregados. Revisa el público, el asunto y el cuerpo antes de confirmar, especialmente en el modo Todos (alcanza toda la base).
  • Idempotencia: el procesamiento es idempotente por destinatario — cada mass_actions_users solo se envía cuando está PENDING y pasa a EXECUTED tras el envío. Las re-ejecuciones del scheduler no reenvían a quienes ya recibieron el correo. Al finalizar, la MassActions también pasa a EXECUTED.
  • Observación sobre el estado: los envíos CANCELLED son ignorados por el scheduler.

Ejemplos ​

Escenario 1 — Comunicado para toda la base
  1. Nuevo → público Todos.
  2. Asunto: Mantenimiento programado el fin de semana.
  3. Mensaje (HTML simple): <p>Hola @user.name, realizaremos mantenimiento el sábado de 2h a 5h.</p>.
  4. Fecha: hoy.
  5. Confirmar. El handler crea un registro PENDING para cada usuario de la base; en el siguiente ciclo del scheduler (≤ 30 min) cada uno recibe el correo con su nombre en lugar de @user.name. El estado del envío pasa a EXECUTED.
Escenario 2 — Envío individual a una lista corta
  1. Nuevo → público Individual.
  2. Escribe joao@cliente.com, haz clic en + (validado contra la base → se convierte en chip). Repite para maria@cliente.com.
  3. Asunto y mensaje normales; Fecha: hoy.
  4. Confirmar. Solo los 2 destinatarios reciben registros PENDING. Si un correo no existe en la base, el + no lo agrega y queda fuera.
Escenario 3 — Corregir el asunto de un envío aún no enviado
  1. En el listado, haz clic en Editar de un envío CREATED/PENDING.
  2. El selector de público y la lista de correos aparecen bloqueados; ajusta solo Asunto o Mensaje.
  3. Confirmar. El envío vuelve a CREATED y será reprocesado por el scheduler. Los destinatarios que aún están PENDING reciben la versión corregida; quienes ya están EXECUTED no se ven afectados.

Pantallas relacionadas ​