---
title: "¿Cómo modela algo para lo que su CRM no tiene un objeto?"
blueprint: 003
slug: where-should-this-data-live
category: Modelo de datos
published: 2026-09-23
revised: 2026-09-23
platform: Coevera CRM (formerly Pipeliner CRM)
canonical: https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/
language: es
translation_of: https://blueprints.coevera.com/blueprints/where-should-this-data-live/
author: Lucia Schmidt
publisher: Coevera
customer_data: none
---

# ¿Cómo modela algo para lo que su CRM no tiene un objeto?

**Respuesta corta.** No empiece modelando. Empiece clasificando cada requisito en uno de **seis
veredictos**: ya **activo** en el espacio · una funcionalidad incluida pero **desactivada** ·
alcanzable mediante **configuración** · un **desarrollo** real · un **límite** rígido de la
plataforma que hay que replantear · o, directamente, **no es un problema de producto**. Solo el
cuarto es un ejercicio de modelado de datos.

Cuando *sí* es un desarrollo, hay que elegir entre una **entidad personalizada** (con su propio
endpoint de API, formularios, numeración por secuencia y funcionalidades de registro), **campos
adicionales en una entidad estándar existente** o un **registro hijo relacionado**. La prueba es
si la cosa tiene su propio ciclo de vida y se lista de forma independiente.

## 01 · El problema de negocio

Una organización llega con una lista. Se había entrevistado por separado a seis departamentos, y
entre todos produjeron unas **44 solicitudes distintas** de cosas que debería hacer el CRM: hacer
seguimiento de inspecciones in situ, asociar permisos a activos, registrar a quién se invitó a un
evento frente a quién asistió realmente, mostrar sugerencias a los gestores de cuentas, organizar
cuestionarios de incorporación, elaborar informes por región.

Cada solicitud llegó formulada como una solución y no como un problema («necesitamos un mosaico en
el panel», «necesitamos un módulo nuevo para permisos»), porque así es como la gente describe lo
que quiere. Y el instinto a ambos lados de la mesa es tomar la lista al pie de la letra y empezar
a diseñar objetos para ella.

Ese instinto resulta caro de una forma concreta. Convierte un ejercicio de análisis en un
presupuesto de desarrollo, y lo hace antes de que nadie haya establecido cuáles de las 44 cosas ya
hace la plataforma.

## 02 · Por qué falla el enfoque obvio

### Una gran parte de las solicitudes no son desarrollos

> **De unas 44 solicitudes, 11 correspondían a funcionalidades que estaban presentes y con
> licencia en el propio espacio del cliente, simplemente desactivadas.** Nueve de ellas
> correspondían directamente a algo recogido en las notas de las reuniones. Sin desarrollo, sin
> esquema, sin modelado: una sesión de administración.
>
> Presupuestar desarrollo para un interruptor es peor que un esfuerzo desperdiciado. Consume
> presupuesto que debería haber ido a las carencias reales, y cuando el cliente descubre más tarde
> que la funcionalidad estaba ahí desde el principio, cuesta una credibilidad difícil de
> recuperar.

Un espacio de Coevera lo expone directamente. En el espacio examinado, la colección `application`
contenía aproximadamente **107 registros de funcionalidades e integraciones**, cada uno con un
indicador de activación. Es el panel de funcionalidades de cada espacio, y leerlo lleva minutos.

Las capacidades de IA son filas que se activan una a una y suelen estar desactivadas, mientras que
otro conjunto distinto a menudo ya está activo y nadie lo ha mostrado. En el proyecto de
referencia, once aplicaciones relacionadas con la IA estaban desactivadas, mientras que otras
dieciséis funcionalidades (entre ellas varias integraciones y los agentes de automatización y de
informes) ya estaban activas y nunca se habían mostrado al cliente.

### Los grupos de solicitudes suelen compartir una única carencia de fondo

Por separado, tres de las 44 solicitudes parecían tres desarrollos distintos: un informe de los
invitados a eventos, un informe de las personas con las que realmente hubo reunión y una
sugerencia basada en la asistencia. Las tres fallaban por la *misma* relación ausente: la entidad
de evento no tenía ningún vínculo directo con los contactos. El único camino existente pasaba por
un registro de gastos, lo que significaba que solo se podía saber quién había asistido si alguien
había registrado un gasto por esa persona.

