La sezione Data and Analytics Management mette insieme due mestieri: tenere pulito il dato e farlo raccontare. Le domande sono scenari, e la risposta corretta non e lo strumento piu potente ma quello proporzionato al requisito.

Prima si misura, poi si corregge

Un programma di qualita del dato che parte dalle correzioni e cieco: non sa da dove viene e non sapra di essere riuscito. Le sei metriche che lo fotografano sono le parole che ritrovi negli scenari.

Metrica Domanda a cui risponde
Age quando e stato aggiornato l’ultima volta ogni record? (Last Modified Date)
Completeness i campi chiave sono valorizzati, o restano vuoti?
Accuracy il dato e stato confrontato con una fonte attendibile?
Consistency formato, ortografia e lingua sono gli stessi ovunque?
Duplication quanti record descrivono la stessa entita?
Usage il dato viene davvero usato in report, dashboard e app?

Quando qualcuno chiede una baseline su account, contact e lead — «dove siamo oggi», «prima di partire» — la risposta attesa non e un report scritto a mano: e la Data Quality Analysis Dashboards App, pacchetto gratuito da AppExchange con dashboard gia pronte su eta, completezza, uso e duplicazione.

Gli strumenti di miglioramento, e cosa ciascuno non risolve

Strumento Difetto che risolve Quello che non risolve
Tipo di campo (Date, Currency, Picklist) formati liberi, ortografie divergenti dato assente
Campo obbligatorio sul page layout campo lasciato vuoto dato che l’utente non possiede
Validation Rule valori fuori formato o incoerenti dato che nessuno in azienda conosce
Flow assegnazioni e normalizzazioni automatiche qualita della fonte
Duplicate Management record doppi completezza
Arricchimento da fonte esterna firmografici mancanti o stantii regole di inserimento

La riga da ricordare e la seconda. Rendere obbligatorio un campo che l’utente non e in grado di compilare non produce dato, produce rumore: il rep scrive N/A o 0 pur di salvare, la completezza sale e l’accuratezza crolla. Per industry, dipendenti e fatturato la strada e l’arricchimento contro una fonte attendibile: app di terze parti sul marketplace Salesforce, che le pagine recenti indicano sotto Data Apps (la vetrina e stata rinominata di recente: verifica il nome corrente).

Duplicate Management: due regole, non una

Il meccanismo e a due stadi e l’esame verifica quale dei due configuri.

  • La matching rule definisce come si riconosce un duplicato: quali campi confrontare e con quale algoritmo, Exact oppure Fuzzy (accosta «Margaret Chan» e «Maggie Chan», o due varianti della stessa via su Mailing Street). Si crea e si attiva da Setup, voce Matching Rules; ne esistono di standard per account, contact e lead.
  • La duplicate rule definisce cosa succede quando la matching rule trova qualcosa, e punta a una matching rule: senza quella, non fa nulla.
Azione Effetto sull’utente Quando sceglierla
Allow + Alert avviso al salvataggio con i record simili elencati; si puo proseguire informare senza fermare il lavoro
Block il salvataggio non avviene il duplicato e inaccettabile per policy
Report i match confluiscono nei duplicate record set misurare prima di irrigidire

Report non e alternativo ad Alert: si spunta insieme all’azione scelta ed e cio che alimenta i dati analizzabili.

Due dettagli che valgono punti. Una duplicate rule vive su un oggetto ma puo confrontarlo con un altro: la rule su Lead con matching rule su Contact e lo scenario «il rep crea un lead per una persona gia a sistema come contatto», e l’avviso arriva al salvataggio. I match finiscono in Duplicate Record Set e Duplicate Record Item; per leggerli serve un custom report type che parta dall’oggetto (per esempio Accounts) e includa Duplicate Record Items. Il consolidamento resta il merge, che elegge un master e vi riporta valori e relazioni figlie.

Archiviare, cancellare, fare backup

Cosa fa Cosa non ti da
Backup copia il dato fuori dalla produzione lasciando l’originale al suo posto, per il ripristino dopo guasti ed errori non libera storage, non e una retention policy
Archiviazione sposta il dato storico fuori dall’uso quotidiano mantenendolo consultabile per audit e analisi non protegge da una cancellazione accidentale
Purge elimina definitivamente, a retention scaduta nessun ritorno indietro

