Dove risiedono questi dati?

🌐 Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Modulo 4 di 10 del capitolo Architettura dei dati Salesforce, capitolo 3 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Costruisci il tuo: gli oggetti personalizzati · Successivo: Scegli l’oggetto giusto

La domanda a cui risponde questo modulo: prima di creare un oggetto, dove dovrebbero risiedere davvero questi dati: sul core in Salesforce, referenziati dove si trovano già, o archiviati?

Lascia che ti faccia una domanda. Ti arriva sulla scrivania un nuovo requisito. Qual è la prima cosa che fai?

Se sei come la maggior parte di noi, apri Imposta e crei un oggetto personalizzato. Lo capisco. In dieci minuti hai una scheda, un layout di pagina e una vista elenco. Ed ecco cosa dico in ogni corso: nel momento in cui crei quel nuovo oggetto, stai già pensando da architetto, che tu lo volessi o no. Perché ogni oggetto che crei è un impegno. Occupa spazio di archiviazione. Accumula limiti. Riceve un modello di condivisione, che tu ne abbia progettato uno o no. Ha bisogno di una licenza per chiunque lo tocchi. E una volta che persone e integrazioni ne dipendono, auguri a toglierlo.

Quindi la prima decisione di architettura non è quale oggetto. È dove dovrebbero risiedere questi dati? Imposta bene questo, e il tipo di oggetto si sceglie quasi da solo.

Sul core e fuori dal core

Prima di tutto, una parola che userò spesso: core. Il core è la piattaforma Salesforce su cui gira la tua org: la piattaforma multitenant guidata dai metadati del modulo 1, dove risiedono gli oggetti Sales e Service del modulo 2, e ogni oggetto personalizzato che costruisci nel modulo 3. Quando dico che i dati sono sul core, intendo che sono memorizzati nella tua org, nei suoi oggetti.

Non tutti i dati risiedono lì. Data 360 tiene i suoi dati in un proprio archivio, fuori dagli oggetti della tua org (è vicino al core, near-core: gestito sul core, con i dati ospitati fuori dal core; di più nel capitolo 4). E poi c’è tutto ciò che la tua azienda fa girare e che non è affatto Salesforce: l’ERP, il magazzino, il sistema degli ordini, la piattaforma del partner. Tutto questo è fuori dal core. Salesforce può raggiungerlo, mostrarlo e usarlo, ma la tua org non lo memorizza.

Sul core, ci sono due tipi di oggetti che contengono davvero i tuoi record: gli sObject, standard e personalizzati (__c), e i big object (__b). Fuori dal core, raggiungi i dati tramite gli oggetti esterni (__x) e gli altri strumenti di integrazione. Tieni a mente quei suffissi del modulo 3: ti dicono dove risiede un dato solo dal suo nome.

Io lo penso come un ufficio. Alcune cose stanno sulla tua scrivania, dove le usi ogni giorno. Alcune ti basta consultarle nello schedario di qualcun altro. E alcune finiscono negli scatoloni nel capanno sul retro. Questo mi dà tre risposte.

1. Sul core: stanno sulla tua scrivania

I dati vengono creati, modificati e usati in Salesforce ogni giorno: account, casi, opportunità, ordini di lavoro. Tenerli negli sObject è come tenerli sul davanti del tuo ufficio. È a questo che servono gli oggetti standard e personalizzati, e hai tutto: layout di pagina, condivisione, automazione, reportistica, ricerca, e ora le funzionalità di IA costruite sul modello dati.

La tua scrivania però non è gratis. I dati sul core costano spazio di archiviazione, contato come lo conta Salesforce, record per record, non colonna per colonna, e i documenti pesano a parte sullo spazio per i file. Li abbiamo visti entrambi nel modulo 2. Grandi volumi di foto e scansioni spesso stanno meglio fuori dal core, con Salesforce che conserva solo un link.

2. Referenziati: stanno nello schedario di qualcun altro

