Sales Cloud «avanzato» è la catena che porta una voce di catalogo fino a un ordine firmato, più i due strumenti con cui il management la legge: forecast e territori. L’esame ci appoggia sopra Knowledge, che vive nel mondo Service ma pone la stessa domanda di fondo: chi vede cosa, e in che stato è il record.

Product, price book e list price

Un Product è la voce di catalogo ed esiste una volta sola. Il prezzo non sta sul prodotto: sta sulla riga che lega prodotto e listino (PricebookEntry). Da qui la regola che l’esame usa in continuazione: lo stesso prodotto ha tanti prezzi quanti sono i listini in cui è inserito.

Standard Price Book Price book custom
Quanti uno solo, creato da Salesforce quanti ne servono
Cosa contiene lo standard price di ogni prodotto il list price valido per quel segmento
Come si popola prezzo standard sul prodotto Related → Add Products, poi si digita il nuovo list price
Flag — Active: se non è spuntato, il listino non è utilizzabile

Le schedule (revenue e quantity) spalmano un prodotto nel tempo: invece di una riga da un importo unico, l’opportunity product genera rate periodiche. Si abilitano per l’organizzazione e poi sul singolo prodotto, scegliendo se schedulare il ricavo, la quantità o entrambi. «Si fattura mese per mese ma è un solo prodotto» è una schedule, non dodici righe.

Chi vede quale listino

L’accesso ai listini è governato da un org-wide default dedicato all’oggetto Price Book, non dai permessi su Product e non dalla proprietà dell’opportunity. I livelli sono tre, e la distinzione fra i due superiori è esattamente ciò che l’esame chiede:

Livello Cosa permette
No Access il listino non compare nemmeno
View Only aprire il price book e leggerne i list price; non usarlo per aggiungere prodotti a un’opportunity
Use aprirlo e aggiungerne i prodotti a opportunity, quote e ordini

Il pattern è: OWD restrittivo sull’oggetto, poi sul singolo price book si apre Sharing e si concede Use a Roles and Subordinates per chi vende su quel listino, lasciando View Only a chi deve solo consultarlo. Due canali con listini diversi si risolvono così, non con due profili né con un record type.

Preventivi: molti, ma uno solo sincronizzato

Su una stessa opportunity si creano quante quote servono, una per configurazione dell’offerta. La frase che l’esame gira in tutti i modi è una sola: «An opportunity can have multiple quotes, but it can sync with only one quote at a time.»

Sincronizzare significa che «the quote and the opportunity are synced so updates to one record are always reflected in the other»: le righe della quote diventano gli opportunity product e l’importo dell’opportunity segue il preventivo, in entrambe le direzioni. L’opportunity tiene traccia del preventivo attivo nel campo Synced Quote; avviare la sincronizzazione su una seconda quote sposta il collegamento, non ne crea un secondo. Le altre quote restano sul record ma non pilotano più nulla.

Il PDF si genera dalla quote con Create PDF e Save to Quote: il file finisce in Notes & Attachments del preventivo, da dove si scarica o si invia.

Dall’accettazione all’ordine

Accettato il preventivo, quello che il cliente si è impegnato a comprare si registra su un Order: si crea con Account Name, il Contract Number del contratto firmato e un Order Start Date, e i prodotti si aggiungono con Add Products scegliendo il price book da cui pescarli, come su un’opportunity. Segue il passo di attivazione: finché è in bozza l’ordine è un documento di lavoro, con l’attivazione diventa l’impegno di riferimento. Quote e Order rispondono a domande diverse, «cosa proponiamo» contro «cosa è stato ordinato», e vivono su rami diversi: la quote sull’opportunity, l’ordine su account e contratto.

Forecast: categorie, gerarchia, rollup

Un forecast type definisce l’oggetto su cui si prevede, se si misura ricavo o quantità, la data di riferimento e il tipo di gerarchia. La forecast hierarchy è «automatically generated from the user role hierarchy», oppure costruita sui territori. Il forecast manager «can view and adjust forecasts for people one level below them in the hierarchy»: senza forecast manager, ciascuno vede e corregge solo il proprio numero.

Le forecast category derivano dallo stage dell’opportunity. Il punto che l’esame ama è il rollup method:

