Scegli l'oggetto giusto

🌐 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 5 di 10 del capitolo Architettura dei dati Salesforce, capitolo 3 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Dove risiedono questi dati? · Successivo: Anche i campi sono architettura

La domanda a cui risponde questo modulo: Che tipo di oggetto Salesforce dovrebbe diventare questo concetto di business, e cosa permettono le licenze?

Una delle cose più facili da fare in Salesforce è creare un oggetto personalizzato. È esattamente per questo che penso ne creiamo troppi.

Sei in una sessione sui requisiti e qualcuno dice: “Dobbiamo tracciare i nostri distributori”. Nuovo oggetto personalizzato: Distributore. Fatto. Solo che voglio che l’architetto si ponga prima un’altra domanda: cos’è un distributore? È un’azienda. Salesforce ha già un modo piuttosto buono per rappresentare un’azienda. Si chiama Account. Non significa che la risposta sia sempre Account. Ma se devo spiegare perché un’azienda non è un Account, voglio una ragione migliore di “il business li chiama distributori”.

È qui che il modello logico del capitolo 2 incontra la piattaforma, e la mia posizione di partenza è semplice: se il concetto di business si adatta in modo pulito allo scopo previsto di un oggetto standard, parti da lì.

Parti dal significato

Anche quando qualcosa merita di essere un oggetto, non merita automaticamente di essere un oggetto personalizzato. Chiediti cosa rappresenta davvero. Un’azienda o un’organizzazione di qualsiasi forma? Parti da Account. Una persona che lavora con quell’organizzazione? Contatto. Qualcosa che un cliente possiede o ha comprato? Asset. Qualcosa che stai cercando di vendere? Ora l’Opportunità entra nella conversazione.

Per questo abbiamo guardato prima alla nave madre, nel modulo 2. Quei modelli non vanno bene per ogni business, ma non dovremmo ignorarli perché costruirne di nostri ci sembra più pulito. Prima di Nuovo oggetto personalizzato, chiediti come modella Salesforce questo concetto, cosa è stato costruito intorno a quel modello, e a cosa rinunceresti sostituendolo.

La prova dell’adattamento pulito

La mia prova è una sola domanda: questo concetto di business si adatta in modo pulito allo scopo previsto dell’oggetto standard? Se sì, la mia propensione va verso l’oggetto standard.

Un distributore è un’azienda con cui abbiamo una relazione, quindi Account si adatta in modo pulito. Non mi importa che gli utenti chiamino un’azienda distributore, un’altra fornitore, un’altra partner retail e un’altra cliente. Sono ruoli di business, e non hanno bisogno di quattro oggetti fisici. Nomi di business diversi non significano automaticamente strutture di dati diverse. Un tipo, un tipo di record o una relazione possono portare la differenza.

La prova funziona anche nell’altra direzione. Nel capitolo 1 ti ho lasciato con una domanda: l’azienda di un cliente ha molti punti di consegna. Ogni punto di consegna dovrebbe essere un Account, o un oggetto personalizzato?

Un Account ti dà molto. Hai i campi dell’indirizzo, e tutto ciò che si aspetta già un indirizzo di Account: report, mappe, integrazioni. Ma ti prendi anche il sovraccarico: molti campi, condivisione, gerarchia, titolarità, tutto ciò che è appeso a un Account, e la maggior parte non c’entra con un indirizzo separato. Ti porteresti dietro un sacco di cose pesanti che non userai, solo per un indirizzo alternativo.

Un oggetto personalizzato, figlio dell’Account, può essere leggero: solo i campi dell’indirizzo, un luogo in cui consegniamo, con un suo ciclo di vita che posso controllare in modo indipendente.

Quindi è un equilibrio: il peso che ti prendi contro il valore che ottieni. Se mi serve solo un indirizzo con un suo ciclo di vita, è lì che vado sul personalizzato.

Lo stesso con i sotto-problemi di un caso. Se ogni sotto-problema è davvero un caso, lavorato da un agente, con un suo stato e un suo livello di servizio, annidali con il Caso principale (Parent Case) del modulo 2. Ma se è solo una voce di una checklist che nessuno lavora come un caso, un caso completo si porta dietro molto che non userà mai, e un semplice figlio personalizzato può pesare meno. Non perché il personalizzato sia più pulito. Perché il significato è diverso, o il peso è sbagliato.

Gli oggetti standard si portano dietro un bagaglio

Quando scegli un oggetto standard, scegli più dei suoi campi. Scegli qualcosa che i prodotti di Salesforce capiscono già: reportistica, automazione, relazioni integrate, funzionalità di prodotto, pacchetti AppExchange, e qualsiasi cosa Salesforce costruirà in futuro. Può avere un valore enorme.