L’archiviazione si governa con una archiving policy, che sposta i record dopo un periodo di retention, affiancata da una purge policy, che definisce quando i dati gia archiviati vengono rimossi. I candidati si scelgono per eta (Created Date, Last Modified Date, ultima attivita) e per rilevanza di business, conservando il minimo contesto storico utile — date, identificativi, importi — perche il record archiviato deve restare leggibile, non solo esistere.

Scegliere lo strumento analitico giusto

Requisito dello scenario Strumento
Oggetti che nessun report type standard mette insieme custom report type
Serie storica di un valore che l’org non conserva reporting snapshot
Poche categorie dai valori di un campo, senza creare campi bucket column
Calcolo su valori gia aggregati (percentuali, rapporti fra somme) custom summary formula
Blocchi di dati eterogenei affiancati nello stesso report joined report
Filtrare il padre per presenza o assenza di figli cross filter
Un cruscotto solo, ciascuno vede i propri dati dynamic dashboard
Un cruscotto solo, tutti vedono tutto ma una fetta per volta dashboard filter

La bucket column si aggiunge dal tab Outline del report builder, voce Add Bucket Column: vive dentro quel report, non e un campo dell’oggetto. Si usa per raggruppare, ordinare e filtrare come un campo normale; i valori non assegnati finiscono in Other, e per i bucket numerici c’e l’opzione che tratta i vuoti come zero.

La custom summary formula si aggiunge dallo stesso tab, con Add Summary Formula, e funziona su report summary o matrix, perche ha bisogno di raggruppamenti su cui posarsi. Il caso «quanto pesa questo gruppo sul totale» si risolve con PARENTGROUPVAL, che legge il valore di un raggruppamento superiore: la somma del gruppo divisa per il gran totale da una percentuale che si ricalcola quando il report viene filtrato, cosa che un campo formula sull’oggetto non puo fare.

Il cross filter aggiunge una condizione WITH o WITHOUT sull’oggetto figlio, con eventuali sottofiltri sui suoi campi. Il punto sfruttato dall’esame: l’output resta un report del solo padre, senza colonne del figlio e senza custom report type da creare. «Gli account con almeno un case in stato Escalated» e un report Accounts con WITH Cases e sottofiltro su Status.

Il reporting snapshot si configura da Setup, voce Reporting Snapshots: report sorgente, oggetto target (tipicamente un custom object), mappatura campo per campo, schedulazione. Ogni esecuzione scrive righe nuove sul target: la serie storica sono quelle, e i report di trend si costruiscono li.

Trappole tipiche d’esame

  • Matching rule contro duplicate rule, Alert contro Block. «Quali campi rendono simili due record» e la matching rule; «cosa succede al salvataggio» e la duplicate rule, che senza una matching rule attiva non avvisa nessuno. «Avvisare il rep lasciandolo proseguire» e Allow con Alert, non Block; e i duplicati fra oggetti diversi si ottengono puntando la matching rule sull’altro oggetto, non attivando due regole separate.
  • Campo obbligatorio contro dato mancante. Se i rep inseriscono segnaposto, non si risolve con altri campi obbligatori ne con una validation rule: e un difetto di origine del dato, e la risposta e l’arricchimento.
  • Archiviazione contro backup. Il backup lascia l’originale in produzione e serve al ripristino; l’archiviazione sposta il dato e libera storage, ma non e una rete contro la cancellazione accidentale.
  • Bucket column contro campo. Il bucket esiste solo nel report che lo contiene: se serve «anche in un altro report, in una list view o in una validation rule», non basta.
  • Dynamic dashboard contro dashboard filter. «Tutti hanno diritto a vedere tutto e vogliono cambiare vista» e un filtro su un’unica dashboard; la dynamic dashboard serve quando ciascuno deve vedere solo i propri dati, e non si salva in una cartella privata.
  • Joined report e dashboard. Un joined report puo essere sorgente di un componente dashboard, tramite il chart del report, fin dal rilascio Winter ’19: alcune pagine di training affermano ancora il contrario. Quando una fonte dice che qualcosa «non si puo fare», trattalo come un sospetto.