¿Por qué la deuda técnica en automatizaciones es diferente de la deuda técnica regular?
En Salesforce, es más fácil acumular deuda técnica que en un entorno de desarrollo regular, ya que la herramienta permite a cualquiera añadir automatizaciones sin pasar por un proceso de código estructurado. Cada administrador que añade un Flow Before Save para resolver un problema puntual, cada Trigger que alguien añadió hace dos años y nadie recuerda por qué, y cada campo de fórmula que contiene una dependencia de otro campo que ya no existe, todo esto se acumula en una capa que nadie ve en su totalidad.
La diferencia fundamental entre la deuda técnica regular y la deuda técnica en las automatizaciones de Salesforce es que esta última casi siempre carece de documentación centralizada. El código reside en un repositorio con un historial de Commits; un Flow reside en Setup sin una explicación de su origen. Esto hace que la fase de identificación sea especialmente difícil, no porque el problema sea técnicamente complejo, sino porque no hay a quién preguntar.
Este artículo aborda la identificación, medición y reducción de esta deuda. No discute cuándo elegir Flow y cuándo Apex desde el principio; para eso se dedica Flow vs. Apex: cómo elegir.
Tres tipos de deuda que se comportan de manera diferente
No toda la deuda técnica es igual, y tratarla toda como el mismo problema lleva a un desperdicio de esfuerzo. Conviene separarla en tres categorías:
| Tipo de deuda | Ejemplo típico | ¿Qué sucede si se ignora? | Prioridad de tratamiento |
|---|---|---|---|
| Deuda estructural | Varios Triggers en el mismo objeto sin un Framework unificador | Orden de ejecución impredecible, falla silenciosa | Alta |
| Deuda lógica | Flow con decenas de ramas de decisión que representan una regla de negocio ya modificada | Decisiones erróneas que se ejecutan silenciosamente | Alta |
| Deuda de mantenimiento | Campos, Flows y variables permanentes sin documentación o uso | Aumento del tiempo de desarrollo, miedo a realizar cambios | Media |
La deuda estructural y la deuda lógica generan un riesgo operativo real; pueden causar datos incorrectos que llegan al cliente o a un informe financiero. La deuda de mantenimiento ralentiza al equipo, pero no necesariamente interrumpe un proceso. Esta clasificación determina el orden de tratamiento: primero se elimina el riesgo operativo, luego se mejora la velocidad de desarrollo.
Cómo identificar la deuda antes de que explote en producción
La identificación no debe comenzar con una revisión manual exhaustiva del código; eso es demasiado caro e insostenible. Comienza con algunas métricas cuantitativas que se pueden obtener en una hora:
- Número de Flows activos en cada objeto central (Lead, Opportunity, Case, etc.). Más de cinco o seis Flows activos en el mismo objeto dificulta la predicción del orden de ejecución.
- Número de Triggers no unificados bajo un mismo Framework por cada objeto. Más de un Trigger por objeto ya es una señal de advertencia, a menos que exista una capa de enrutamiento explícita.
- Densidad de consultas SOQL dentro de bucles que aparece en los registros como un Governor Limit cercano al umbral, aunque no se haya superado en la práctica.
- Tiempo de ejecución inusual de Flow o Apex Batch que aumenta con el tiempo sin que el volumen de negocio crezca en la misma proporción.
- Campos y variables sin uso identificado en el informe de Uso de Campos, que permanecen "por si alguien los necesita".
Estas métricas no demuestran un problema inequívoco, pero proporcionan una lista de sospechosos enfocada. La combinación de estas métricas con una profunda comprensión de las integraciones de las que depende la automatización se detalla en Patrones de integración de Salesforce.
Marco de decisión: qué abordar primero
No todos los hallazgos en la lista de sospechosos merecen la misma inversión. Un Framework simple para la priorización se basa en dos ejes: impacto comercial y probabilidad de falla:
| Situación | Impacto comercial si falla | Probabilidad de falla a corto plazo | Acción |
|---|---|---|---|
| Automatización en el proceso de pedido/facturación con múltiples Triggers no documentados | Alta | Alta | Refactorización inmediata, fuera de la cola normal |
| Flow complejo en la actualización de estado interno sin impacto externo | Baja | Alta | Documentación y simplificación a ritmo normal |
| Trigger antiguo que funciona estable pero no está claro por qué existe | Potencialmente alta | Baja | Documentación primero, no intervención inmediata |
| Campos no utilizados y variables permanentes huérfanas | Baja | Baja | Limpieza cíclica a nivel de Release |
La regla general es: no se aborda lo que más molesta a los desarrolladores, sino lo que es más peligroso para el negocio. Un Trigger antiguo y estable que nadie entiende es a veces el caso más tentador para intervenir primero, y ese es precisamente el caso en el que una intervención descuidada provoca el mayor daño.
Escenario organizacional: una compañía de seguros con 14 Flows en Opportunity
Supongamos una compañía de seguros mediana que ha gestionado ventas B2B a través de Salesforce durante seis años. Con el tiempo, se han acumulado 14 Flows activos en el objeto Opportunity: siete manejan actualizaciones de etapa, tres envían alertas internas, dos sincronizan datos con una herramienta externa de BI, y otros dos son restos de un proceso antiguo que fue reemplazado hace dos años pero nunca fue desactivado.
El detonante para identificar el problema fue una falla concreta: una transacción pasó a la etapa "Cerrada-Ganada" pero la alerta al equipo de suscripción no se envió, porque otro Flow actualizó el mismo campo en paralelo y creó un orden de ejecución no previsto. El equipo pasó dos días intentando entender por qué, no porque el error fuera complicado, sino porque nadie conocía el orden de ejecución completo de los 14 componentes.
El tratamiento no fue "reescribir todo en Apex". El equipo primero mapeó los 14 Flows y los clasificó según la tabla anterior: los dos Flows antiguos se desactivaron después de verificar que no había dependencias activas, las tres alertas se unificaron en un solo Flow con una lógica de enrutamiento clara, y las siete actualizaciones de etapa se unificaron bajo un único Record-Triggered Flow con un orden de ejecución explícito. Resultado: de 14 componentes a 6, con un orden de ejecución documentado que cualquier nuevo desarrollador puede leer en quince minutos.
Riesgos en el propio proceso de reducción
La reducción de la deuda técnica es una acción con sus propios riesgos, no solo una corrección de un riesgo existente:
| Riesgo | Cómo se manifiesta en la práctica | Acción preventiva |
|---|---|---|
| Cambio en el orden de ejecución que rompe una dependencia oculta | Proceso que funcionaba deja de funcionar después de la unificación de Flows | Mapeo completo de dependencias y pruebas de regresión antes de cualquier unificación |
| Eliminación de un componente "muerto" que en realidad sigue funcionando en un escenario raro | Falla que aparece solo al final de un trimestre o en un escenario extremo estacional | Revisar registros de ejecución durante un año completo, no solo el último mes |
| Conversión a Apex sin un propietario del proceso que comprenda la regla de negocio | El nuevo código es "técnicamente correcto" pero implementa una regla antigua que ya ha cambiado | Validar la regla de negocio con el propietario del proceso antes de escribir código, no solo con el código existente |
| Refactorización realizada en un Sandbox y no sincronizada | El problema reaparece en el entorno de producción después del siguiente Deploy | Gestionar el cambio a través de un proceso de Release regular y no como una corrección "fuera de la cola" |
El riesgo común a todos ellos es el mismo fenómeno: el equipo está seguro de que "solo está limpiando" y, por lo tanto, omite las pruebas que habría realizado para una nueva funcionalidad. A nivel de Gobernanza, la refactorización debe pasar por el mismo proceso de aceptación que el desarrollo regular, no menos.
Métricas para el seguimiento continuo de la reducción
Para saber que el esfuerzo realmente reduce la deuda y no solo la desplaza, conviene seguir:
- Número de componentes de automatización activos por objeto, como una métrica de tendencia trimestral y no puntual.
- Tiempo promedio para diagnosticar un error de automatización, desde el momento del informe hasta la identificación del componente responsable.
- Porcentaje de componentes documentados del total de automatizaciones activas en el clúster central.
- Número de errores recurrentes en el mismo componente en un período de tres meses.
Las organizaciones que tienen dificultades para priorizar entre la refactorización y el desarrollo continuo utilizan el servicio de arquitectura CRM para construir un plan de trabajo vinculante y medible.
Checklist operativo antes de iniciar la refactorización
- ☐ Existe un mapa completo de todas las automatizaciones activas en el objeto relevante
- ☐ Se conoce el orden de ejecución real, no solo por el orden de creación
- ☐ Cada componente destinado a la eliminación ha sido revisado en los registros de ejecución durante un año completo
- ☐ El propietario del proceso de negocio ha aprobado la regla que se vuelve a implementar
- ☐ Existe un entorno de pruebas que simula un volumen de datos real
- ☐ Se ha definido una métrica "antes y después" para el número de componentes y el tiempo de diagnóstico
- ☐ El proceso de refactorización pasa por un Release regular, no por un Deploy excepcional
- ☐ Se ha asignado una capacidad constante en cada Sprint para el tratamiento continuo, no solo un evento puntual
Resumen
La deuda técnica en las automatizaciones de Salesforce se acumula silenciosamente, componente por componente, y por lo tanto debe desmantelarse también silenciosamente, no en un gran proyecto de limpieza que detiene el desarrollo durante un mes. Las herramientas necesarias son relativamente simples: contar componentes por objeto, mapear el orden de ejecución y clasificar por impacto comercial vs. probabilidad de falla. Lo que determina el éxito es la continuidad: asignar una capacidad constante para reducir la deuda junto con el desarrollo continuo, y no perseguir puntualmente el componente que causó la última falla. Una organización que adopta este hábito de medición llega a un punto en el que cualquier nuevo desarrollador puede entender en una hora qué sucede al guardar un registro, y eso, en última instancia, es la definición más práctica de la ausencia de deuda técnica.