Gli oggetti standard hanno anche le loro idee: comportamenti esistenti, relazioni, considerazioni di sicurezza, a volte requisiti di licenza, e funzionalità che non ti servono. Quindi “usa sempre gli oggetti standard” non è la mia regola. Non ho una regola del “sempre”. Ho una propensione: usa l’oggetto standard quando il significato si adatta in modo pulito e il comportamento della piattaforma intorno aiuta il progetto invece di ostacolarlo. Se passo cinque anni a far comportare l’Opportunità come qualcosa che non è un’opportunità di vendita, non ho guadagnato nulla restando sullo standard. Ho solo fatto il compromesso sbagliato nell’altra direzione.

Asset è un buon esempio

Asset è uno degli oggetti standard che si trascurano. Il modo più semplice in cui posso dirlo: è una cosa che il cliente ha. Forse l’ha comprata da noi, forse no. Mi interessa comunque il prodotto di un concorrente presso il sito del mio cliente, perché lo sto assistendo, o sto cercando di sostituirlo, o devo capire la sua base installata. Se creo Customer_Product__c senza guardare prima Asset, ho saltato una domanda architetturale. Asset non vince automaticamente, ma merita di essere valutato.

Account personali: quando la persona è l’account?

Nel modulo 2 abbiamo incontrato gli account personali: un account e un contatto in un unico record, per i clienti che sono persone fisiche. Ora la decisione.

La mia posizione: per il B2C è difficile farne a meno. Con Account e Contatti arriva così tanto già pronto che il costo e il sovraccarico ne valgono la pena. E un costo c’è: circa il doppio dello spazio di archiviazione di un account aziendale, un interruttore che non puoi spegnere, e alcune licenze esterne non possono usarli. Partner Community non si può usare con gli account personali (Experience Cloud User Licenses (opens in a new tab)). Quindi la domanda non è “abbiamo persone nel nostro database?”. Ogni org ha persone. È “in questo business la persona è davvero l’account?”. Il fatto che un Contatto sia una persona non lo rende un account personale. Lo decide la relazione di business.

Click to enlarge

Ora complichiamo tutto: le licenze

Finora: trova il concetto, cerca l’adattamento standard più pulito, vai sul personalizzato quando il significato non si adatta. Ora la domanda successiva dell’architetto: chi deve usarlo? Puoi progettare un modello bellissimo e poi scoprire che metà delle persone che hanno bisogno dei dati non ha la licenza per gli oggetti che hai scelto. Le licenze fanno parte del modello dati.

Tre licenze interne

Parti dalle tue persone. Dentro l’azienda ci sono tre tipi di licenza che voglio che ogni architetto conosca a menadito, perché determinano cosa ogni utente può vedere e fare, e quindi su cosa può contare il tuo modello dati.

Sales Cloud (ora Agentforce Sales). Questi utenti hanno la licenza utente Salesforce completa: gli oggetti CRM standard e qualsiasi app standard o personalizzata. Cioè lead, opportunità e previsioni oltre ad account e contatti, e perfino i casi: un commerciale può vedere i casi aperti di un cliente prima di una chiamata. Creare ed eseguire campagne richiede un pezzo in più, la licenza di funzionalità Marketing User.

Service Cloud (ora Agentforce Service). La stessa licenza utente Salesforce, configurata per l’assistenza. Al centro ci sono i casi, lavorati nella Service Console: è la licenza di funzionalità Service Cloud User che apre la Salesforce Console for Service. Qui vivono gli accordi sul livello di servizio (SLA), tramite la gestione degli entitlement e le milestone, ed è qui che entra Knowledge, che la maggior parte delle edizioni acquista come componente aggiuntivo.

Platform (Salesforce Platform). Per le persone che hanno bisogno delle tue app personalizzate, non del CRM. Hanno account, contatti, report, dashboard, documenti e ogni app personalizzata della org. Cosa non hanno: previsioni, lead, campagne e opportunità. Costa meno, ed è esattamente per questo che tante grandi app personalizzate girano su di essa, ed esattamente per questo che può cogliere in fallo il tuo modello dati.

	Sales Cloud	Service Cloud	Platform
Licenza utente	Salesforce	Salesforce	Salesforce Platform
Pensata per	Vendere	Assistere i clienti	App personalizzate
Account, contatti	Sì	Sì	Sì
Lead, opportunità, previsioni	Sì	Sì	No
Casi	Sì, per vedere i casi di un cliente	Al centro, nella Service Console	No
Accordi sul livello di servizio	No	Sì, entitlement e milestone	No
Oggetti e app personalizzati	Sì	Sì	Sì

Leggi la tabella come la legge un architetto. Se un grande gruppo di utenti è su Platform, qualsiasi progetto che mette il loro lavoro su un’Opportunità è rotto prima ancora di partire. Se i dirigenti hanno bisogno dei numeri sugli SLA, è la licenza che hanno a decidere se possono vederli. Questi tre tipi determinano il comportamento.

