Flow
Automatización declarativa con estructura clara, nombres consistentes y documentación.
Desarrollo y Automatización
Flow o Apex — Una decisión razonada, no una costumbre.
Construcción de automatizaciones y desarrollos en Salesforce con una elección consciente entre declarativo y código, según la complejidad, el rendimiento y el coste de mantenimiento — incluyendo pruebas, control de versiones y reducción de la deuda técnica.
Mapa de capacidades
Qué se incluye y en qué orden
El mapa muestra las capas de trabajo de este servicio, desde la infraestructura hasta las capacidades que ven los usuarios.
Desarrollo y automatización — Mapa de Capacidades
Flow
Automatización declarativa con estructura clara, nombres consistentes y documentación.
Apex
Lógica compleja, grandes volúmenes y pruebas unitarias reales.
LWC
Interfaces dedicadas que agilizan el trabajo diario.
Platform Events
Separación de sistemas mediante eventos en lugar de llamadas directas.
Pruebas y calidad
Cobertura de pruebas significativa y no formal, y revisión de código.
Control de versiones
Sandboxes, lanzamiento controlado y documentación de cambios.
El contexto
Qué decide realmente aquí
La mayor parte de la deuda técnica en Salesforce no proviene de un código deficiente, sino de la multiplicidad de automatizaciones construidas por separado sobre el mismo objeto, sin nadie que vea el panorama completo.
La regla práctica es simple: lo que se puede resolver de forma declarativa y clara, se construirá así. Lo que requiere lógica compleja, alto volumen o control preciso del orden de las operaciones, se justifica con código, con pruebas.
Toda automatización necesita un propietario y documentación. Una automatización de la que nadie sabe por qué se construyó permanecerá en el sistema durante años y romperá cosas en silencio.
Áreas de trabajo
Lo que hacemos en la práctica
Apex
Lógica compleja, grandes volúmenes y pruebas unitarias reales.
LWC
Interfaces dedicadas que agilizan el trabajo diario.
Platform Events
Separación de sistemas mediante eventos en lugar de llamadas directas.
Pruebas y calidad
Cobertura de pruebas significativa y no formal, y revisión de código.
Control de versiones
Sandboxes, lanzamiento controlado y documentación de cambios.
Matriz de decisión
Las decisiones que determinan el resultado
| Requisito | Declarativo | Código | Lo que decide |
|---|---|---|---|
| Actualizar campos y condiciones | Flow | — | Simplicidad y mantenimiento |
| Lógica con muchas excepciones | Difícil de mantener | Apex | Número de condiciones y llamadas |
| Gran volumen de registros | Puede encontrar limitaciones | Apex optimizado | Volumen de procesamiento |
| Interfaz dedicada | Página estándar | LWC | Complejidad de la interacción |
| Publicación en varios sistemas | Conexiones directas | Platform Events | Número de consumidores y tolerancia a fallos |
Actualizar campos y condiciones
- Declarativo
- Flow
- Código
- —
- Lo que decide
- Simplicidad y mantenimiento
Lógica con muchas excepciones
- Declarativo
- Difícil de mantener
- Código
- Apex
- Lo que decide
- Número de condiciones y llamadas
Gran volumen de registros
- Declarativo
- Puede encontrar limitaciones
- Código
- Apex optimizado
- Lo que decide
- Volumen de procesamiento
Interfaz dedicada
- Declarativo
- Página estándar
- Código
- LWC
- Lo que decide
- Complejidad de la interacción
Publicación en varios sistemas
- Declarativo
- Conexiones directas
- Código
- Platform Events
- Lo que decide
- Número de consumidores y tolerancia a fallos
Forma de trabajo
Fases de ejecución
- 01
Mapeo de automatizaciones existentes
Qué se ejecuta en cada objeto y en qué orden.
- 02
Decisión de enfoque
Declarativo o código, con justificación documentada.
- 03
Construcción
Estándar de nomenclatura, modularidad y prevención de duplicidades.
- 04
Pruebas
Escenarios positivos y negativos, no solo cobertura.
- 05
Lanzamiento
Sandbox, revisión y ventana de lanzamiento definida.
- 06
Limpieza
Eliminación de automatizaciones innecesarias y reducción de deuda.
Continuar desde aquí
Servicios y guías relacionados
Preguntas frecuentes
Preguntas frecuentes
¿Es Flow siempre preferible a Apex?
No. Flow es preferible cuando la lógica es simple y clara, ya que su mantenimiento es económico y es accesible incluso para un Admin. Cuando se trata de lógica compleja, volúmenes altos o la necesidad de un control preciso sobre el orden de las operaciones, Apex con pruebas es la opción más segura.
¿Cuántas automatizaciones están permitidas en un objeto?
El número es menos importante que la transparencia. El problema comienza cuando nadie sabe qué se está ejecutando y en qué orden. Un estándar organizado y la documentación son más importantes que una regla estricta.
¿Qué se considera deuda técnica en este contexto?
Automatizaciones duplicadas, código sin pruebas, campos no utilizados, permisos demasiado amplios y lógica sin propietario. Todo esto aumenta el riesgo en cualquier cambio futuro.
¿Se necesita una herramienta de DevOps?
Cuando hay más de un desarrollador o un ritmo de lanzamiento regular, sí. En un entorno pequeño, un proceso de Sandbox ordenado y la documentación pueden ser suficientes en la etapa inicial.
El siguiente paso
Examen de la capa de automatización
Mapearemos lo que se está ejecutando hoy, identificaremos duplicidades y definiremos un estándar que se pueda mantener.