Entidades

Las entidades son los tipos de objeto de tu CRM (Cuentas, Contactos, Oportunidades, Casos, Tareas, o lo que tu negocio necesite). Cada entidad define qué campos tiene, cómo se lista, cómo se ve un registro y quién lo puede ver. Esta página es para quien administra el modelo de datos; necesitás el permiso configure_entities.

Todo se hace desde Configuración → Constructor de app → Entidades.

Entidades standard

Cada workspace nuevo arranca con cinco entidades que cubren lo típico de un CRM:

Entidad	Campo principal	Vista por defecto	Para qué sirve
Cuentas	Nombre	Lista	Empresas u organizaciones
Contactos	Nombre	Lista	Personas, asociadas a una cuenta
Oportunidades	Nombre	Kanban por etapa	Negocios potenciales, con monto y probabilidad
Casos	Asunto	Lista	Tickets de soporte, con estado y prioridad
Tareas	Asunto	Lista	Actividades y pendientes, con fecha de vencimiento

⚠️ Se crean con las etiquetas en inglés (Account / Accounts, Contact, Opportunity, Case, Task, y los campos “Name”, “Industry”, “Full Name”…) aunque el workspace esté en español: la tabla usa los nombres en castellano para que se entienda, pero en la barra lateral vas a ver Accounts, Contacts, etc. Para traducirlas, editá el Label y el plural de cada entidad (pestaña General) y la etiqueta de cada campo; el nombre de API (account, contact…) no cambia.

Las podés editar como a cualquier otra (agregar campos, cambiar opciones de los picklists, rediseñar páginas) y no cuentan contra el límite de entidades de tu plan. Las Notas también son una entidad del sistema, pero se administran desde cualquier registro, no desde acá (ver Notas).

Crear una entidad

Nueva entidad

En Configuración → Constructor de app → Entidades, botón Nuevo.

Nombre y etiquetas

Label y plural: lo que ven los usuarios (“Propiedad” / “Propiedades”).
Name (nombre de API): identificador técnico en minúsculas (property), sugerido desde el label sin acentos (“Trámite” → tramite). Se usa en URLs, automations y la API, y no se puede cambiar después.

El asistente no pide ícono: se elige después en la pestaña General (Icon).

Campo principal

Es el campo que funciona como título de cada registro. Puede ser de texto (lo escribe el usuario) o autonumérico (el sistema asigna PROP-2026-0001 al crear; ver Tipos de campo → Autonumérico). Siempre es obligatorio.

Visibilidad por defecto

Elegís el Org-Wide Default de la entidad: si los registros son privados (solo el dueño y su jerarquía), de solo lectura para todos, o de lectura/escritura para todos. Se puede cambiar después y afinar con sharing rules — ver Sharing.

Permisos iniciales

Podés marcar de una a qué permission sets darle acceso (ver / crear / editar / eliminar). Si no, la entidad nace visible solo para quien tiene all_entity_access (el System Admin).

La entidad aparece de inmediato en la barra lateral con una list view All (se crea con ese nombre; podés renombrarla en List Views).

Configurar una entidad

Al abrir una entidad, la configuración está organizada en pestañas verticales:

Pestaña	Qué se configura
General	Label, plural, ícono, descripción, vista por defecto (lista o kanban), configuración del kanban (campo de columnas, monto, fecha, probabilidad, dueño) y formulario de creación (qué campos y en qué orden aparecen en ”+ Nuevo”).
Campos	Los campos de la entidad: agregar, editar, eliminar. Ver Tipos de campo y validación. La columna Automático marca los campos que llena el sistema.
List Views	Vistas de lista con sus columnas. Cada entidad tiene al menos una (All en una entidad nueva); podés crear más (por ejemplo “Pipeline” con menos columnas). Los usuarios eligen la vista desde la lista.
Record Pages	Las páginas de detalle del registro: qué secciones tiene, en qué orden, quién ve cuál. Ver Record Pages.
Tipos de registro	Variantes de la entidad con su propia página y formulario. Ver Tipos de registro.
Layouts	Popover layouts: qué campos aparecen en la vista previa al pasar el mouse sobre un registro relacionado (ver abajo).
History Tracking	Qué campos registran historial de cambios (ver abajo).

