Apex

Apex es el lenguaje de programación propietario de Salesforce, orientado a objetos y de sintaxis parecida a Java, que corre en los servidores de Salesforce (no en el navegador del usuario). Sirve para agregar lógica de negocio personalizada cuando las herramientas declarativas como Flow ya no alcanzan: validaciones complejas, integraciones, procesos por lotes y servicios que exponen datos.

A diferencia de un lenguaje de propósito general, Apex está fuertemente acoplado a la plataforma: tiene acceso directo a la base de datos vía SOQL y operaciones DML (insert, update, delete) sobre los objetos de Salesforce, y se ejecuta en un entorno multitenant compartido por miles de clientes. Por eso Salesforce impone límites estrictos de recursos (los governor limits): cuántas consultas, cuántos registros y cuánta CPU puede consumir cada transacción. Escribir y mantener Apex es una de las tareas centrales del rol de desarrollador Salesforce.

Por qué existe Apex y cuándo se usa

Salesforce ofrece dos caminos para personalizar una org: el declarativo (configurar con clics, sin escribir código) y el programático (escribir código). La mayoría de las automatizaciones simples se resuelven hoy con herramientas declarativas como Flow. Apex entra cuando el requerimiento supera lo que esas herramientas pueden expresar: lógica condicional muy ramificada, llamadas a sistemas externos, procesamiento de grandes volúmenes de registros en segundo plano o servicios que otras aplicaciones consumen.

Un caso típico en una empresa argentina: una distribuidora que quiere recalcular automáticamente la prioridad de cada oportunidad según el monto, la antigüedad de la cuenta y el saldo de cobranza traído de su ERP. Esa combinación de reglas y la llamada al sistema externo se programan en Apex, que corre del lado del servidor y deja el resultado escrito en el registro.

Cómo se ejecuta: triggers, clases y contexto

El código Apex vive en dos formas principales. Los triggers son piezas que se disparan automáticamente cuando un registro se crea, modifica o borra (por ejemplo, recalcular un total cada vez que se guarda una factura). Las clases agrupan métodos reutilizables que se invocan desde triggers, desde botones, desde Flow o desde un endpoint expuesto como API.

Una regla cultural de Apex es que el código debe estar bulkificado: pensado para procesar muchos registros a la vez, no de a uno. Si un trigger hace una consulta a la base por cada registro de un lote de 200, choca contra los governor limits y la transacción falla. El patrón correcto es consultar una sola vez fuera del bucle y operar sobre la colección completa.

Governor limits: la restricción que define el estilo

Como Apex corre en un entorno multitenant (la infraestructura es compartida por todos los clientes de Salesforce), ningún código puede acaparar recursos y afectar a los vecinos. Salesforce hace cumplir esto con límites por transacción que conviene tener presentes:

• Hasta 100 consultas SOQL por transacción síncrona.
• Hasta 150 operaciones DML (insert/update/delete) por transacción.
• 50.000 registros recuperables por transacción.
• 10 segundos de tiempo de CPU en transacciones síncronas.
• Cobertura de tests obligatoria del 75% para poder desplegar a producción.

Ese último punto es distintivo: Salesforce no deja subir código a producción si las pruebas unitarias no cubren al menos tres cuartas partes del código. Es una garantía de calidad poco común en otras plataformas.

Apex frente a otras opciones de la plataforma

La duda recurrente del negocio es cuándo conviene programar y cuándo configurar. Esta comparación resume el criterio:

La buena práctica vigente es declarativo primero, Apex cuando hace falta: resolver con Flow todo lo que se pueda y reservar el código para lo que realmente lo justifica. Esto reduce la deuda técnica y mantiene la org más fácil de mantener.

Errores comunes

El error más caro es escribir Apex sin bulkificar, lo que funciona en pruebas con un registro pero explota contra los governor limits en producción cuando entra un lote real. Otros tropiezos frecuentes: poner llamadas a sistemas externos dentro de un bucle, descuidar el manejo de excepciones, y escribir tests que solo buscan llegar al 75% de cobertura en vez de verificar que la lógica realmente funciona. Un buen test valida comportamiento, no solo cobertura.

Para interfaces de usuario modernas, Apex suele trabajar de la mano con los Lightning Web Components: el componente corre en el navegador y llama a métodos Apex del servidor para leer o escribir datos. Esa división (lógica de negocio y datos en Apex, presentación en el frontend) es el modelo de desarrollo estándar de la plataforma hoy.