Una relación, construida una sola vez, convirtió tres solicitudes en datos sobre los que se podían
hacer informes. Estimarlas por separado habría triplicado el presupuesto y aun así habría
producido tres respuestas parciales.

### Algunas cosas no pueden construirse a ningún precio

Unas pocas solicitudes apuntaban a objetos de la plataforma con una forma fija: un punto de
extensión que simplemente no existe. Prometerlas es el peor resultado posible, porque el fallo
aparece en la entrega y no al definir el alcance.

## 03 · El marco de decisión

Cada requisito recibe exactamente un veredicto antes de que nadie estime nada. El veredicto
determina quién se hace cargo de él, y eso es lo que lo hace útil y no meramente académico.

| Veredicto | Significado | Responsable |
|---|---|---|
| **Activo** | Activo hoy en el espacio. La carencia es de conocimiento, no de capacidad. | Habilitación / formación |
| **Interruptor** | Viene con el producto; la aplicación está inactiva en este espacio. | Administrador |
| **Configuración** | Alcanzable con automatización, campos personalizados, informes o listas de comprobación por paso. | Arquitecto de soluciones / administrador |
| **Desarrollo** | Esquema, relación o integración completamente nuevos. | Arquitecto + ingeniería |
| **Límite** | Frontera rígida de la plataforma. Replantear sobre algo que existe. | Producto |
| **Ajeno al producto** | Política, cuestiones comerciales o herramientas internas disfrazadas de CRM. | Equipo de cuenta |

### Cuando el veredicto es Desarrollo, ¿adónde va?

Cuatro destinos, en orden creciente de coste:

| Destino | Cuándo usarlo | Coste |
|---|---|---|
| **Un campo en una entidad existente** | Los datos describen ese registro y no tienen existencia independiente: un nivel, un territorio, un indicador. | El más barato. Pero cada campo es otra fila en un formulario que ven todos los usuarios. |
| **Un subtipo de una entidad existente** | Se necesitan el mismo ciclo de vida y la misma cola, pero un conjunto de campos distinto para cada variante. | Bajo. Se trata a fondo en el [Blueprint 001](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/). |
| **Un registro hijo relacionado** | Hay muchos por registro principal: líneas de pedido, visitas de inspección, lecturas. | Moderado. Un lookup al registro principal y una cuadrícula en línea en el formulario del registro principal. |
| **Una entidad personalizada nueva** | Tiene su propio ciclo de vida, necesita su propia numeración de referencia y se lista y se analiza en informes de forma independiente. | El más alto. Sus propios formularios, sus propios permisos y una entrada en el menú de creación. |