Click to enlarge

Quando la licenza decide l’oggetto

L’Opportunità è la vittima in cui mi sono imbattuto più spesso. L’hai visto nella tabella: gli utenti Platform non ce l’hanno (Standard User Licenses (opens in a new tab)), e nemmeno gli utenti Customer Community possono lavorarci. Quindi il requisito sembra un’Opportunità, qualcuno dice “usiamo l’Opportunità”, e poi io chiedo chi ha bisogno di accedervi. Se una grande popolazione è su licenze Platform o Customer Community, la licenza non è più un dettaglio di acquisto. È un vincolo architetturale, e di solito spinge il progetto verso un oggetto personalizzato.

Funziona anche verso l’alto. In aula chiedo: l’amministratore delegato vuole dei bei dashboard; licenza Sales o Service? Un utente Sales vede gli oggetti di vendita e perfino i casi, quindi per dashboard di vendita e conteggi dei casi aperti Sales va bene. Ma nel momento in cui il dirigente vuole i KPI sugli SLA (quanto manca prima che un caso violi il suo livello di servizio), quei dati stanno negli entitlement e nelle milestone, e la gestione degli entitlement richiede Agentforce Service, già Service Cloud (Supported Editions for Service Features (opens in a new tab)). Ora stai aggiornando le licenze dei dirigenti. Ascolta il requisito di business, e sappi quale licenza c’è sotto i dati di cui ha bisogno.

Lo stadio

Penso alle licenze come ai posti in uno stadio. Tutti guardano la stessa partita. Se compro i posti costosi al centro, vedo da vicino entrambe le squadre. Se sono in curva, in alto, i sedili non sono imbottiti e guardo con il binocolo.

Sono le licenze esterne, per le persone fuori dall’azienda: clienti e partner che accedono a un sito Experience Cloud. Ce ne sono tre che voglio che tu conosca.

Customer Community: la curva. Pensata per un gran numero di utenti esterni che hanno bisogno di casi e knowledge: un cliente che controlla il suo caso di assistenza. I posti costano circa la metà e possono andare a un numero enorme di utenti. Cosa perdi lassù? Report, dashboard e la tabella di condivisione: la condivisione basata sui ruoli che hanno i livelli superiori. Funziona con gli account personali.

Customer Community Plus: circa a metà strada. Salesforce la descrive come la licenza per gli utenti esterni che hanno bisogno di report, dashboard e della condivisione standard: un cliente che gestisce l’accesso di altre persone, o che ha bisogno di vedere i suoi numeri.

Partner Community: ancora più vicino, per il business-to-business, con accesso ai dati di vendita. I partner lavorano su lead e opportunità: registrano trattative e gestiscono campagne insieme a te. È il posto esterno che arriva agli oggetti di vendita. Un limite: non si può usare con gli account personali (Experience Cloud User Licenses (opens in a new tab)).

Click to enlarge

L’errore è progettare come se tutti avessero il biglietto costoso, e poi scoprire durante l’implementazione che la maggior parte dei tuoi utenti non può entrare nel settore in cui hai messo i loro dati. A quel punto hai tre scelte: comprare posti diversi, spostare l’esperienza o riprogettare il modello. Tutte e tre sono architettura.

Il modo in cui pagano cambia il progetto

C’è un’altra domanda che si dimentica: come accederanno questi utenti? Le licenze esterne hanno due forme. Basate sui membri: paghi per utente, adatto a 500 partner che accedono ogni giorno. Basate sugli accessi: compri un numero di accessi al mese, adatto a cinque milioni di clienti che accedono qualche volta all’anno. Accedere più di una volta nello stesso giorno conta comunque come un solo accesso (Experience Cloud User Licenses (opens in a new tab)).

Quindi quando qualcuno dice “stiamo costruendo un portale clienti”, la mia domanda successiva non è quale modello. È: chi sono i clienti, quanti sono, quanto spesso vengono, di quali dati hanno bisogno, e cosa possono farci?

Quando la licenza dà forma al modello

A volte la licenza non sceglie solo l’oggetto; piega l’intero modello. Alcune licenze di piattaforma limitano gli utenti a un’app personalizzata con al massimo dieci oggetti personalizzati (Lightning Platform – One App, per esempio; Standard User Licenses (opens in a new tab)).

