Soy Juan Manuel Garrido, fundador de EGA Futura y cofundador de Vantegrate. Después de muchos años trabajando con Salesforce, hay una escena que vemos una y otra vez: abrimos un objeto en producción y encontramos un Flow, un Process Builder, una Workflow Rule y otro Flow más. Todos sobre el mismo objeto, todos haciendo algo parecido, y cada uno dejado por una consultora o un administrador distinto.
La Salesforce Org no está rota. Funciona. Pero nadie se anima a tocarla. En esta guía explicamos por qué pasa, por qué hoy es urgente resolverlo y cómo ordenar las automatizaciones de un objeto paso a paso, sin romper producción.
Por qué una Salesforce Org termina con automatizaciones superpuestas
Casi nunca es un error de una sola persona. Es acumulación. Cada proyecto resolvió su necesidad con la herramienta disponible en ese momento: primero Workflow Rules, después Process Builder, más tarde Flow y, en algunos casos, triggers de Apex. Nadie documentó por qué se creó cada pieza y nadie apagó lo anterior.
El síntoma típico es que un pedido simple, como agregar un campo o cambiar una regla de aviso, se vuelve un proyecto. Antes de tocar nada hay que entender todo lo que se dispara cuando se guarda un registro. Y cuando automatizar da miedo, la automatización deja de ser una ventaja para tu empresa.
- Cada nueva capa suma complejidad.
- Cada parche heredado aumenta el riesgo de efectos inesperados.
- Cada cambio pequeño en producción exige horas de análisis.
El dato que vuelve esto urgente: fin del soporte de Workflow Rules y Process Builder
Salesforce dejó de dar soporte a Workflow Rules y Process Builder el 31 de diciembre de 2025. Según el artículo oficial de ayuda de Salesforce, esas automatizaciones siguen ejecutándose, pero ya no reciben soporte ni corrección de errores. La recomendación oficial es migrar a Flow Builder, y para eso existe la herramienta Migrate to Flow dentro de Setup.
En la práctica, si tu Org todavía depende de esas herramientas, hoy está ejecutando lógica de negocio sin red de seguridad. No hace falta entrar en pánico, pero sí conviene tener un plan.
Paso 1: inventario de automatizaciones por objeto
Antes de migrar, hay que saber qué existe. Recomendamos trabajar objeto por objeto, empezando por los de mayor volumen o mayor impacto comercial, como Oportunidad, Cuenta o Caso. Para cada uno, armamos una planilla simple con:
- Workflow Rules activas (en Setup se pueden filtrar por la columna Active).
- Procesos de Process Builder y su estado.
- Flows activados por registro, antes y después de guardar.
- Triggers de Apex sobre el objeto.
- Para cada pieza: qué hace, cuándo se dispara, qué campos actualiza y quién la pidió.
Esta planilla es la base de todo lo demás. Sin inventario, cualquier migración es una apuesta.
Paso 2: detectar superposiciones y conflictos
Con el inventario a la vista aparecen las sorpresas: dos automatizaciones que actualizan el mismo campo, emails duplicados, reglas que se contradicen. Aquí importa el orden de ejecución de Salesforce: cuando se guarda un registro, la plataforma ejecuta Flows antes de guardar, triggers, reglas de validación, Workflow Rules, procesos y Flows después de guardar en una secuencia definida. Dos piezas que tocan el mismo campo en momentos distintos pueden producir resultados que parecen aleatorios. Muchos errores que nadie logra reproducir nacen justamente ahí.
Paso 3: criterios para decidir qué se consolida y qué se apaga
No todo merece migrarse. Antes de convertir cada regla, conviene responder tres preguntas:
- El proceso de negocio que justificó esta regla sigue existiendo?
- Otra automatización ya hace lo mismo, o casi lo mismo?
- Esta lógica pertenece a un Flow, o es tan compleja que corresponde a Apex?
Preferimos apagar algo con criterio antes que trasladar la deuda técnica a un Flow nuevo. Migrar todo tal cual solo cambia el formato del problema.
Paso 4: usar Migrate to Flow sin piloto automático
Migrate to Flow convierte Workflow Rules y procesos en Flows, y los crea inactivos para que puedan probarse. Es un muy buen punto de partida. Su límite es que convierte cada automatización por separado. El verdadero valor está en consolidar: varias reglas sobre el mismo objeto suelen quedar mejor en pocos Flows bien diseñados, con entradas claras, que en un Flow por cada regla antigua.
Paso 5: probar en sandbox y activar en el orden correcto
Toda migración se prueba primero en sandbox, con casos reales: creación, edición, cambios masivos y cargas de datos. La secuencia en producción importa:
- Desplegar el Flow nuevo inactivo.
- Desactivar la Workflow Rule o el proceso antiguo.
- Activar el Flow y monitorear los primeros días.
Si se activan los dos al mismo tiempo, se duplica exactamente la lógica que se quería limpiar.
Paso 6: gobierno, documentación y responsables
El último paso es el que evita volver al punto de partida. Definimos nombres claros para cada Flow, una descripción que explique su propósito y un responsable por objeto. Además, acordamos con el equipo reglas de juego: qué se automatiza con Flow, cuándo hace falta Apex y quién aprueba cambios en producción. Sin este gobierno, dentro de dos años alguien vuelve a encontrar cinco capas sobre el mismo objeto.
Lo que hace buena a una implementación de Salesforce
Las mejores implementaciones no son las que más automatizaciones tienen. Son las que logran ser claras, mantenibles y predecibles. Una Org donde cualquier persona del equipo puede abrir un objeto y entender qué pasa al guardar un registro vale mucho más que una llena de soluciones ingeniosas que nadie se anima a tocar. Ese orden también es la base para sumar después procesos más avanzados, como agentes con Agentforce o integraciones con aplicaciones del AppExchange.
Si quieres fortalecer la base de tu equipo antes de migrar, en EGA Futura ofrecemos clases de Salesforce en vivo y gratis. Y si tu empresa gestiona su operación dentro de Salesforce, puedes conocer nuestro ERP para Salesforce, que funciona nativo en la plataforma.
Empieza hoy con el inventario del objeto que más te preocupa. Y cuéntanos: cuántas capas de automatización encontraste en el último objeto que abriste?