Posted: 14 Jul. 2022 4 minutos Tiempo de lectura

Salesforce Flows: Evolución hacia los Flows

Salesforce siempre ha buscado que configurar su plataforma fuera algo sencillo y potente. De este modo, incluso administradores sin conocimientos de programación, podrían fácilmente ajustar las funcionalidades básicas de la plataforma a sus procesos de negocio.

Para realizar dicho desarrollo sin código, se liberaron un conjunto de herramientas. La más reciente, está recibiendo en los últimos tiempos una gran cantidad de mejoras que la convierten en fundamental para todo desarrollo actual.

Pero, ¿cómo llegamos a este punto? A continuación, se hará una introducción a la evolución de dichas herramientas de automatización, partiendo de las más antiguas: Workflow Rules, Process Builder y los actuales Flow

El principio de todo: los Workflow Rules

Inicialmente, aparecieron los Workflow Rules, que permitían una lógica sencilla, pero era suficiente para procesos de negocio sencillos. A pesar de sus desventajas, permitía que muchas operaciones no requirieran del uso de código Apex.

Cada Workflow Rule depende (o actúa) sobre un objeto. Se divide en: 

  • Condiciones de activación: conjunto de condiciones para la ejecución
  • Acciones a ejecutar: distintas acciones a llevar a cabo si las condiciones se cumplían

De este modo, es sencillo crear procesos automáticos simples, con una diversidad de acciones más que suficiente: modificar campos de un registro, enviar un email, crear una tarea, o enviar información a un servicio externo.

Sin embargo, tiene grandes desventajas. Por un lado, la cantidad y flexibilidad de las acciones no es suficiente para flujos más elaborados. Pero además, para cada conjunto de condiciones de un objeto, es necesario crear una Workflow Rule separada.

Este último inconveniente hace complejo el mantenimiento y comprensión de estas automatizaciones, ya que la lista de Workflow Rules tiende a crecer, y no se presentan de una forma ordenada, sino que cada uno es independiente. Además, la plataforma no asegura su ejecución en un orden determinado, lo cual produce en ocasiones comportamientos cuya causa no es clara.

La solución: los Process Builder

Los Process Builder aparecen en Salesforce para unir en un solo flujo varias condiciones de activación, con sus acciones a llevar a cabo. De este modo, se permite crear, para un objeto, un flujo de proceso, compuesto de ramas, cada una conteniendo condiciones de ejecución, y las acciones que pueden ejecutarse.

Con ellos, ya es posible tener reunidos todos los procesos automáticos que afectan a un objeto, así como conocer de forma determinista en qué orden se van a ejecutar cada uno de ellos.

Salesforce aprovechó esta nueva funcionalidad añadiéndole algunas funcionalidades más potentes, que no estaban disponibles en las Workflow Rules, tentando así a los desarrolladores a moverse a esta nueva herramienta.

Pero los Process Builder no eran perfectos, se requería una herramienta más potente, sin las muchas limitaciones que ofrecía, y con la facilidad suficiente como para ser usado por alguien sin conocimientos de desarrollo (¿recuerdas que es uno de los objetivos de Salesforce?).

¿Conoces los Flows?

Process Builder es útil para los procesos de negocio más frecuentes, con una lógica no muy compleja. Su forma de ejecutar los nodos es secuencial: en caso de que se cumpla una condición, se desencadena una acción. Pero… ¿qué pasa si hay más opciones que un simple true/false? ¿O si se ha de repetir las acciones en un bucle, hasta que el proceso acabe?

Y llegaron los Flows. Y las posibilidades de creación de procesos automáticos se disparó. ¿En qué sentido? En todo aquello que ahora sí es posible:

  • Entorno completamente gráfico donde definir los flujos
  • Lógicas complejas de selección de caminos
  • Interacciones
  • Creación de constantes y variables que usar durante el flujo
  • Recuperación de registros, sobre los que operar durante el flujo
  • Inserciones, modificaciones ¡y borrados! de registros
  • Integraciones con sistemas externos
  • Distintos tipos de Flows
  • ¡Y más cosas!

¿Hemos dicho “distintos tipos de Flows”? Así es. Ya no hablamos tan solo de una herramienta dedicada a procesos automáticos en el back office, sino que, como parte del proceso, ahora es posible mostrar pantallas al usuario, para recabar información de él, o para mostrarle información sobre la ejecución.

Conclusión

Miles de posibilidades se abren a través de Flows para el desarrollo de procesos automáticos en Salesforce, más teniendo en cuenta que, en cada versión, se están añadiendo más y más funcionalidades.

Y nosotros, ¿qué debiéramos hacer?  Tanto los Workflow Rules como los Process Builder pasarán a estar obsoletos en la versión Winter’23, en favor de los Flows. Por tanto, los nuevos desarrollos debiéramos hacerlos ya sobre esta herramienta.

¿Y los que ya están implementados? Bien, en este caso, Salesforce ha puesto a nuestro alcance una función de migración, que convertirá estos procesos antiguos al nuevo sistema de Flows.

Sea como sea, los Flows han llegado para quedarse. Te animo a que busques algo de documentación, un buen tutorial, y te pongas a ello… ¡Un nuevo mundo te aguarda!

Ejemplo de un Flow, con su sencillez para definir los pasos y el orden de ejecución de un proceso

 

Autor del artículo

Ángel Granero Alonso, solution lead de Consultoría Tecnológica de Deloitte