Por qué un Flow que funciona tumba la org después?

Porque corre de más (sin entry conditions), hace DML adentro del loop o consulta más de 50.000 registros. En una org chica no se nota. Cuando crece el volumen, pincha el CPU time.

Qué son los governor limits, en simple?

Salesforce es un edificio de departamentos. Cada org comparte recursos. Hay techos de tiempo, queries y trabajos asíncronos para que un mal desarrollo no deje al vecino afuera. Si se pasan, pueden bloquear transacciones una hora o 24 horas.

Cómo se diagnostica un CPU Time Limit?

Con Log Analyzer en Visual Studio Code: arma un call tree del log, marca en rojo dónde pinchó y muestra cuánto CPU y cuántas queries consume cada parte. Scale Center mide si la org está lenta de verdad en horario pico.

Conviene un objeto join si todas las promos van a todas las cuentas?

No. Un millón de cuentas por 20 promos son 20 millones de registros a 2K cada uno. Mejor niveles, y el cruce solo cuando importe el uso.

Qué hacer con data vieja para no inflar el storage?

Big Objects (sin Flow ni trigger), export a una base externa con External Objects, o consolidar (un registro mensual en lugar de miles). Y no borren producción sin backup y un correo de quien lo pide.

Rendimiento Salesforce: el Flow que anda y tumba la org

Seguridad y gobernanza en Salesforce: cómo dar acceso sin perder el control

Experience Cloud con React: portales Salesforce multi-framework (más allá de Aura)

Claudeforce: Salesforce se mete en Claude (y Claude se queda a vivir en el CRM)