Modela los tipos de registro con los que realmente funciona tu negocio.
Define tus propios tipos de objeto —pólizas, solicitudes, eventos, subvenciones, lo que sea que tu negocio rastree— con campos tipados, y obtén gratis una interfaz y una API completas de crear/leer/actualizar/eliminar.
Las entidades integradas del CRM (contactos, prospectos, oportunidades, cuentas, tareas) no encajan en todos los negocios. Los objetos personalizados permiten que un inquilino defina sus propios tipos de registro de primera clase, cada uno con un conjunto de campos tipados, y obtenga de inmediato listado, detalle, creación, edición y eliminación para los registros de ese tipo —en la interfaz y a través de la API— sin ningún código ni migración de esquema. Es lo que permite que una aseguradora modele pólizas, una escuela modele solicitudes o una iglesia modele eventos de forma nativa dentro del mismo CRM.
Define un tipo de objeto
Un gerente (o superior) define un tipo con una clave, una etiqueta singular y una plural, un icono opcional y una lista de campos. Cada campo tiene una clave, una etiqueta, un tipo y si es obligatorio.
- Los tipos de campo se validan del lado del servidor contra un conjunto fijo de tipos soportados (texto, número, fecha, selección y más)
- Los campos de selección llevan su propia lista de opciones permitidas
- Las claves de tipo se normalizan (minúsculas, espacios a guiones bajos) y deben ser únicas por inquilino
- Actualizar los campos de un tipo es una acción de nivel de gestión: la lista de campos puede evolucionar sin perder los registros existentes
Registros, formularios y tablas generados
Una vez que existe un tipo, su página de registros renderiza un formulario de creación y una tabla de datos generados directamente a partir de las definiciones de campo del tipo: agrega un campo al tipo y aparece como columna y como campo del formulario automáticamente, sin cambios de front-end.
- Los registros llevan un nombre más una carga de datos flexible indexada por clave de campo
- Los registros pueden enlazar opcionalmente a un contact_id y/o account_id, atando los datos personalizados de vuelta al grafo central del CRM
- Cada registro es propiedad del usuario que lo creó
CRUD completo, de principio a fin
Los objetos personalizados no son un complemento de solo lectura: tanto los tipos como los registros admiten crear, leer, actualizar y eliminar, cada uno produciendo una entrada de registro de auditoría (object_type.created/updated/deleted, object.<key>.created/updated/deleted) para que los cambios sean rastreables por inquilino.
Datos validados, registros paginados
Las cargas de datos de los registros se validan contra las definiciones de campo del tipo en cada escritura: los campos obligatorios se exigen al crear, y las actualizaciones se fusionan contra la carga existente en lugar de reemplazarla por completo. Los listados de registros están paginados (predeterminado 50, hasta 200 por página) con encabezados de respuesta de recuento total y de si hay más.
- Una agencia de seguros que rastrea Pólizas con campos de prima, aseguradora y fecha de renovación
- Una escuela que rastrea Solicitudes con campos de programa, estado de decisión y fecha de entrevista
- Una organización sin fines de lucro que rastrea Subvenciones o Eventos distintos de sus registros de donantes/contactos
- Cualquier equipo que haya superado una hoja de cálculo para un tipo de registro que el CRM central no modela
Objetos personalizados — preguntas comunes
No: definir un tipo (su etiqueta, icono y campos) es una acción de nivel de gerente en el producto, no un cambio de código ni una migración de base de datos.
Texto, número, fecha y selección (con una lista de opciones definida) se admiten hoy; el tipo de campo se valida contra el conjunto permitido de la plataforma cada vez que se crea o actualiza un tipo.
Sí: cada registro puede referenciar opcionalmente un contact_id y/o account_id, así que los datos personalizados se mantienen conectados a las personas y empresas que ya rastreas.
Los registros existentes conservan su carga de datos almacenada; el formulario y la tabla generados de la interfaz reflejan la lista de campos actual, y las actualizaciones fusionan los nuevos valores en los datos existentes de cada registro.
Forman parte de los planes Pro y Enterprise. Son accesibles a través de la misma API /v1/objects que usa la interfaz, así que son automatizables y reportables junto con las entidades integradas.