Governor limits

Los governor limits son los topes que Salesforce aplica a cada transacción de código y automatización para evitar que un proceso consuma más recursos de los que le corresponden. Como Salesforce es una plataforma multitenant (muchas organizaciones comparten la misma infraestructura), estos límites garantizan que el código de una empresa nunca degrade la performance de las demás. Son una de las primeras restricciones con las que se topa quien programa en Salesforce.

A diferencia de un servidor propio, donde podés consumir CPU o memoria hasta agotar la máquina, en Salesforce cada transacción arranca con un presupuesto fijo de recursos. Si tu código pasa ese presupuesto (por ejemplo, más de 100 consultas SOQL síncronas o más de 150 operaciones DML), la plataforma corta la ejecución y lanza una excepción que no se puede atrapar para ignorarla. El límite no es opcional ni configurable: es parte del contrato de la plataforma.

Por eso, en el mundo Salesforce, escribir buen código no es solo que funcione, sino que funcione dentro de los límites incluso cuando el volumen de datos crece. Diseñar pensando en governor limits es la diferencia entre una automatización que aguanta diez mil registros y una que explota al primer lote grande.

Por qué existen los governor limits

Salesforce no te da un servidor dedicado: tu organización vive sobre una infraestructura que comparte con miles de otros clientes. Ese modelo multitenant es lo que hace a la plataforma económica y escalable, pero introduce un riesgo: si una sola empresa pudiera ejecutar una consulta gigante o un bucle infinito, frenaría a todos los demás. Los governor limits son el mecanismo que reparte los recursos de forma justa. En esencia, son un presupuesto por transacción: cada vez que se ejecuta tu código (un trigger, un flujo, una llamada API), Salesforce mide cuántas consultas, registros, llamadas externas y tiempo de CPU consumís, y corta apenas superás el tope.

Los límites más importantes

Aunque hay decenas, en la práctica la mayoría de los problemas vienen de un puñado de límites por transacción. Estos son los que más se cruzan en proyectos reales:

• Consultas SOQL: 100 en contexto síncrono, 200 en asíncrono. Cada vez que pedís datos a la base contás una consulta.
• Registros recuperados por SOQL: hasta 50.000 en total dentro de la transacción.
• Operaciones DML: 150 sentencias (insert, update, delete) por transacción.
• Registros procesados por DML: 10.000 en total.
• Tiempo de CPU: 10.000 milisegundos en síncrono (lo que más sorprende, porque la lógica pesada lo agota rápido).
• Llamadas a servicios externos (callouts): 100 por transacción, con un tope de tiempo total.
• Heap (memoria): 6 MB en síncrono, 12 MB en asíncrono.

Bulkification: la regla de oro

El error más común de quien recién programa en Salesforce es escribir código que hace una consulta o un DML dentro de un bucle. Si procesás 200 registros y consultás la base una vez por cada uno, llegás a 200 consultas y te pasás del límite de 100. La solución, llamada bulkification, es sacar las consultas y los DML fuera del bucle: una sola consulta que trae todo lo que necesitás de golpe, y una sola operación DML que escribe la lista completa. Bien diseñado, un trigger que procesa 1 registro o 200 consume exactamente la misma cantidad de consultas. Esta práctica no es opcional: es la forma correcta de escribir en la plataforma.

Ejemplo concreto (Argentina)

Pensá en una distribuidora de Consumo Masivo que importa 5.000 pedidos por noche desde su sistema legacy a Salesforce. Un trigger sobre Pedido recalcula el saldo de la cuenta del cliente cada vez que entra un registro. Si ese trigger consulta la cuenta uno por uno, al procesar el lote de 5.000 supera el límite de consultas y la integración entera falla a las 3 de la mañana, dejando datos a medias. Reescrito con bulkification (una consulta que trae todas las cuentas afectadas y un único update masivo), el mismo proceso corre sin acercarse a ningún tope. Es el caso típico donde la diferencia entre saber y no saber de governor limits cuesta una madrugada de incidentes.

Errores comunes

• Hacer SOQL o DML dentro de un for (la causa número uno de límites superados).
• Probar con 1 o 2 registros y asumir que escala: los límites solo aparecen con volumen.
• Cadenas de automatizaciones (un flujo que dispara un trigger que dispara otro flujo) que suman CPU y DML sin que nadie las vea juntas.
• Recursión sin control: un update que se dispara a sí mismo y consume el presupuesto.

Governor limits vs multitenant

La gente suele confundir el límite con la arquitectura que lo justifica. No son lo mismo:

En resumen, multitenant es la causa y governor limits es la consecuencia: como compartís infraestructura, la plataforma necesita límites para que el reparto sea justo. Entenderlo cambia la forma de diseñar: en Salesforce no programás contra una máquina, programás contra un presupuesto, y respetarlo es la base de toda integración o automatización que aspire a aguantar volumen real.