Editar campos de una entidad con registros

Agregar un campo es seguro: los registros existentes lo muestran vacío. Cambiar el label o las opciones de un picklist también. Eliminar un campo no borra los datos que ya existen en los registros, pero dejan de verse y editarse.

Renombrar el valor interno de una opción de picklist afecta solo a los registros nuevos: los viejos conservan el valor anterior y dejan de matchear filtros y automations que usen el nuevo. Renombrar la etiqueta (lo que se muestra) es seguro. El editor distingue las dos cosas.

Campos que vienen de un paquete

Si instalaste un paquete (CPQ, Fundraising…), sus entidades traen campos con prefijo (cpq__status). Son campos administrados por el paquete: podés cambiarles el label, la descripción, las opciones del picklist (agregar valores, relabelar, recolorear) y si restringen valores, pero no su tipo, su relación ni si son obligatorios. Los valores que trae el paquete no se pueden borrar ni renombrar, porque el paquete los usa. Tus ediciones se conservan cuando el paquete se actualiza. Más en Paquetes.

Eliminar una entidad

General → Eliminar entidad. Antes de confirmar, el sistema te muestra el impacto: cuántos registros se van a borrar y qué otras piezas la referencian (por ejemplo, pestañas de la app). Se eliminan la entidad, todos sus registros, su historial y sus páginas. No se puede deshacer.

Límites

Límite	Valor
Entidades custom por workspace	Según el plan: 10 (Free), 25 (Starter), 100 (Professional), sin límite (Enterprise). Las standard no cuentan; las que instala un paquete sí.
Campos por entidad	200
Registros, usuarios, automations, almacenamiento	También por plan — se ven en Configuración → Espacio de trabajo → General → Plan y uso.

Un sandbox tiene límites más chicos (10 entidades, 1.000 registros, 2 usuarios). Ver Sandboxes.

History Tracking (historial de cambios)

En la pestaña History Tracking marcás qué campos registran cada cambio (valor anterior, valor nuevo, autor y momento). Es opt-in por campo: nada se trackea hasta que lo elegís.

Agregar campos abre un selector con los campos todavía no trackeados; Stop tracking lo saca.
Se registran las ediciones. La creación ya queda cubierta por “creado por / creado el”, y al borrar un registro se va su historial.
Para que los usuarios lo vean, agregá el componente Field History a la Record Page (ver Record Pages). Además necesitan el permiso view_field_history y acceso de lectura al registro.
El historial no se depura solo: elegí solo los campos que de verdad necesitás auditar.

Cómo se ve para el usuario: Registros → Historial de cambios.

Cuando alguien pasa el mouse sobre un campo de relación (el nombre de la cuenta dentro de un contacto), aparece una tarjeta con un resumen del registro relacionado. Qué campos muestra esa tarjeta lo define el popover layout de la entidad destino.

Configuración → Constructor de app → Entidades → (la entidad que se va a previsualizar) → Layouts.
Editá el layout Default o creá uno nuevo y marcalo como default.
Elegí los campos (de datos o de sistema: creado, modificado, dueño) y guardá.

Las entidades standard vienen con un popover layout default preconfigurado. Las relaciones se muestran con el nombre del registro relacionado; los campos de usuario, con el nombre de la persona.

Qué más configura una entidad

Quién ve qué registros (OWD, jerarquía de roles, sharing rules): Sharing.
Qué puede hacer cada permission set sobre la entidad y sobre cada campo: Usuarios y permisos.
Qué pasa cuando se guarda un registro (permisos → automations → validación → historial): Qué pasa al guardar un registro.