Objeto custom

El objeto custom es una tabla personalizada del modelo de datos de Salesforce que una empresa define para representar un concepto propio de su negocio que los objetos estándar (como Cuenta, Contacto u Oportunidad) no cubren. Se comporta igual que un objeto estándar: tiene sus campos, sus relaciones con otros objetos y sus permisos, pero modela algo específico, por ejemplo Póliza, Contrato o Ruta de reparto.

La analogía ayuda: si los objetos estándar son los cajones que ya vienen en el mueble, un objeto custom es un cajón nuevo con su etiqueta, sus divisiones y su cerradura. Definir bien estos objetos es parte del modelado de datos que sostiene toda implementación sobre Salesforce, porque sobre ese modelo se apoyan después la automatización, los reportes y la IA.

Un objeto custom existe porque ninguna plataforma puede traer de fábrica todos los conceptos que maneja cada negocio. Salesforce incluye objetos estándar listos para usar (Cuentas, Contactos, Oportunidades, Casos), pero cuando una empresa necesita registrar algo que esos objetos no contemplan, lo crea como objeto propio. A partir de ahí, ese objeto vive dentro de la org como una tabla más, con todas las capacidades de la plataforma.

Crear un objeto custom es una tarea declarativa: se hace desde la configuración de la plataforma (el Object Manager), sin escribir código, definiendo su nombre, su etiqueta y cómo se identifican los registros. Recién después se le agregan campos, relaciones y reglas de acceso. Esa naturaleza declarativa es lo que permite que un administrador, y no solo un programador, modele buena parte del negocio.

Los componentes de un objeto custom

Un objeto custom no es una tabla vacía: se arma con varias piezas que juntas forman el modelo.

• Campos custom: las columnas donde se guardan los datos, con su tipo (texto, número, fecha, lista de selección o fórmula).
• Relaciones: los vínculos con otros objetos, de tipo lookup (referencia suelta) o master-detail (dependencia fuerte), que arman el modelo de datos.
• Registros: cada fila, es decir cada instancia concreta del concepto que el objeto representa.
• Permisos y seguridad a nivel de campo: las reglas que definen quién puede ver y editar cada dato.

Por qué le importa a una empresa de LATAM

Modelar bien los datos es la base de todo lo demás: sin un buen modelo, la automatización, los reportes y la IA se construyen sobre arena. Un objeto custom bien diseñado evita forzar información en campos que no le corresponden y mantiene la data limpia y consultable. Las implementaciones sobre Salesforce trabajan dentro de la org del cliente, sobre su modelo real de datos, incluidos los objetos custom que representan su operación concreta.

Diferencias con términos vecinos

Conviene despejar tres confusiones habituales.

• Objeto custom vs objeto estándar: ambos se comportan igual (campos, relaciones, reportes, automatización), pero el estándar viene con la plataforma y el custom lo define la empresa.
• Objeto custom vs campo custom: el objeto es la tabla completa; el campo es una sola columna dentro de una tabla. Un objeto Póliza puede tener campos como prima, vencimiento y estado.
• Objeto custom vs registro: el objeto es la estructura; el registro es una fila concreta, una póliza puntual guardada dentro de ese objeto.

Cuántos objetos custom se pueden crear

La cantidad depende de la edición de Salesforce. Enterprise Edition permite hasta 200 objetos custom y Unlimited Edition hasta 2.000, con un tope duro de 3.000 por organización que no se puede elevar. El número rara vez es el problema real: el buen criterio es no crear un objeto para cada necesidad puntual, sino modelar los conceptos que de verdad estructuran el negocio.

Errores comunes

• Crear un objeto custom cuando alcanzaba con agregar campos a un objeto estándar existente.
• Elegir mal el tipo de relación (lookup cuando correspondía master-detail, o al revés) y romper la lógica de datos.
• No definir la seguridad a nivel de campo y terminar exponiendo datos sensibles.
• Duplicar objetos que representan lo mismo, generando data fragmentada y reportes que no cierran.

Sobre un objeto custom se puede automatizar con Flow o con Apex, reportar y hasta alimentar análisis, exactamente igual que con cualquier objeto estándar. Esa es la ventaja de modelar cada concepto en su propio objeto en lugar de improvisar con campos sueltos.