---
title: "Come modella qualcosa per cui il suo CRM non ha un oggetto?"
blueprint: 003
slug: where-should-this-data-live
category: Modello dati
published: 2026-09-23
revised: 2026-09-23
platform: Coevera CRM (formerly Pipeliner CRM)
canonical: https://blueprints.coevera.com/it/blueprints/where-should-this-data-live/
language: it
translation_of: https://blueprints.coevera.com/blueprints/where-should-this-data-live/
author: Lucia Schmidt
publisher: Coevera
customer_data: none
---

# Come modella qualcosa per cui il suo CRM non ha un oggetto?

**Risposta breve.** Non inizi dalla modellazione. Inizi classificando ogni requisito in uno di
**sei verdetti**: già **attivo** nello spazio · una funzionalità inclusa ma **disattivata** ·
realizzabile tramite **configurazione** · un vero **sviluppo** · un **limite** rigido della
piattaforma da riformulare · oppure **non un problema di prodotto**. Solo il quarto è un esercizio
di modellazione dei dati.

Quando *si tratta* di uno sviluppo, la scelta è tra un'**entità personalizzata** — con un proprio
endpoint API, moduli, numerazione a sequenza e funzionalità del record —, **campi aggiuntivi su
un'entità standard esistente** oppure un **record figlio correlato**. Il test è se l'oggetto abbia
un proprio ciclo di vita e venga elencato in modo indipendente.

## 01 · Il problema di business

Un'organizzazione arriva con un elenco. Sei reparti erano stati intervistati separatamente e, nel
complesso, avevano prodotto circa **44 richieste distinte** di cose che il CRM avrebbe dovuto
fare: tenere traccia delle ispezioni in sito, gestire i permessi associati agli asset, registrare
chi era stato invitato a un evento rispetto a chi si era effettivamente presentato, proporre
suggerimenti agli account manager, gestire quiz di onboarding, produrre report per regione.

Ogni richiesta era formulata come una soluzione anziché come un problema — "ci serve un riquadro
nella dashboard", "ci serve un nuovo modulo per i permessi" — perché è così che le persone
descrivono ciò che vogliono. E l'istinto, da entrambi i lati del tavolo, è prendere l'elenco alla
lettera e iniziare a progettare oggetti per esso.

Quell'istinto è costoso in un modo specifico. Trasforma un esercizio di analisi in un preventivo
di sviluppo, e lo fa prima che qualcuno abbia stabilito quali delle 44 cose la piattaforma faccia
già.

## 02 · Perché l'approccio ovvio non funziona

### Una quota consistente delle richieste non sono sviluppi

> **Di circa 44 richieste, 11 corrispondevano a funzionalità presenti e concesse in licenza nello
> spazio stesso del cliente e semplicemente disattivate.** Nove di queste corrispondevano
> direttamente a qualcosa nelle note delle riunioni. Nessuno sviluppo, nessuno schema, nessuna
> modellazione — una sessione di amministrazione.
>
> Preventivare uno sviluppo per un interruttore è peggio di uno sforzo sprecato. Brucia budget che
> sarebbe dovuto andare alle lacune reali, e quando il cliente scopre in seguito che la
> funzionalità c'era da sempre, costa una credibilità difficile da recuperare.

Uno spazio Coevera lo espone direttamente. Nello spazio esaminato, la collezione `application`
conteneva circa **107 record di funzionalità e integrazioni**, ciascuno con un flag di
attivazione. È il pannello delle funzionalità per spazio, e leggerlo richiede pochi minuti.

Le funzionalità di IA sono righe attivabili singolarmente e sono spesso disattivate, mentre un
insieme diverso è spesso già attivo e mai mostrato. Nell'incarico di riferimento, undici app
legate all'IA erano disattivate, mentre altre sedici funzionalità — tra cui diverse integrazioni e
gli agenti di automazione e di reportistica — erano già attive e non erano mai state mostrate al
cliente.

### Gruppi di richieste condividono spesso un'unica lacuna di fondo

Prese singolarmente, tre delle 44 richieste sembravano tre sviluppi separati: un report sugli
invitati agli eventi, un report su chi era stato effettivamente incontrato e un suggerimento
basato sulla partecipazione. Tutte e tre fallivano per la *stessa* relazione mancante — l'entità
evento non aveva alcun collegamento diretto con i contatti. L'unico percorso esistente passava per
un record di spesa, il che significava che si poteva sapere chi aveva partecipato solo se qualcuno
ne aveva messo a rimborso la spesa.