**Fuente.** Centro de ayuda de Coevera, [Advanced admin — working with custom
entities](https://help.coevera.com/en/articles/8330709-advanced-admin-working-with-custom-entities),
sobre lo que implica realmente configurar el más caro de los cuatro destinos.

La pregunta decisiva es breve: **¿esta cosa se lista, se filtra y se analiza en informes de forma
independiente, y tiene vida propia?** Una inspección sí: tiene una fecha, un inspector, un
resultado, y querrá una lista de las que están vencidas. El nivel de un distribuidor no; es un
atributo de una cuenta.

> **Lo que una entidad personalizada le da realmente**, y por tanto lo que está pagando: su propio
> endpoint REST, sus propios formularios editables por subtipo, una numeración de referencia
> basada en secuencias y funcionalidades de registro opcionales (actividades, documentos, notas y
> búsqueda global). Si no necesita nada de eso, probablemente no necesite la entidad.

## 04 · Mecánica de configuración

### Cómo leer el panel de funcionalidades

Exporte los registros de funcionalidades del espacio y sepárelos por estado de activación antes de
definir el alcance de nada. Después, asigne cada solicitud del cliente a una fila, y considere
algo un desarrollo solo cuando ninguna fila lo cubra.

### Corrobore un interruptor con el uso

Que un interruptor esté desactivado es, por sí solo, un hallazgo débil. Combinado con pruebas de
que no se usa, se vuelve sólido: en el caso de los campos de IA, revise todas las colecciones de
descriptores de campo en busca de un bloque de opciones de IA no nulo. **Cero campos configurados
más la aplicación desactivada significa que la funcionalidad nunca se ha usado**, una afirmación
mucho más defendible que el interruptor por sí solo, y que le indica que la solicitud está
realmente sin atender y no mal explicada.

La configuración del detector de duplicados merece el mismo tratamiento. Incluye un indicador de
activación, un nivel de similitud y los ID de los campos comparados por entidad, de modo que una
solicitud de «activar la detección de duplicados» a menudo significa en realidad «la regla
existente compara demasiado pocos campos».

### Campos lookup: la mecánica que suele sorprender

- **Un campo lookup es una relación multivalor, que se intercambia como un array de referencias**,
  no una clave foránea escalar. Una lectura devuelve un array de objetos de referencia; un array
  vacío significa que no hay nada vinculado.
- **Escribir un array sustituye los vínculos en lugar de añadirse a ellos.** Envíe siempre el
  conjunto completo previsto; un array vacío borra la relación. Es la forma más habitual en que
  una integración desvincula sin avisar registros que pretendía dejar intactos.
- **Los nombres de los campos personalizados se usan tal cual**, sin sufijo `_id`, aunque las
  claves foráneas del sistema sí lo llevan.
- **Crear un campo lookup requiere un bloque de filtro completo** incluso cuando el filtrado está
  desactivado; si se omite, falla con un error genérico poco útil.

> **La trampa cuando sí crea una entidad personalizada.** Al crear una, se crea automáticamente un
> subtipo por defecto por debajo de ella, con el mismo nombre y un formulario vacío. Si añade sus
> propios subtipos, los usuarios ven en el menú de creación una entrada más de las que usted
> pretendía, y la sobrante no lleva a ninguna parte. En su lugar, aloje uno de sus subtipos en el
> subtipo por defecto creado automáticamente; consulte el [Blueprint
> 001](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/).

## 05 · Cómo ordenar la respuesta

Una vez que cada solicitud tiene su veredicto, el orden de entrega sale solo, y adelanta
deliberadamente todo lo que no cuesta nada.

1. **Desbloquear**Todo aquello en lo que el cliente está atascado hoy. Días, no semanas, y genera
   buena voluntad para todo lo que viene después.
2. **Mostrarle lo que ya tiene**Cada veredicto *Activo*, demostrado. Ningún desarrollo. En el
   proyecto de referencia, esto abarcó dieciséis funcionalidades activas que nunca se habían
   mostrado.
3. **Activar y configurar**Los veredictos *Interruptor* y *Configuración*. Una sesión de
   administración y algo de configuración, sujetas a la aprobación interna que el cliente necesite
   primero.
4. **Desarrollar**Solo lo que ha superado las tres primeras fases, con alcance y presupuesto
   aparte, porque para entonces es una lista mucho más corta.
5. **Seguimientos ajenos al producto**Se entregan a quien realmente se hace cargo de ellos, en
   lugar de absorberlos discretamente en el alcance del CRM.

Las fases 1 a 3 son las que cambian la conversación. Un análisis de requisitos que entrega una
cuarta parte de la lista sin ningún desarrollo, antes de presupuestar el primero, se gana el
derecho a una conversación seria sobre el resto.

## 06 · Límites y compromisos

### La salvedad que desmonta toda la historia de las victorias rápidas si se pasa por alto

> **El indicador de activación de una aplicación no distingue entre «un administrador puede
> activarlo hoy» y «esto depende de la licencia».** En algunas filas refleja un derecho de uso y
> no un simple interruptor.
>
> Confirme con el equipo de producto qué elementos puede activar realmente un administrador
> *antes* de presentarlos como victorias rápidas gratuitas. Todo el valor del hallazgo de los
> interruptores depende de esa distinción, y equivocarse convierte una ganancia de credibilidad en
> una pérdida de credibilidad.

### Límites rígidos: replantear en lugar de desarrollar

En el proyecto de referencia aparecieron tres categorías, y cada una tiene una alternativa
honesta:

| Límite | Consecuencia | Replantear sobre |
|---|---|---|
| Algunos objetos de la plataforma tienen una forma fija y no admiten campos adicionales | No se puede mostrar contenido personalizado a través de esa funcionalidad | Mosaicos de informes o paneles, o tareas generadas por automatización |
| Ciertos filtros solo operan sobre el propietario y la unidad organizativa | No se puede configurar el filtrado de esa funcionalidad por región | Informes y filtros guardados sobre los campos de ubicación nativos |
| La plataforma no tiene ninguna capacidad de gestión del aprendizaje ni de cuestionarios | No se puede prometer la evaluación de la incorporación como producto | Una guía proporcionada por el equipo de servicios, o un LMS de terceros del centro de integraciones |

Uno más que conviene conocer antes de diseñar en torno a ello: **los procesos de aprobación no
pueden tener como destino una entidad personalizada**, y el propio registro de aprobación no
admite campos personalizados. Si su nueva entidad necesita aprobación, eso condiciona el diseño;
la solución alternativa está en el [Blueprint
001](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/).

### El coste permanente de una entidad personalizada

Conviene decirlo con claridad, porque normalmente se deja fuera de la estimación: cada entidad
personalizada es otro formulario que mantener, otra superficie de permisos que configurar bien,
otra entrada en el menú de creación y otra cosa que hay que tener en cuenta cada vez que se
reconfigura el espacio. Las entidades son baratas de crear y caras de mantener.

### Dónde este análisis no puede ayudar

Las solicitudes recogidas en notas de reuniones arrastran ambigüedades que ningún conocimiento de
la plataforma resuelve: una abreviatura sin explicar, un nombre de producto poco claro, una
referencia a una persona que nadie sabe identificar. En el proyecto de referencia, cuatro
elementos no pudieron acotarse exactamente por ese motivo. Márquelos como preguntas abiertas en
lugar de adivinar; una solicitud que se ha entendido mal es más peligrosa que una que todavía no
se ha respondido.

## 07 · Verificación

El resultado de este ejercicio es un conjunto de afirmaciones sobre lo que puede hacer una
plataforma, hechas a un cliente que se las exigirá. Cada una necesita respaldo antes de decirse en
voz alta.

- **Cada veredicto vinculado a una prueba.** Un veredicto *Interruptor* cita la fila de la
  aplicación y su estado. Un veredicto *Configuración* cita el mecanismo que lo consigue. Un
  veredicto *Límite* cita la ausencia: la forma fija del objeto, o que no hay ninguna operación
  correspondiente en todo el esquema.
- **Interruptores corroborados con el uso configurado**, no afirmados solo a partir del indicador.
- **Licencias confirmadas con el equipo de producto** para cada elemento que vaya a presentarse
  como un interruptor gratuito.
- **Correcciones documentadas, no absorbidas en silencio.** Varias lecturas iniciales eran
  erróneas y se corrigieron durante el análisis; conservar ese rastro es lo que permite a un
  revisor comprobar el razonamiento en lugar de dar la conclusión por buena sin más.
- **Los elementos que no se pueden resolver, listados como preguntas abiertas**, con el motivo por
  el que no pueden responderse sin el cliente.
- **Para todo lo que llegó a Desarrollo:** el destino justificado frente a las cuatro opciones del
  §3, y las alternativas descartadas por escrito. Una entidad personalizada cuya necesidad nadie
  sabe explicar acaba creándose de todos modos seis meses después, por alguien que no sabe que ya
  se consideró y se descartó.

**Qué indicaría que el análisis salió mal:** que se presupueste un desarrollo para algo que
después resulta ser un interruptor; tres estimaciones separadas que comparten una única carencia
de fondo; una entidad personalizada entregada cuya vista de lista nadie abre.

## Blueprints relacionados

- [Blueprint 001 — ¿Cómo gestiona cinco tipos distintos de solicitudes de clientes en un único
  servicio de
  asistencia?](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/) — el
  destino de subtipo llevado hasta el final: cinco tipos de solicitud en una entidad.
- [Blueprint 007 — ¿Cómo fija precios distintos para un mismo producto por región, segmento o
  contrato?](https://blueprints.coevera.com/es/blueprints/pricing-one-product-many-prices/) — un
  requisito que parece un campo del producto y no lo es: el precio vive en un registro de unión.
- [Blueprint 010 — ¿Cómo entrega una oportunidad ganada al equipo que la
  ejecuta?](https://blueprints.coevera.com/es/blueprints/handover-from-sales-to-delivery/) — un
  segundo pipeline como respuesta de configuración a un traspaso que nadie quería desarrollar.
- [Blueprint 011 — ¿Cómo mantiene cientos de automatizaciones del CRM de forma
  sostenible?](https://blueprints.coevera.com/es/blueprints/keeping-hundreds-of-automations-maintainable/)
  — lo que cuesta mantener en funcionamiento el desarrollo que usted aprueba cuando ya hay
  cientos.

## Preguntas frecuentes

### ¿Cómo modela algo para lo que su CRM no tiene un objeto, como inspecciones, permisos o activos?

Antes de diseñar nada, determine en cuál de seis veredictos encaja realmente el requisito: ya activo en el espacio, una funcionalidad que viene con el producto pero está desactivada, alcanzable mediante configuración, un desarrollo real, un límite rígido de la plataforma que hay que replantear o, directamente, no es un problema de producto. Solo el cuarto es un ejercicio de modelado. Cuando se trata de un desarrollo, hay que elegir entre una entidad personalizada nueva (con su propio endpoint de API, formularios, numeración por secuencia y funcionalidades de registro), campos adicionales en una entidad estándar existente (más barato, pero visible para todos) o un registro hijo relacionado con un lookup de vuelta a su registro principal.

### ¿Cuándo conviene crear una entidad personalizada en lugar de añadir campos personalizados?

Cree una entidad personalizada cuando la cosa tenga su propio ciclo de vida, necesite su propia numeración de referencia o vaya a listarse y a analizarse en informes de forma independiente. Añada campos a una entidad estándar existente cuando los datos describan ese registro y no tengan existencia independiente: es mucho más barato y hereda todo el comportamiento del registro principal, pero cada campo es otra fila en un formulario que ven todos los usuarios. Use un registro hijo relacionado cuando haya muchos por registro principal, como líneas de pedido o visitas de inspección.

### ¿Por qué las solicitudes de personalización de un CRM a menudo no necesitan desarrollo?

Porque muchas de las capacidades solicitadas ya vienen con la plataforma y simplemente están desactivadas a nivel de espacio. Todo espacio de Coevera expone un panel de funcionalidades; en el espacio examinado contenía aproximadamente 107 registros de funcionalidades e integraciones, cada uno con un indicador de activación. En un análisis reciente de requisitos con seis departamentos, 11 de aproximadamente 44 solicitudes distintas correspondían a funcionalidades que estaban presentes y con licencia, pero desactivadas: no hacía falta ningún desarrollo. Leer ese panel antes de definir el alcance es el paso de mayor valor en un análisis de requisitos, porque presupuestar desarrollo para algo que es un interruptor destruye la credibilidad y consume presupuesto que debería ir a las carencias reales.

### ¿Cómo se distingue un límite real de la plataforma de algo que solo necesita configurarse?

Compruebe la forma de lo que intenta ampliar. Algunos objetos de la plataforma tienen una forma fija y no admiten campos adicionales, y algunos filtros solo operan sobre dimensiones concretas, como el propietario o la unidad organizativa. Cuando no existe en ninguna parte una mutación ni una vía de configuración para una capacidad, es un límite rígido, y la respuesta honesta es replantear el requisito sobre algo que sí existe (informes, paneles o tareas generadas por automatización) en lugar de prometer un desarrollo que no se puede entregar.

---

Publicado por Coevera. Abstraído al patrón reutilizable: sin nombres de clientes, sin datos
de clientes, sin datos personales.