Un amministratore passa buona parte del suo tempo a rispondere a due domande che sembrano parenti ma non lo sono: «perché questo record non si salva?» e «chi ha cambiato questa cosa?». La prima riguarda cosa succede dentro una transazione; la seconda riguarda cosa è già successo e chi l’ha fatto. Salesforce ha strumenti diversi per l’una e per l’altra, e l’esame vive quasi interamente sulla differenza. A questo si aggiunge un terzo tema, che sta nello stesso obiettivo: come si tratta un dato sensibile quando deve stare in produzione e quando viene copiato in una sandbox.

Il debug log: una scatola nera che devi accendere prima

Il debug log registra l’interno di una transazione: l’ordine di esecuzione, quali validation rule scattano, quali flow, trigger, workflow field update e assignment rule intervengono, quali limiti di governor vengono consumati, quali eccezioni vengono lanciate. È lo strumento giusto quando un singolo utente vede un errore che nessun altro riproduce e l’oggetto ha più automazioni sovrapposte: solo il log ti dice quale automazione ha bloccato il salvataggio.

Si accende in due modi. Dalla Developer Console, con Debug → Change Log Levels, per quello che fai tu nella tua sessione. Oppure — ed è il modo che l’esame preferisce, perché è quello che serve per un altro utente — da Setup → Debug Logs, creando un trace flag sull’utente da osservare: si sceglie l’entità tracciata, una finestra di inizio e fine, e un debug level, cioè l’insieme dei livelli assegnati a ciascuna categoria (Apex Code, Workflow, Validation, Database, Callout, System, Visualforce). I livelli sono cumulativi e vanno da NONE a FINEST passando per ERROR, WARN, INFO, DEBUG, FINE, FINER. Per capire quale automazione fallisce servono Workflow e Validation alzati; per l’Apex serve Apex Code.

Il punto su cui si costruiscono le domande è questo: il debug log non è retroattivo. Genera righe solo per le transazioni che avvengono mentre il trace flag è attivo, e il trace flag ha una scadenza. Se l’errore è già accaduto e nessun log era acceso, il debug log non ti serve a niente: devi riprodurre il problema con il trace flag attivo. Sullo stesso oggetto batte anche il tema degli intermittenti: se l’errore si presenta una volta ogni tanto, il log può riempirsi di transazioni innocue prima che arrivi quella buona. Salesforce dichiara che ogni singolo log non può superare i 20 MB (oltre, viene troncato) e che l’org conserva fino a 1.000 MB di log complessivi, dopodiché i più vecchi vengono sovrascritti. Trattali come ordini di grandezza da verificare alla fonte, non come cifre da mandare a memoria: la sostanza è che il debug log è volatile, non è un archivio.

Per leggerlo si usa il Log Inspector della Developer Console (Debug → Perspective Manager), con tab come Timeline, Executed Units ed Execution Log. Nella stessa console, Execute Anonymous esegue Apex al volo e ne scrive l’output nel debug log: è il modo in cui un admin verifica un’ipotesi senza toccare la configurazione.

Setup Audit Trail: chi ha toccato la configurazione

Il Setup Audit Trail è l’opposto del debug log: è sempre acceso, non va configurato e non si spegne, e registra le modifiche alla configurazione — chi, cosa, quando. Disattivare una validation rule, creare o modificare un profilo o un permission set, aggiungere un campo, attivare un flow, cambiare le password policy, creare un utente, rinfrescare una sandbox: tutto questo finisce lì. Si consulta da Setup → View Setup Audit Trail, che mostra le voci più recenti e permette di scaricare un CSV della finestra pubblicata da Salesforce (indicata in sei mesi; è un valore da riverificare, non da citare a occhi chiusi).

E qui c’è la confusione che l’esame usa più spesso: il Setup Audit Trail non registra le modifiche ai dati. Se stanotte qualcuno ha disattivato una validation rule e ha cambiato il campo Amount su alcune opportunità, l’audit trail ti dà il primo fatto e non il secondo. Il secondo si ricostruisce solo con la field history dell’oggetto, e solo se il tracking su quel campo era già attivo — anche la field history, come il debug log, non è retroattiva.

Scegliere lo strumento: la tabella che risolve gli scenari

Strumento Cosa registra Quando è disponibile Va predisposto prima? Licenza
Debug log Esecuzione interna di una transazione (automazioni, limiti, errori) Solo con trace flag attivo Sì, obbligatorio Inclusa
Setup Audit Trail Modifiche alla configurazione (metadati), con utente e data Sempre, retroattivo nella finestra pubblicata No Inclusa
Field History Tracking Vecchio e nuovo valore dei campi tracciati Da quando è attivo il tracking Sì, campo per campo Inclusa
Field Audit Trail Stessa cosa, con più campi e conservazione lunga Da quando è attivo Sì Shield
Event Monitoring (EventLogFile) Attività utente: login, export di report, chiamate API, click Dopo: oraria o giornaliera No Shield / add-on
Transaction Security Nulla: interviene mentre l’azione accade In tempo reale Sì, va scritta la policy Shield / add-on