Una sola relazione, costruita una volta, ha trasformato tre richieste in dati su cui fare report.
Stimarle separatamente avrebbe triplicato il preventivo e prodotto comunque tre risposte parziali.

### Alcune cose non si possono costruire a nessun prezzo

Una manciata di richieste riguardava oggetti della piattaforma dalla forma fissa — un punto di
estensione che semplicemente non esiste. Prometterli è il peggiore esito possibile, perché il
fallimento emerge alla consegna anziché in fase di definizione del perimetro.

## 03 · Il quadro decisionale

Ogni requisito riceve esattamente un verdetto prima che qualcuno stimi qualsiasi cosa. Il verdetto
determina chi ne è responsabile, ed è questo che rende il metodo utile anziché accademico.

| Verdetto | Significato | Responsabile |
|---|---|---|
| **Attivo** | Attivo oggi nello spazio. La lacuna è di consapevolezza, non di capacità. | Enablement / formazione |
| **Da attivare** | Incluso nel prodotto; l'app è inattiva in questo spazio. | Amministratore |
| **Configurazione** | Realizzabile con automazioni, campi personalizzati, report o checklist per fase. | Solution architect / amministratore |
| **Sviluppo** | Schema, relazione o integrazione del tutto nuovi. | Architetto + sviluppo |
| **Limite** | Confine rigido della piattaforma. Riformulare su qualcosa che esiste. | Prodotto |
| **Non di prodotto** | Policy, questioni commerciali o strumenti interni travestiti da CRM. | Team dell'account |

### Quando il verdetto è Sviluppo — dove va collocato?

Quattro destinazioni, in ordine crescente di costo:

| Destinazione | Da usare quando | Costo |
|---|---|---|
| **Un campo su un'entità esistente** | I dati descrivono quel record e non hanno un'esistenza indipendente — un livello, un territorio, un flag. | Il più economico. Ma ogni campo è un'altra riga su un modulo che vedono tutti gli utenti. |
| **Un sottotipo di un'entità esistente** | Servono lo stesso ciclo di vita e la stessa coda, ma un insieme di campi diverso per ogni variante. | Basso. Trattato in dettaglio nel [Blueprint 001](https://blueprints.coevera.com/it/blueprints/one-entity-five-request-types/). |
| **Un record figlio correlato** | Ce ne sono molti per ciascun padre — righe di dettaglio, visite di ispezione, letture. | Moderato. Un lookup verso il padre e una griglia inline nel modulo del padre. |
| **Una nuova entità personalizzata** | Ha un proprio ciclo di vita, ha bisogno di una propria numerazione di riferimento e viene elencata e riportata nei report di per sé. | Il più alto. Moduli e permessi propri, e una voce nel menu di creazione. |