Metodo Cosa mostra una colonna
Per singola categoria «include opportunities in the given category only»
Cumulative «combine opportunities into cumulative totals for a given forecast category, and all subsequent categories»

Se il management vuole il Closed già dentro il Commit, e nel Best Case il Commit più il Closed, la risposta non è un report né un campo formula: sono i cumulative forecast rollup. Le quota, caricate per periodo e utente, fanno leggere il forecast come percentuale di obiettivo.

Territori: matrice, non catena

La role hierarchy è «perfect for modeling management and Human Resources types of reporting structures, where one person reports only to another person». La territory hierarchy è «best for modeling a matrix reporting structure, where someone can report to multiple managers». Sono due assi diversi e la raccomandazione ufficiale è esplicita: non duplicarli — «duplicating the territory structure in the sales branch of the role hierarchy is unnecessary and redundant».

È la risposta quando i ruoli devono restare la catena di riporto ma l’accesso agli account deve seguire la geografia: Enterprise Territory Management assegna gli account ai territori con assignment rule su filter criteria (campi dell’account, se serve normalizzati in un campo formula) e concede l’accesso ai membri del territorio, senza torcere i ruoli. Per il forecast per territorio serve poi un forecast manager su ogni territorio di cui si vuole il totale. Nota di scala: le assignment rule vengono rivalutate su tutti gli account anche quando ne cambia uno solo, e territori troppo capienti degradano le prestazioni.

Knowledge: tipo di articolo, categorie, versioni

In Lightning Knowledge l’articolo è un record come gli altri e si modella con gli strumenti standard. I record type «determine the page layouts and picklist values users have access to»: How To e FAQ portano layout e campi diversi, e si rendono disponibili spuntando Make Available sui profili.

Le data category sono l’altra metà: si raggruppano in un category group, si organizzano ad albero sotto il nodo All e vanno attivate (il gruppo passa da Inactive Category Groups ad Active Category Groups). La visibilità è un impianto separato dai permessi: si imposta in Default Data Category Visibility per ruolo e, quando serve, dentro il singolo permission set con Category Group Visibility. Un agente può avere la Knowledge User license, la lettura sull’oggetto e il permission set giusto, e non vedere comunque gli articoli di una categoria: non è un problema di licenza, è la visibilità di categoria.

Il ciclo di vita è a versioni. L’articolo nasce in Draft e si pubblica; per correggerne uno pubblicato si usa Edit as Draft, che riporta la Publication Status a Draft lasciando online la versione pubblicata finché non si ripubblica con Flag as New Version. Ne nasce una nuova voce nella tab Versions: i lettori non vedono mai il cantiere. L’archiviazione toglie l’articolo dalla circolazione senza cancellarlo.

Trappole tipiche d’esame

  • View Only contro Use sul price book. «Deve poter aprire il listino e leggere i prezzi» è View Only; «deve poter aggiungere quei prodotti alla sua opportunity» è Use. Il distrattore è sempre un permesso sull’oggetto Product o un profilo: l’accesso al listino si concede sul price book.
  • Il prezzo non è un campo del prodotto. Lo stesso Product ha un list price per ogni listino: chi lo cerca su un campo del prodotto non trova mai la riga giusta.
  • Sincronizzare la seconda quote non aggiunge, sostituisce. Una sola quote per volta pilota l’opportunity, e la sincronizzazione è bidirezionale: modificare l’opportunity cambia anche il preventivo sincronizzato.
  • Cumulative rollup contro categoria singola. «Il Commit deve già contenere il closed» descrive un rollup cumulativo, non un report personalizzato né una modifica delle forecast category.
  • Territori contro ruoli. Quando l’accesso deve seguire la geografia ma la gerarchia dei ruoli deve restare la catena di riporto, la risposta è Enterprise Territory Management: non un ramo aggiuntivo di ruoli, non una sharing rule su un campo geografico.
  • Knowledge: permessi e data category sono due porte diverse. Licenza e lettura sull’oggetto aprono l’articolo; senza visibilità sulla categoria l’articolo non compare. E un Edit as Draft non oscura la versione pubblicata: resta online finché non pubblichi la nuova.