Le ultime due righe sono la coppia che l’esame contrappone. Event Monitoring è analisi a posteriori: i file di log degli eventi si scaricano via API e arrivano con ritardo (orario per chi ha la licenza, giornaliero altrimenti), quindi servono a capire cosa è successo, non a impedirlo. Transaction Security è il contrario: valuta l’evento nel momento in cui accade e può bloccare l’operazione, chiedere l’autenticazione a più fattori, inviare una notifica, o non fare nulla (modalità utile per collaudare la policy). Se lo scenario dice «l’export va fermato mentre avviene e il team di sicurezza va avvisato», la risposta è una policy di Transaction Security, non un report sugli event log.

Dati sensibili fuori dalla produzione: Salesforce Data Mask

Una sandbox Full contiene una copia dei dati veri. Se ci lavorano fornitori esterni, il problema non è tecnico ma legale. Salesforce Data Mask risolve offuscando i dati nella sandbox, lasciando la produzione intatta.

La procedura ha una geografia precisa, ed è il punto che le domande verificano: il pacchetto gestito si installa in produzione, la configurazione si può preparare in produzione (e viene ereditata dalla sandbox alla creazione o al refresh) oppure direttamente nella sandbox, ma il job di mascheramento si lancia dalla sandbox, dal tab Data Mask Home. Funziona su sandbox full e partial. E soprattutto: il mascheramento è irreversibile, non esiste un «unmask».

Per ogni campo si sceglie una fra tre tecniche:

Tecnica Risultato Quando usarla
Replace with Random Characters/Numbers Valori illeggibili (Blake → gB1ff95-$) Il dato deve sparire ma il campo deve restare valorizzato
Replace From Library Valori finti ma realistici (nomi, indirizzi, telefoni) Serve un collaudo end-to-end credibile
Delete Campo svuotato Il dato non serve affatto al test

Se il requisito è «i contractor non devono vedere dati veri, ma i record devono restare realistici per il test end-to-end», la scelta è Replace From Library, non Delete. Attenzione: campi checkbox, lookup e picklist non sono supportati.

Dati sensibili dentro la produzione: Shield

In produzione il dato sensibile non si cancella: si cifra. Shield Platform Encryption cifra a riposo con una gerarchia di chiavi (primary secret di Salesforce, tenant secret dell’org, root key, data encryption key derivata, più salt e initialization vector) e offre due schemi:

  • probabilistico: IV casuale a ogni cifratura, quindi ciphertext sempre diverso. Più sicuro, ma impedisce filtri, ordinamenti e report sul campo;
  • deterministico: IV statico per campo, stesso ciphertext per lo stesso valore. Leggermente meno robusto, ma consente il filtro per corrispondenza esatta e le clausole WHERE.

Quindi, se un campo custom National ID su Contact deve essere cifrato a riposo e il team di conformità deve poter filtrare un report su un valore esatto, la risposta è la cifratura deterministica: con quella probabilistica il requisito del filtro cade.

Il terzo componente Shield è Field Audit Trail, che va dove la field history standard non arriva. La field history standard traccia fino a 20 campi per oggetto e conserva il dato 18 mesi nell’interfaccia e fino a 24 mesi via API; Field Audit Trail sale fino a 200 campi per oggetto e permette di definire una retention policy (dopo quanti mesi la storia viene archiviata e per quanti anni resta in archivio), con la storia archiviata consultabile dal Field History Explorer, l’app Shield che filtra le modifiche per utente, campo e data senza scrivere una riga di codice. È esattamente la risposta allo scenario «un regolatore ci chiede di mostrare per anni ogni modifica a pochi campi di Contract, e gli auditor devono poterle rivedere da dentro la produzione».

Trappole tipiche d’esame

  • Il debug log non racconta il passato. Se l’incidente è già avvenuto e nessun trace flag era attivo, non esiste modo di recuperare il log: si predispone il trace flag sull’utente e si riproduce. Le opzioni che promettono di «recuperare i log di stanotte» sono sempre sbagliate.
  • Setup Audit Trail = metadati, field history = dati. Una validation rule disattivata sta nell’audit trail; un Amount modificato su dieci opportunità no. Uno scenario che mescola le due cose vuole due strumenti, non uno.
  • Event Monitoring guarda indietro, Transaction Security interviene adesso. «Bloccare l’operazione mentre accade» esclude gli EventLogFile, che arrivano con ore di ritardo. «Capire chi ha esportato cosa il mese scorso» esclude Transaction Security, che non è un archivio.
  • Data Mask: si installa in produzione, si esegue dalla sandbox, e non si torna indietro. Le distrattoli classiche sono «si installa nella sandbox», «maschera anche i dati di produzione» e «si può annullare».
  • Deterministico contro probabilistico. Ogni volta che una domanda chiede di cifrare e di filtrare, ordinare o fare report per valore esatto, la cifratura probabilistica è la risposta sbagliata. Se invece la domanda non chiede il filtro, la probabilistica è la scelta più sicura.
  • Conservazione lunga = Field Audit Trail, non field history standard. «Diversi anni» e «più di venti campi» sono i due segnali che spostano la risposta su Shield; il Field History Explorer è l’interfaccia con cui gli auditor leggono quell’archivio dentro la produzione.