I dati appartengono a un altro sistema (l’ERP, un data warehouse, una piattaforma ordini), e quel sistema resta la fonte di verità. Gli utenti hanno bisogno di vederli in Salesforce, magari di collegarli a un record, ma Salesforce non ha bisogno di una propria copia. Li sentirai chiamare anche dati virtuali: compaiono in Salesforce in modo virtuale, senza esservi mai memorizzati.

Sono gli oggetti esterni, tramite Salesforce Connect. Mi piace dire che sembra un’anatra e cammina come un’anatra, ma non è un’anatra. Si presenta come un sObject: puoi metterlo nei layout di pagina e negli elenchi correlati, e collegarlo ai tuoi record con relazioni di ricerca esterne e indirette. Ma i dati non sono memorizzati sul core. Ogni volta che lo tocchi, fa una chiamata esterna (callout). Apri un record, carichi un elenco correlato, esegui un report, e Salesforce va a chiedere all’altro sistema. Questo significa latenza, e la tua pagina è disponibile solo quanto lo è il sistema dietro di essa.

Le persone si oppongono al costo della licenza, quindi fai i conti come li faccio io in aula. Connect è concesso in licenza per endpoint, e un endpoint può portare molti oggetti. Ora chiediti quanto costa costruire e mantenere l’alternativa: un componente personalizzato, il codice di callout dietro, e uno sviluppatore reperibile quando si rompe. Spesso la licenza costa meno, e i tuoi amministratori possono configurarla senza scrivere una riga di codice. Dove non regge: dati che gli utenti modificano tutto il giorno, o su cui fanno molta reportistica.

Anche i documenti si possono referenziare. Se un contratto si trova già in SharePoint Online, OneDrive, Google Drive o Box, Files Connect permette agli utenti di raggiungerlo da Salesforce senza copiarlo dentro.

Salesforce Connect non è l’unico modo per referenziare i dati. A volte è logica personalizzata: codice che chiama l’altro sistema in tempo reale e ne mostra i dati sulla pagina, senza conservarne una copia. Ti dà il pieno controllo, e la piena responsabilità del callout, degli errori e della manutenzione. E anche Data 360 può federare senza copiare. Quella scelta ha un suo capitolo (Virtualizzazione, federazione e zero copy). Qui il punto è la decisione in sé: referenzia, non copiare.

3. Archiviati: vanno nel capanno sul retro

Storico, audit trail, vecchie transazioni. Devi conservarli, a volte per anni, ma quasi nessuno li apre. Ed è quella che i team rimandano. Quando un corso mi dice di avere un oggetto con 50 milioni di record e mi chiede perché dovrebbero archiviare, rispondo con una domanda: se non archiviate oggi, archivierete mai? A 50 milioni oggi, state andando verso 100, 150, 200 milioni.

I capanni sono due. Uno è sul core: i big object. Pensali come dati messi in garage. Puoi memorizzare un numero enorme di record, ma non puoi metterli in un layout di pagina, non c’è un’interfaccia né una reportistica standard, e interroghi tramite l’indice del big object, per corrispondenza esatta o per intervallo (Big Objects Best Practices (opens in a new tab)). La sicurezza è solo a livello di autorizzazioni su oggetti e campi, senza condivisione dei record, e l’automazione non gira su di essi. Ho usato Salesforce Connect decine di volte e i big object solo una o due. Funzionano, ma sono scomodi, e ho scritto la mia dose di soluzioni alternative per arrivare ai dati. Quindi il mio consiglio: fai un prototipo prima di proporli, e pianifica come le persone troveranno i dati prima di sceglierli.

L’altro capanno è fuori dal core: un data warehouse o un database da qualche altra parte (Progettare per la scala). Spesso è il capanno migliore, e non deve per forza stare fuori dalla vista. I dati archiviati fuori dal core possono comparire ancora nei report tramite strumenti come Tableau, e restare raggiungibili da Salesforce, tramite Salesforce Connect o un altro modo di virtualizzarli, quando qualcuno ha bisogno di guardare indietro.