In un progetto dei primi tempi, per una grande azienda di servizi professionali e costruzioni, dovevamo realizzare qualcosa come LinkedIn per tutto il personale: i ruoli, le competenze, le certificazioni, le lingue e i progetti di ognuno, così da poter trovare il costruttore di ponti certificato in un certo paese. Senza limiti avrei costruito un oggetto utente-ruolo, utente-competenza, utente-certificazione, utente-lingua e utente-progetto, più gli elenchi di riferimento di certificazioni e progetti. Con una licenza da dieci oggetti, e con l’indicazione di non bruciarli tutti, non era possibile. Così è diventato un quiz musicale alla “indovina la canzone”: con quanti pochi oggetti riesco a costruirlo? La risposta è stata due. Un oggetto di riferimento, con un tipo di record per ogni tipo di elenco (ruolo, competenza, certificazione, lingua, progetto), e un oggetto attributo dell’utente, con tipi di record corrispondenti, che punta a esso.

Non era il modello ottimale. Era un tormento per la reportistica, e l’avrei preferito più pulito. Ma era ciò che la licenza permetteva. Li chiamo oggetti coltellino svizzero: tieni il pattern in tasca, e quando i limiti non lasciano spazio, rompi il vetro e passa alla separazione per tipo di record. Sappi solo cosa stai scambiando. Autorizzazioni diverse per tipo di record possono costringerti comunque a dividere l’oggetto.

Le persone non sono più gli unici utenti

Un’altra domanda sulle licenze è diventata importante: e le cose che non sono persone? Le integrazioni hanno identità. Gli agenti hanno identità. Salesforce ora ha una licenza Salesforce Integration per le integrazioni da sistema a sistema: solo API, non per persone, con cinque licenze incluse in ogni org Enterprise, Unlimited e Performance Edition (Standard User Licenses (opens in a new tab)). Quindi non chiederti solo quali utenti hanno bisogno di accesso. Chiediti quali identità ne hanno bisogno: una persona, un cliente, un partner, un’integrazione, un agente. E poi cosa deve vedere e fare ciascuna.

Oltre l’esame: cosa cambia l’IA. Man mano che gli agenti diventano un altro consumatore e creatore di dati, la scelta degli oggetti e le licenze non riguardano più solo le schermate per le persone. Sappi con quale identità gira l’agente, cosa può raggiungere quell’identità, e se il modello mette i dati di cui ha bisogno dietro un oggetto o un’autorizzazione che non può usare.

Steve Trucking: un caso facile e uno difficile

Steve Trucking lavora con i Partner retail. Cos’è un Partner retail? Un’azienda. Facile: Account. Non creo Retail_Partner__c perché qualcuno ha usato la parola “partner”.

Ora il Destinatario, la persona che riceve il frigorifero. Contatto? Account personale? Qualcos’altro? Un milione di nuovi Destinatari all’anno, che sono clienti dei Partner retail, non nostri. È esattamente il tipo di domanda in cui non voglio saltare a un oggetto prima di aver capito la relazione, l’accesso e la scala. Lo decideremo al checkpoint della Parte 1.

Cosa decide qui un architetto

• Se un concetto di business si adatta in modo pulito allo scopo previsto di un oggetto standard, o se il suo significato o il suo peso sono diversi.
• Se etichette di business diverse sono entità diverse o solo ruoli diversi della stessa entità.
• Se ogni persona, utente esterno, integrazione e agente che ha bisogno dei dati può raggiungere l’oggetto scelto con le licenze previste.
• Come la popolazione e il modello di accesso (basato sui membri o sugli accessi) danno forma alla licenza e al modello.
• Quando un limite di licenza giustifica un modello meno che ottimale, e quanto costa quello scambio in reportistica e autorizzazioni.

Il punto non è che gli oggetti standard siano buoni e quelli personalizzati cattivi. È che la scelta ha conseguenze, e a volte non la decide affatto il sostantivo, ma le persone, e le macchine, che devono usarlo.

Per approfondire

• Guida di Salesforce, Standard User Licenses (opens in a new tab) (in inglese), consultato il 2026-10-02, ricontrollato il 2026-10-12: gli utenti Platform non hanno diritto a previsioni, lead, campagne e opportunità; un’app personalizzata con al massimo 10 oggetti personalizzati; cinque licenze Salesforce Integration in ogni org Enterprise Edition.
• Guida di Salesforce, Experience Cloud User Licenses (opens in a new tab) (in inglese), consultato il 2026-10-02, ricontrollato il 2026-10-12: Partner Community non si può usare con gli account personali; Customer Community Plus per report, dashboard e condivisione standard; più accessi nello stesso giorno contano come uno.
• Guida di Salesforce, Supported Editions for Service Features (opens in a new tab) (in inglese), consultato il 2026-10-02, ricontrollato il 2026-10-12: accordi sul livello di servizio (gestione degli entitlement) con Agentforce Service; Knowledge a costo aggiuntivo nella maggior parte delle edizioni.
• Guida di Salesforce, Available Feature Licenses (opens in a new tab) (in inglese), consultato il 2026-10-12: Service Cloud User, “Access the Salesforce Console for Service”; Marketing User per creare e gestire le campagne.