Hay información que pierde casi todo su valor si llega tarde.
Un stock que se quedó corto, un contrato que vence el viernes o una aprobación frenada hace tres días son cosas que alguien tiene que saber en el momento, no cuando abre el sistema a revisar.
La alerta por email resuelve exactamente eso: convierte un evento del sistema en un correo que llega al buzón de quien tiene que actuar.
Toda alerta se describe con estos tres elementos, y describirlos bien es lo que hace que un pedido se implemente rápido.
La alerta no decide sola cuándo enviarse: la llama un flujo de trabajo que ya evaluó la condición.
Esa condición puede ser el cambio de estado de un registro, la llegada de una fecha o el resultado de una revisión programada que corre cada mañana.
El texto del correo no se escribe cada vez: sale de una plantilla de correo electrónico definida de antemano.
La plantilla trae el asunto, el cuerpo y los espacios donde se insertan los datos del registro, así que cada correo llega con el número, el importe y el nombre que corresponden.
Gracias a eso todos los avisos del mismo tipo se ven iguales y hablan con la misma voz.
Es quién recibe el aviso, y admite varias formas de definirse a la vez.
Puede ser el propietario del registro, su responsable jerárquico, un usuario fijo, un grupo entero o una dirección de correo escrita a mano.
Definir bien esta lista es lo que separa un aviso útil de un correo que todos aprenden a ignorar.
El beneficio no es solo la comodidad de no revisar el sistema.
Es que el aviso se produce siempre, con el mismo criterio y sin depender de que alguien se acuerde.
Una empresa que confía en que el encargado de compras mire la lista de faltantes tiene un proceso que funciona los días que el encargado tiene tiempo.
Con una alerta, ese control pasa a ejecutarse todos los días a la misma hora, incluso durante las vacaciones de la persona.
El segundo efecto es que el aviso llega con contexto: no dice que hay un problema, dice cuál es el registro, qué valor lo disparó y a quién le toca resolverlo.
No todo aviso tiene que salir por correo, y elegir el canal es parte del diseño.
Sirve cuando el destinatario no está mirando el sistema en ese momento y cuando el aviso tiene que quedar guardado en algún lado.
Es el canal natural para vencimientos, aprobaciones pendientes y resúmenes que alguien va a querer reenviar.
Sirve cuando la persona ya está trabajando en el sistema y el aviso se resuelve en dos clics.
Las Notificaciones son menos invasivas y no compiten con el resto del correo del día.
Muchos circuitos usan los dos canales para el mismo evento, con criterios distintos de urgencia.
Un aviso inmediato dentro de la Plataforma y un correo recién cuando pasaron dos días sin respuesta es un patrón que funciona muy bien.
Una alerta mal pensada hace más daño que la ausencia de alerta.
Cuando el mismo correo llega veinte veces por día, el equipo arma una regla en su buzón y el aviso deja de existir en la práctica.
Por eso conviene que cada alerta responda tres preguntas antes de construirse: quién tiene que hacer algo, qué tiene que hacer y en qué plazo.
Si alguna de las tres queda sin respuesta, casi siempre lo que corresponde es un informe o un panel, y no un correo.
Las alertas por email son la voz del ERP hacia afuera de la pantalla, y aparecen en los puntos del proceso donde el tiempo cuesta dinero.
Estos son los circuitos que casi todas las empresas terminan pidiendo.
En inventario, cuando la existencia de un producto cae por debajo de su punto de reorden, la alerta llega al responsable de compras con el producto, el almacén y la cantidad disponible ya calculada.
En tesorería, un recorrido programado revisa cada mañana los vencimientos de la semana y avisa al responsable de cobranzas con el listado del día.
En mantenimiento, cuando una póliza pasa a estado Por vencer, el aviso sale a quien tiene que gestionar la renovación con treinta días de margen.
La alerta es siempre el último eslabón de una cadena que empieza antes.
El flujo de trabajo evalúa la condición, la plantilla arma el mensaje con los datos del registro, y la lista de destinatarios decide a quién le llega.
Cuando el circuito necesita una respuesta y no solo un aviso, el mismo flujo puede iniciar un proceso de aprobación, y ahí el correo incluye el pedido concreto.
Armar una alerta implica definir la condición, escribir la plantilla, elegir los destinatarios y probar el envío antes de dejarlo andando.
La Org la administra EGA Futura, así que tu empresa no necesita un administrador propio para tener el aviso que le hace falta.
Alcanza con describir la situación en palabras de negocio: quién tiene que enterarse, de qué, en qué momento y con qué datos a la vista.
Con eso, EGA Futura construye el circuito completo y lo deja funcionando.
Es servicio incluido, y es lo que permite que los avisos se vayan afinando con la experiencia real del equipo en lugar de quedar como los dejó la instalación inicial.
Estas son las dudas que aparecen cuando una empresa empieza a definir qué quiere que le avise el sistema.
Hace falta algo que la dispare.
La alerta es una acción, no una regla: la llama un flujo de trabajo que ya evaluó la condición, o bien código Apex.
Por eso, cuando se pide un aviso nuevo, en realidad se está pidiendo el par completo de condición y aviso.
El texto vive en una plantilla de correo electrónico, así que se ajusta ahí una sola vez y el cambio rige para todos los envíos siguientes.
La plantilla incluye los espacios donde se insertan los datos del registro, de manera que cada correo llega con el número, la fecha y el importe correctos.
A quien esté definido en la lista de destinatarios, que admite varias formas combinadas.
Puede ser el propietario del registro, su responsable jerárquico, un usuario concreto, un grupo entero o una casilla externa.
Conviene revisar esa lista cada tanto, porque los cambios de equipo suelen dejar avisos llegando a quien ya no se ocupa del tema.
La notificación aparece dentro de la Plataforma y sirve cuando la persona ya está trabajando ahí.
El correo llega al buzón y sirve cuando el destinatario no está mirando el sistema o cuando el aviso tiene que quedar guardado.
Muchos circuitos usan los dos canales para el mismo evento, con plazos distintos.
Limitando cada alerta a los casos donde alguien tiene que hacer algo concreto.
Si el aviso no dice quién actúa, qué tiene que hacer y en qué plazo, casi siempre conviene un informe o un panel en lugar de un correo.
Un buzón lleno de avisos que nadie mira es peor que no tener aviso.
Las configura EGA Futura, porque la Org la administra su equipo.
Tu empresa describe qué quiere que le avise el sistema y la implementación forma parte del servicio, junto con el resto de la puesta a punto del ERP en la nube.
Esta sección es para quien escribe requerimientos de avisos automáticos o trabaja sobre la Org, y necesita nombrar cada pieza con precisión.
Una alerta queda completamente especificada con estos cuatro datos.
| Pieza | Qué define | Nota |
|---|---|---|
| Objeto | Sobre qué registro se dispara | Determina qué campos puede usar la plantilla |
| Plantilla de correo | Asunto y cuerpo del mensaje | Con campos de combinación del registro |
| Destinatarios | Quién recibe el correo | Se pueden combinar varios tipos a la vez |
| Remitente | Con qué dirección sale el mensaje | Puede ser el usuario actual o una dirección de la organización |
Conviene conocerlos porque casi siempre la solución correcta es una combinación y no un usuario fijo.
| Tipo | A quién resuelve | Cuándo conviene |
|---|---|---|
| Propietario del registro | El usuario dueño del registro | Avisos de seguimiento comercial |
| Responsable del propietario | El superior jerárquico | Escalamientos por falta de respuesta |
| Usuario | Una persona concreta | Circuitos con un único responsable |
| Grupo o rol | Un conjunto de personas | Guardias y equipos rotativos |
| Campo de correo del registro | La dirección guardada en el propio registro | Avisos al cliente o al proveedor |
| Dirección de correo adicional | Una casilla escrita a mano | Buzones compartidos y externos |
La alerta es una acción reutilizable, así que el mismo aviso puede servir a varios circuitos.
| Origen | Cómo la llama |
|---|---|
| Flujo de trabajo | Como elemento de acción dentro del recorrido |
| Proceso de aprobación | En los pasos de envío, aprobación y rechazo |
| Apex | Invocando la alerta desde el código |
Hay tres cosas que conviene anticipar al redactar el pedido, porque cambian el diseño del circuito.
La primera es que la alerta no evalúa nada por su cuenta: toda la lógica de cuándo avisar vive en el flujo que la llama, así que un requerimiento que solo describe el correo queda a mitad de camino.
La segunda es que un recorrido que actúa sobre muchos registros a la vez conviene resolverlo con un único correo resumen en lugar de uno por registro, y decirlo desde el pedido evita rehacerlo después de la primera mañana de cien avisos.
La tercera es que los campos que la plantilla puede insertar dependen del objeto sobre el que se define la alerta, o sea que un aviso que necesita datos del cliente y de la factura al mismo tiempo tiene que definirse sobre el objeto que llega a los dos.
Nombrar el objeto en el requerimiento es, por eso, más importante que describir el texto del mensaje.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
Quiero llevar mi Empresa a la Nube