Toda empresa tiene reglas que hoy viven en la cabeza de alguien y se ejecutan a mano.
Avisar al vendedor cuando su pedido se aprueba, marcar un contrato como vencido el día que corresponde, abrir la tarea de revisión cada vez que entra un cliente nuevo.
Un flujo de trabajo toma esa regla y la convierte en comportamiento del sistema, que se cumple siempre y sin que nadie tenga que acordarse.
Un flujo, por complejo que parezca, siempre se puede describir con estas tres piezas.
Es el momento en que el flujo entra en acción.
Puede ser el guardado de un registro, la llegada de una fecha, la publicación de un cambio en un campo determinado o una persona que aprieta un botón en la pantalla.
Es el filtro que decide si el flujo sigue o se detiene ahí mismo.
Sin condición, el flujo se ejecutaría en todos los casos, y lo habitual es que la regla de negocio aplique solo a una parte: los pedidos de más de cierto monto, los clientes de una región, los productos de una familia.
Es lo que el flujo hace cuando la condición se cumple.
Crear un registro, actualizar campos, asignar un responsable, enviar un aviso, iniciar un proceso de aprobación o llamar a otro flujo.
Un mismo flujo puede encadenar varias acciones en orden, y también puede bifurcarse y hacer una cosa u otra según lo que encuentre.
La característica que define a un flujo de trabajo es que se arma de forma declarativa, o sea describiendo qué tiene que pasar en lugar de programarlo.
La consecuencia práctica es grande: la distancia entre la regla de negocio y su implementación se acorta muchísimo.
Quien conoce el proceso puede explicarlo en sus propias palabras y ese texto ya es, casi literalmente, la especificación del flujo.
Cuando la lógica excede lo que el modo declarativo cubre, el flujo puede llamar a código escrito en Apex, así que el techo es alto y la puerta de entrada sigue siendo baja.
No todos los flujos se comportan igual, y la diferencia importa al momento de pedir uno.
Se dispara cuando se crea o se modifica un registro y actúa en el acto.
Es el que usamos para completar campos calculados en el momento, asignar un responsable o crear un registro relacionado apenas nace el principal.
Corre en un horario definido y recorre los registros que cumplen una condición.
Es el que revisa cada mañana qué contratos vencen esta semana o qué facturas quedaron impagas, y actúa sobre todas ellas de una vez.
Guía a una persona paso a paso, pidiéndole datos y decidiendo qué mostrar según lo que responde.
Es lo que convierte un procedimiento largo en un formulario corto que nadie puede completar mal.
El beneficio evidente es el tiempo ahorrado, pero no es el más importante.
El más importante es que la regla se cumple siempre y de la misma manera, incluso el día que la persona que la conocía está de vacaciones.
El segundo es que queda escrita: cuando alguien pregunta por qué el sistema hizo tal cosa, la respuesta está en el flujo y no en una costumbre.
Y el tercero es que se puede cambiar en un solo lugar, así que ajustar una política deja de significar avisarle a diez personas.
Ese es exactamente el trabajo que hace el ERP en la nube de EGA Futura.
Los flujos son los que sostienen el comportamiento automático del ERP, y en el día a día se notan más por lo que evitan que por lo que se ve.
Un pedido que al aprobarse reserva el stock, una orden de mantenimiento que al cerrarse actualiza la ficha del activo, un contrato que cambia de estado el día que corresponde.
Estos son los recorridos que aparecen una y otra vez en las implementaciones.
En inventario, un flujo puede vigilar el punto de reorden de cada existencia y abrir una solicitud de compra cuando el stock cae por debajo del mínimo.
En ventas, un flujo puede asignar el vendedor según la región del cliente y crear la tarea de seguimiento con la fecha ya calculada.
En tesorería, un flujo programado puede recorrer los vencimientos de cada mañana y disparar una alerta por email al responsable de cobranzas.
Un flujo casi nunca trabaja solo.
Se apoya en los campos del objeto para decidir, en los tipos de registro para distinguir variantes del mismo proceso, y en las plantillas de correo para que el aviso salga siempre con el mismo formato.
Y cuando el proceso necesita el visto bueno de una persona, el flujo lo entrega a un proceso de aprobación y espera la respuesta antes de seguir.
Acá está la diferencia con un ERP que se compra y después hay que hacer funcionar.
La Org la administra EGA Futura, así que tu empresa no necesita aprender a armar flujos ni contratar a alguien que sepa hacerlo.
El equipo del cliente describe la regla en palabras de negocio, del tipo cuando un pedido supera cierto monto tiene que aprobarlo el gerente comercial antes de reservar stock.
Con esa frase alcanza: EGA Futura construye el flujo, lo prueba y lo deja andando.
Es servicio incluido, y es lo que permite que el sistema se vaya ajustando al proceso real de cada empresa en lugar de obligarla a adaptarse al software.
Estas son las dudas más habituales cuando una empresa empieza a automatizar sus reglas dentro del ERP.
No, y esa es su razón de ser.
Un flujo se arma de forma declarativa, describiendo qué tiene que pasar y bajo qué condición, sin escribir código.
Cuando la lógica es muy particular, el flujo puede llamar a código en Apex, pero eso es la excepción y no el punto de partida.
Un proceso de aprobación existe para conseguir el visto bueno de una persona y deja registro de quién aprobó y cuándo.
Un flujo es más general: automatiza cualquier comportamiento, y puede iniciar un proceso de aprobación como una de sus acciones.
Muchas veces los dos aparecen juntos en el mismo circuito.
Corre solo cuando se cumple la condición que tiene definida.
Esa condición es la que separa los pedidos que necesitan aprobación de los que siguen de largo, o los clientes de una región de los del resto.
Se ajusta el flujo en un solo lugar y el cambio rige desde ese momento para todos los registros nuevos.
Esa es una de las ventajas más concretas frente a una regla que vive en la costumbre de cada equipo.
El pedido se hace describiendo la regla nueva, sin necesidad de tocar nada del sistema.
Sí, y es una de sus acciones más usadas.
El flujo dispara una alerta por email que toma una plantilla de correo y una lista de destinatarios, así que el aviso sale siempre igual.
Es la forma en que el sistema avisa sin que nadie tenga que estar mirando la pantalla.
Los construye EGA Futura, porque la Org la administra su equipo.
Tu empresa describe la regla y esa implementación forma parte del servicio, así que la automatización deja de depender de tener perfiles técnicos propios.
Quien quiera ver hasta dónde llega esto en cada edición puede mirar los planes del ERP.
Esta sección es para quien escribe requerimientos de automatización o trabaja sobre la Org, y necesita nombrar cada pieza con el término correcto.
Elegir bien el tipo desde el pedido evita rehacer el trabajo, porque cambiarlo después implica construir otro flujo.
| Tipo | Cuándo corre | Caso típico |
|---|---|---|
| Record-Triggered antes de guardar | Al crear o modificar, sobre el mismo registro | Completar campos del propio registro |
| Record-Triggered después de guardar | Al crear o modificar, ya con el identificador asignado | Crear registros relacionados y enviar avisos |
| Schedule-Triggered | En un horario definido, sobre un conjunto de registros | Vencimientos diarios y recordatorios |
| Screen Flow | Cuando una persona lo inicia desde la pantalla | Alta guiada paso a paso |
| Autolaunched | Llamado por otro flujo, por Apex o por una integración | Lógica reutilizable |
Son el vocabulario con el que se describe el recorrido, y usarlo bien acorta las vueltas.
| Elemento | Qué hace | Nota |
|---|---|---|
| Get Records | Busca registros que cumplen un criterio | Es el paso previo a decidir o actualizar |
| Decision | Bifurca el recorrido según una condición | Cada rama puede terminar distinto |
| Assignment | Guarda un valor en una variable del flujo | No toca la base de datos |
| Create y Update Records | Crea o modifica registros | Es donde el flujo deja su efecto |
| Action | Invoca una alerta por email, una aprobación o código Apex | Es la puerta al resto de la Plataforma |
| Loop | Recorre una colección de registros de a uno | Habitual en los flujos programados |
Un pedido con estos cuatro datos se implementa sin idas y vueltas.
| Dato | Ejemplo de cómo se escribe |
|---|---|
| Disparador | Cuando se guarda un pedido con estado Aprobado |
| Condición | Solo si el monto total supera el límite de la región |
| Acción | Crear la reserva de stock y avisar al vendedor |
| Excepción | Los pedidos internos no reservan stock |
Hay tres cosas que definen el diseño y conviene anticiparlas en el pedido.
La primera es el orden: un flujo que corre antes de guardar es el lugar barato para completar campos del propio registro, mientras que crear registros relacionados exige correr después, cuando el identificador ya existe.
La segunda es que la automatización se ejecuta con permisos amplios por diseño, así que un flujo puede actualizar registros que el usuario que lo disparó no vería, y eso es deseable en un circuito de aprobación pero conviene declararlo.
La tercera es que un flujo que actúa sobre muchos registros a la vez se diseña distinto de uno que actúa sobre uno solo, de modo que decir cuántos registros esperamos tocar por corrida cambia la construcción desde el principio.
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