Lascia che ti racconti un progetto in cui l’abbiamo fatto bene fin dall’inizio. Un cliente retail aveva oltre 1.200 punti vendita. Mi hanno detto: “Facciamo solo cento appuntamenti al giorno per negozio. Niente di che”. Poi ho fatto i conti: cento al giorno, sei giorni alla settimana (circa 305 giorni all’anno), su 1.200 punti vendita, sono oltre 36 milioni di appuntamenti all’anno. Poi hanno detto che ogni visita creava due appuntamenti, uno al banco e uno per il retro del negozio: oltre 73 milioni di record all’anno. Poi volevano cinque anni di storico: più di 360 milioni di record, prima di qualsiasi crescita. Non eravamo ancora andati in produzione, e vedevo già il treno puntare dritto sulla stazione dei grandi volumi di dati. Così l’archivio è stato costruito prima di raccogliere un solo appuntamento: gli appuntamenti più vecchi passavano ai big object, e la schermata di ricerca mostrava gli appuntamenti attuali con quelli archiviati subito sotto. Anni dopo, funziona ancora benissimo.

Click to enlarge

Metterlo in pratica: Steve Trucking

Steve Trucking è il nostro scenario ricorrente: un’azienda familiare di consegne dell’ultimo miglio che ritira elettrodomestici ed elettronica nei centri di distribuzione delle grandi catene, poi li consegna e li installa a casa dei clienti. Quattro tipi di suoi dati, tre risposte:

Dati	Dove risiedono	Perché
Consegne, squadre e appuntamenti di oggi	Sul core	Chi fa dispatch e le squadre ci lavorano tutto il giorno
I dettagli degli ordini del retailer	Referenziati (o una copia essenziale sul core)	Il sistema del retailer è la fonte di verità
Lo storico delle consegne di tre anni fa	Archiviati	Conservati per reclami e tendenze; quasi nessuno li apre
Le foto delle consegne	Fuori dal core, con un link	Migliaia al giorno; memorizzate fuori da Salesforce con un link sulla consegna

Ecco la stessa cosa come modello dati. La Consegna (Delivery) sta sul core, dove le persone ci lavorano tutto il giorno. Dopo tre anni passa in Delivery History, un big object: ancora sul core, ma fuori nel capanno. L’ordine del partner compare come oggetto esterno, __x: Salesforce gli collega la consegna, ma i dati restano nel sistema del retailer. E le foto risiedono interamente fuori dal core, con un link dalla consegna. Un solo modello, tre sedi.

Click to enlarge

Ogni org reale le ha tutte e tre. Quelle che finiscono nei guai mettono tutto sul core, perché creare un oggetto era il pulsante predefinito.

Cosa decide qui un architetto

• La sede di ogni tipo di dato, prima di progettare qualsiasi oggetto: sul core, referenziati o archiviati.
• La fonte di verità. Se un altro sistema possiede i dati, Salesforce non dovrebbe diventare in silenzio un secondo master.
• Il percorso di accesso per tutto ciò che è fuori dal core. I dati referenziati hanno bisogno di una fonte disponibile e di una latenza accettabile; i dati archiviati hanno bisogno di un modo per farli trovare alle persone.
• La crescita dello spazio. Fai i conti adesso (record al giorno, per la crescita, per la conservazione), non quando arriva l’avviso sullo spazio.

Oltre l’esame: l’IA alza la posta sui dati “sul core”. Le funzionalità di IA e gli agenti funzionano meglio sui dati che la piattaforma capisce: dati in oggetti standard e personalizzati, con buoni nomi e buone descrizioni. È una spinta a mettere di più sul core. Resisti per i dati sbagliati. Un agente che si basa su una copia non aggiornata dei dati dell’ERP dà risposte sicure e sbagliate. Spesso la mossa migliore è referenziare la fonte viva, o tenere sul core una porzione piccola e ben descritta. Dove l’IA legge i dati fa ormai parte della decisione su dove risiedono i dati.

Per approfondire

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (in inglese, consultato il 2026-09-25)
• Files Connect FAQ (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-09-25)
• In questo corso: Virtualizzazione, federazione e zero copy e Progettare per la scala