**Fonte.** Centro assistenza di Coevera, [Advanced admin — working with custom
entities](https://help.coevera.com/en/articles/8330709-advanced-admin-working-with-custom-entities),
per ciò che comporta effettivamente configurare la più costosa delle quattro destinazioni.

La domanda decisiva è breve: **questo oggetto viene elencato, filtrato e riportato nei report in
modo indipendente, e ha una vita propria?** Un'ispezione sì — ha una data, un ispettore, un esito,
e vorrà un elenco di quelle scadute. Il livello di un distributore no; è un attributo di un
account.

> **Cosa offre effettivamente un'entità personalizzata**, e quindi per cosa sta pagando: un
> proprio endpoint REST, moduli modificabili propri per ogni sottotipo, una numerazione di
> riferimento basata su sequenze e funzionalità del record attivabili a scelta — attività,
> documenti, note e ricerca globale. Se non le serve nulla di tutto ciò, probabilmente non le
> serve l'entità.

## 04 · Aspetti pratici della configurazione

### Leggere il pannello delle funzionalità

Esporti i record delle funzionalità dello spazio e li suddivida per stato di attivazione prima di
definire il perimetro di qualsiasi cosa. Poi associ ogni richiesta del cliente a una riga, e
consideri qualcosa uno sviluppo solo quando nessuna riga lo copre.

### Confermare un interruttore rispetto all'uso

Un interruttore disattivato è, da solo, un indizio debole. Se lo si affianca a prove del mancato
utilizzo diventa solido: per i campi IA, esamini ogni collezione di descrittori di campo alla
ricerca di un blocco di opzioni IA non nullo. **Zero campi configurati più l'app disattivata
significano che la funzionalità non è mai stata usata** — un'affermazione molto più difendibile
del solo interruttore, e che le dice che la richiesta è davvero insoddisfatta anziché spiegata
male.

Le impostazioni del controllo dei duplicati meritano lo stesso trattamento. Contengono un flag di
attivazione, un livello di somiglianza e gli ID dei campi confrontati per ogni entità — quindi una
richiesta di "attivare il controllo dei duplicati" è spesso in realtà "la regola esistente
confronta troppo pochi campi".

### Campi di lookup — i meccanismi che sorprendono

- **Un campo di lookup è una relazione multivalore, scambiata come array di riferimenti** — non
  una chiave esterna scalare. Una lettura restituisce un array di oggetti di riferimento; un array
  vuoto significa che non è collegato nulla.
- **Scrivere un array sostituisce i collegamenti anziché aggiungerli.** Invii ogni volta l'intero
  insieme desiderato; un array vuoto azzera la relazione. È il modo più comune in cui
  un'integrazione scollega in silenzio record che intendeva lasciare invariati.
- **I nomi dei campi personalizzati si usano alla lettera**, senza suffisso `_id`, anche se le
  chiavi esterne di sistema lo hanno.
- **La creazione di un campo di lookup richiede un blocco filtro completo** anche quando il
  filtraggio è disattivato — ometterlo produce un errore generico e poco utile.

> **La trappola quando crea davvero un'entità personalizzata.** Crearne una genera automaticamente
> al suo interno un sottotipo predefinito con lo stesso nome e un modulo vuoto. Se aggiunge i suoi
> sottotipi, gli utenti vedono nel menu di creazione una voce in più di quelle previste, e quella
> in più è un vicolo cieco. Collochi invece uno dei suoi sottotipi sul predefinito creato
> automaticamente — si veda il [Blueprint
> 001](https://blueprints.coevera.com/it/blueprints/one-entity-five-request-types/).

## 05 · Mettere in sequenza la risposta

Una volta che ogni richiesta ha un verdetto, l'ordine di consegna viene da sé — e porta
deliberatamente in testa tutto ciò che non costa nulla.

1. **Sbloccare**Tutto ciò su cui il cliente è bloccato oggi. Giorni, non settimane, e procura
   buona volontà per tutto ciò che segue.
2. **Mostrare ciò che possiede già**Ogni verdetto *Attivo*, dimostrato. Zero sviluppo.
   Nell'incarico di riferimento questo ha riguardato sedici funzionalità attive che non erano mai
   state mostrate.
3. **Attivare e configurare**I verdetti *Da attivare* e *Configurazione*. Una sessione di
   amministrazione e un po' di impostazione, fatta salva l'approvazione interna di cui il cliente
   ha bisogno prima.
4. **Sviluppare**Solo ciò che è sopravvissuto alle prime tre fasi — definito e preventivato
   separatamente, perché a questo punto l'elenco è molto più breve.
5. **Seguiti non di prodotto**Affidati a chi ne è effettivamente responsabile, anziché assorbiti
   in silenzio nel perimetro del CRM.

Sono le fasi da 1 a 3 a cambiare la conversazione. Un esercizio sui requisiti che consegna un
quarto dell'elenco senza alcuno sviluppo, prima che venga preventivato il primo, si guadagna il
diritto a una discussione seria sul resto.

## 06 · Limiti e compromessi

### L'avvertenza che, se trascurata, fa crollare l'intera storia dei risultati rapidi

> **Il flag di attivazione di un'app non distingue tra "un amministratore può attivarla oggi" e "è
> vincolata alla licenza".** Per alcune righe riflette un diritto di licenza anziché un semplice
> interruttore.
>
> Verifichi con il team di prodotto quali elementi siano davvero attivabili da un amministratore
> *prima* di presentarli come risultati rapidi gratuiti. L'intero valore della scoperta degli
> interruttori si basa su questa distinzione, e sbagliarla trasforma un guadagno di credibilità in
> una perdita di credibilità.

### Limiti rigidi — riformulare anziché sviluppare

Nell'incarico di riferimento sono emerse tre categorie, e ciascuna ha un'alternativa onesta:

| Limite | Conseguenza | Riformulare su |
|---|---|---|
| Alcuni oggetti della piattaforma hanno una forma fissa e non accettano campi aggiuntivi | Non è possibile mostrare contenuti personalizzati tramite quella funzionalità | Riquadri di report o dashboard, oppure attività generate dall'automazione |
| Alcuni filtri operano solo su proprietario e unità organizzativa | Il filtraggio di quella funzionalità per regione non è configurabile | Report e filtri salvati sui campi nativi di localizzazione |
| La piattaforma non offre alcuna funzionalità di gestione dell'apprendimento o di quiz | La valutazione di onboarding non può essere promessa come prodotto | Una guida fornita come servizio, oppure un LMS di terze parti dall'hub delle integrazioni |

Un altro limite da conoscere prima di progettarci attorno: **i processi di approvazione non
possono avere come destinazione un'entità personalizzata**, e il record di approvazione stesso non
accetta campi personalizzati. Se la sua nuova entità richiede un'approvazione, questo influisce
sul progetto — la soluzione alternativa è descritta nel [Blueprint
001](https://blueprints.coevera.com/it/blueprints/one-entity-five-request-types/).

### Il costo permanente di un'entità personalizzata

Vale la pena dirlo chiaramente, perché di solito resta fuori dalla stima: ogni entità
personalizzata è un altro modulo da mantenere, un'altra superficie di permessi da configurare
correttamente, un'altra voce nel menu di creazione e un'altra cosa da considerare ogni volta che
lo spazio viene riconfigurato. Le entità sono economiche da creare e costose da possedere.

### Dove questa analisi non può aiutare

Le richieste raccolte dalle note delle riunioni contengono ambiguità che nessuna conoscenza della
piattaforma può risolvere — un'abbreviazione non spiegata, un nome di prodotto poco chiaro, il
riferimento a una persona che nessuno riesce a identificare. Nell'incarico di riferimento quattro
elementi non hanno potuto essere definiti proprio per questo motivo. Li segnali come domande
aperte anziché tirare a indovinare; una richiesta fraintesa è più pericolosa di una a cui non ha
ancora risposto.

## 07 · Verifica

Il risultato di questo esercizio è un insieme di affermazioni su ciò che una piattaforma può fare,
rivolte a un cliente che gliene chiederà conto. Ognuna ha bisogno di un riscontro prima di essere
pronunciata ad alta voce.

- **Ogni verdetto ricondotto a una prova.** Un verdetto *Da attivare* cita la riga dell'app e il
  suo stato. Un verdetto *Configurazione* cita il meccanismo che lo realizza. Un verdetto *Limite*
  cita l'assenza — la forma fissa dell'oggetto, oppure nessuna operazione corrispondente in tutto
  lo schema.
- **Interruttori confermati rispetto all'uso configurato**, non affermati sulla base del solo
  flag.
- **Licenze confermate con il team di prodotto** per ogni elemento che verrà presentato come
  interruttore gratuito.
- **Correzioni registrate, non assorbite in silenzio.** Diverse letture iniziali si sono rivelate
  errate e sono state riviste nel corso dell'analisi; conservare questa traccia è ciò che consente
  a un revisore di verificare il ragionamento anziché accettare la conclusione sulla fiducia.
- **Elementi irrisolvibili elencati come domande aperte**, con il motivo per cui non è possibile
  rispondere offline.
- **Per tutto ciò che è arrivato a Sviluppo:** la destinazione giustificata rispetto alle quattro
  opzioni del §3, e le alternative scartate messe per iscritto. Un'entità personalizzata di cui
  nessuno sa spiegare la necessità viene creata comunque, sei mesi dopo, da qualcuno che non sa
  che era già stata considerata e respinta.

**Cosa segnalerebbe che l'analisi è andata storta:** uno sviluppo preventivato per qualcosa che in
seguito si rivela un interruttore; tre stime separate che condividono un'unica lacuna di fondo;
un'entità personalizzata consegnata la cui vista elenco nessuno apre.

## Blueprint correlati

- [Blueprint 001 — Come gestisce cinque tipi diversi di richieste dei clienti in un unico help
  desk?](https://blueprints.coevera.com/it/blueprints/one-entity-five-request-types/) — la
  destinazione sottotipo portata fino in fondo — cinque tipi di richiesta in un'unica entità.
- [Blueprint 007 — Come fissa prezzi diversi per lo stesso prodotto per regione, segmento o
  contratto?](https://blueprints.coevera.com/it/blueprints/pricing-one-product-many-prices/) — un
  requisito che sembra un campo sul prodotto e non lo è: il prezzo risiede su un record di
  collegamento.
- [Blueprint 010 — Come consegna un'opportunità vinta al team che la
  realizza?](https://blueprints.coevera.com/it/blueprints/handover-from-sales-to-delivery/) — una
  seconda pipeline come risposta di configurazione a un passaggio di consegne che nessuno voleva
  sviluppare.
- [Blueprint 011 — Come mantiene gestibili centinaia di automazioni del
  CRM?](https://blueprints.coevera.com/it/blueprints/keeping-hundreds-of-automations-maintainable/)
  — quanto costa mantenere funzionante lo sviluppo che approva, una volta che ce ne sono
  centinaia.

## Domande frequenti

### Come modella qualcosa per cui il suo CRM non ha un oggetto, come ispezioni, permessi o asset?

Prima di progettare qualsiasi cosa, stabilisca in quale di sei verdetti rientra effettivamente il requisito: già attivo nello spazio, una funzionalità inclusa nel prodotto ma disattivata, realizzabile tramite configurazione, un vero sviluppo, un limite rigido della piattaforma che richiede una riformulazione, oppure nemmeno un problema di prodotto. Solo il quarto è un esercizio di modellazione. Quando si tratta di uno sviluppo, la scelta è tra una nuova entità personalizzata (con un proprio endpoint API, moduli, numerazione a sequenza e funzionalità del record), campi aggiuntivi su un'entità standard esistente (più economici ma visibili a tutti) oppure un record figlio correlato con un lookup verso il suo padre.

### Quando conviene creare un'entità personalizzata invece di aggiungere campi personalizzati?

Crei un'entità personalizzata quando l'oggetto ha un proprio ciclo di vita, ha bisogno di una propria numerazione di riferimento o verrà elencato e riportato nei report in modo indipendente. Aggiunga campi a un'entità standard esistente quando i dati descrivono quel record e non hanno un'esistenza indipendente — è molto più economico ed eredita tutto il comportamento del padre, ma ogni campo è un'altra riga su un modulo che vedono tutti gli utenti. Usi un record figlio correlato quando ce ne sono molti per ciascun padre, come le righe di dettaglio o le visite di ispezione.

### Perché le richieste di personalizzazione del CRM spesso non richiedono sviluppo?

Perché molte delle funzionalità richieste sono già incluse nella piattaforma e sono semplicemente disattivate a livello di spazio. Ogni spazio Coevera espone un pannello delle funzionalità; nello spazio esaminato elencava circa 107 record di funzionalità e integrazioni, ciascuno con un flag di attivazione. In una recente analisi dei requisiti con sei reparti, 11 di circa 44 richieste distinte corrispondevano a funzionalità presenti e concesse in licenza ma disattivate — senza alcuno sviluppo necessario. Leggere quel pannello prima di definire il perimetro è il passaggio di maggior valore in un esercizio sui requisiti, perché preventivare uno sviluppo per qualcosa che è un interruttore distrugge la credibilità e consuma budget che dovrebbe andare alle lacune reali.

### Come si distingue un vero limite della piattaforma da qualcosa che richiede solo configurazione?

Verifichi la forma dell'oggetto che sta cercando di estendere. Alcuni oggetti della piattaforma hanno una forma fissa e non accettano campi aggiuntivi, e alcuni filtri operano solo su dimensioni specifiche come il proprietario o l'unità organizzativa. Dove per una funzionalità non esiste da nessuna parte alcuna mutation o alcun percorso di configurazione, si tratta di un limite rigido e la risposta onesta è riformulare il requisito su qualcosa che esiste — report, dashboard o attività generate dall'automazione — anziché promettere uno sviluppo che non può essere consegnato.

---

Pubblicato da Coevera. Ridotto allo schema riutilizzabile: nessun nome di cliente, nessun dato
dei clienti, nessun dato personale.