Objeto (Salesforce)

Un objeto de Salesforce es la unidad básica con la que la plataforma organiza la información: equivale a una tabla de base de datos donde cada fila es un registro y cada columna es un campo. Por ejemplo, el objeto Cuenta guarda empresas, el objeto Contacto guarda personas y el objeto Oportunidad guarda negocios en curso. Cada registro de un objeto tiene un identificador único de 15 o 18 caracteres (el Id) con el que Salesforce lo referencia internamente.

Salesforce distingue dos grandes familias. Los objetos estándar vienen incluidos de fábrica (Account, Contact, Lead, Opportunity, Case, entre otros) y son la base de productos como Salesforce. Los objetos personalizados los crea cada empresa para modelar datos propios que no encajan en los estándar (por ejemplo, "Póliza", "Embarque" o "Suscripción"), y se reconocen por el sufijo `__c` en su nombre de API.

Sobre cada objeto se apoyan los campos, las relaciones con otros objetos, las reglas de validación, los layouts de página y los permisos. Por eso entender el modelo de objetos es el primer paso para diseñar bien cualquier implementación.

Cómo se estructura un objeto

Cada objeto reúne varias piezas que conviene conocer. Los campos son las columnas que guardan datos de cada registro (texto, número, fecha, picklist, fórmula). Las relaciones conectan objetos entre sí: una relación lookup vincula dos registros de forma flexible, mientras que una relación master-detail ata el registro hijo al padre (si se borra el padre se borran los hijos, y el hijo hereda permisos y propiedad). Además, cada objeto tiene page layouts que definen cómo se ve el formulario, record types para tener variantes del mismo objeto según el proceso, y un conjunto de permisos que controla quién lo ve y lo edita.

Un detalle clave para quien recién arranca es el nombre de API. Los objetos estándar usan su nombre directo (`Account`, `Opportunity`), pero los personalizados llevan el sufijo `__c` (por ejemplo `Embarque__c`) y sus campos personalizados también (`Numero_Tracking__c`). Ese nombre de API es el que se usa en consultas SOQL, en código Apex, en Flow y en la API de integración.

Objeto estándar vs objeto personalizado

La diferencia práctica entre ambos tipos se resume así:

La recomendación general es reutilizar el objeto estándar siempre que el dato encaje (una empresa va en Account, una persona en Contact) y solo crear objetos personalizados para lo que la plataforma no contempla. Forzar datos en el objeto equivocado complica los reportes y las automatizaciones más adelante.

Por qué importa para el negocio

El modelo de objetos no es un tecnicismo aislado: determina qué se puede medir, automatizar y reportar. Una mala decisión de modelado (campos sueltos, objetos duplicados, relaciones mal armadas) se arrastra durante años y encarece cada cambio. Un modelo limpio, en cambio, se convierte en una única fuente de verdad sobre la que se construyen tableros y procesos confiables.

Ejemplo concreto

Pensá en una empresa de Consumo Masivo que vende a supermercados. El objeto Cuenta guarda cada cadena, el objeto Contacto a los compradores, el objeto Oportunidad a cada negociación de listado de productos, y un objeto personalizado Visita__c registra cada relevamiento de perfect store en el punto de venta. Con todo relacionado entre sí, esa estructura permite responder preguntas como "¿qué cuentas no recibieron visita este mes?" con un simple reporte.

Errores comunes

• Crear un objeto personalizado nuevo cuando el dato encajaba en uno estándar, duplicando información.
• Guardar varios conceptos distintos en un mismo objeto con un campo "tipo" en lugar de record types o de objetos separados.
• Abusar de las relaciones master-detail cuando alcanzaba un lookup, perdiendo flexibilidad.
• Ignorar los governor limits y los límites de cantidad de campos al sobrecargar un objeto.

Entender bien qué es un objeto y cuándo conviene cada tipo es la base de cualquier proyecto serio sobre la plataforma, desde un CRM de ventas hasta una integración de datos a gran escala.