Report, dashboard e visibilita

Un report in Salesforce non contiene dati: contiene una domanda. I dati arrivano nel momento in cui qualcuno lo esegue, e arrivano filtrati dai permessi di chi lo sta eseguendo. E’ per questo che due colleghi possono aprire lo stesso report nella stessa cartella e vedere numeri diversi: non e’ un bug, e’ il modello di sicurezza che fa esattamente il suo mestiere.

L’esame gioca quasi sempre su questa separazione. Tienila a mente come due domande distinte, da porsi sempre nell’ordine:

1. L’utente puo’ aprire il report? Dipende dalla cartella.
2. Quali righe compaiono dentro? Dipende dall’accesso ai record e ai campi.

La cartella decide chi apre, non cosa vede

Report e dashboard vivono in cartelle, e la cartella si condivide separatamente dal contenuto. Una cartella puo’ essere privata (solo il proprietario), pubblica per tutta l’org, o condivisa con ruoli, ruoli e subordinati, gruppi pubblici o territori. Su ciascun destinatario si sceglie un livello di accesso alla cartella:

Il punto che l’esame sfrutta: nessuno di questi tre livelli aggiunge una sola riga di dati. Dare Manager su una cartella a un utente che non ha accesso ai record non gli mostra niente di piu’; gli permette solo di riorganizzare report vuoti.

Le righe: i quattro livelli di accesso

Il report interroga cio’ che l’utente gia’ puo’ vedere, attraverso i quattro livelli del modello di sicurezza: organizzazione, oggetto, record, campo.

• Oggetto — senza il permesso Read sull’oggetto (da profilo o permission set) l’utente non vede il report type e non vede nulla di quell’oggetto. E’ il livello che spiega il report che non e’ nemmeno selezionabile.
• Record — qui vive la maggior parte delle domande. La base e’ l’org-wide default: Private significa che solo il proprietario e chi gli sta sopra nella role hierarchy vede e “reporta” su quei record; Public Read Only che tutti vedono e reportano ma solo il proprietario e i suoi superiori modificano; Public Read/Write che tutti vedono e modificano. Sopra a questa base si aggiungono, solo in senso ampliativo, role hierarchy, sharing rule (owner-based o criteria-based, spesso verso un Public Group) e manual sharing.
• Campo — la field-level security. Questa e’ la parte che la guida d’esame chiama “sharing fields” e va letta con attenzione: le field permission controllano la visibilita’ del campo in ogni parte dell’applicazione, related list, list view, ricerca e report compresi, mentre il page layout governa solo le pagine di dettaglio e modifica. Un campo nascosto in FLS sparisce dal report anche se resta sul layout: rimuoverlo dal layout non e’ una protezione, nasconderlo in FLS lo e’.

Da qui la diagnosi del classico caso “vedo le intestazioni di colonna ma zero righe”: la cartella e’ condivisa (il report si apre), l’oggetto e’ accessibile (le colonne si disegnano), ma l’utente non ha accesso a nessun record che soddisfi i filtri. Se poi lo stesso utente apre singoli record dal tab dell’oggetto, il sospetto si stringe ulteriormente: non e’ un problema di permesso sull’oggetto, e’ un problema di record-level sharing o di filtri del report che escludono la sua porzione di dati.

Stesso ragionamento per il manager che vede solo le proprie opportunita’ con OWD Private. Le soluzioni corrette sono quelle che ampliano l’accesso ai record: metterlo in un ruolo superiore a quello del team nella role hierarchy, oppure creare una sharing rule che condivida i record del gruppo con lui. Le soluzioni sbagliate, e ricorrenti fra i distrattori, sono quelle che toccano altro: cambiare la cartella, cambiare profilo o permission set, modificare i filtri del report.

Dashboard: componenti, sorgenti, grafici

Una dashboard e’ un insieme di widget (componenti). Ogni widget mostra testo, un’immagine, oppure i dati di un solo report: non si sommano due report in un componente, e un report puo’ alimentare piu’ componenti. Le forme disponibili vanno dai grafici (barre verticali e orizzontali, barre impilate, linee, ciambella, imbuto, dispersione) al gauge per un valore dentro un intervallo, alla metrica per un numero singolo, alla Lightning table per i dati in colonna; le impostazioni del componente scelgono raggruppamento, misura, intervallo e decimali.

Sulle sorgenti valgono due vincoli da ricordare. Gli historical trend report non sono ammessi come sorgente. I joined report, invece, sono un caso da maneggiare con cura: molta documentazione e molto materiale di preparazione affermano ancora che non possono alimentare un componente, ma dal Winter ‘19 un joined report puo’ essere sorgente di un componente di tipo grafico, a condizione che il report abbia un suo grafico; il componente ne eredita il grafico anziche’ offrire tutte le opzioni consuete, e le funzionalita’ di dashboard che dipendono dai campi del report (tipicamente i filtri) non sono disponibili. In sede d’esame la risposta ragionevole e’ che il joined report si puo’ visualizzare, con limitazioni, non che sia vietato.

Chi e’ l’utente che “esegue” la dashboard

Una dashboard non si esegue da sola: mostra i dati di un utente. La proprieta’ si chiama View Dashboard As e cambia completamente il significato della stessa dashboard.

Quando il requisito e’ “una sola dashboard, e ognuno vede solo cio’ che il proprio accesso consente”, la risposta e’ la dashboard dinamica. Attenzione pero’ ai suoi vincoli, che sono terreno fertile per i distrattori: non si salva in una cartella privata, il numero di dashboard dinamiche per org e’ limitato e dipende dall’edition (Enterprise, Unlimited e Performance hanno tetti diversi: vanno verificati nella propria org, non ricordati a memoria), e storicamente non ne e’ previsto l’aggiornamento schedulato ne’ la sottoscrizione.

Per il resto, una dashboard si puo’ sottoscrivere: il sottoscrittore riceve per email l’aggiornamento secondo la cadenza scelta, e la sottoscrizione specifica anche come vengono eseguiti i dati inviati. L’aggiornamento schedulato e’ la via per avere numeri freschi a un orario fisso. I filtri di dashboard, infine, si aggiungono scegliendo un campo e dei criteri: filtrano tutti i componenti compatibili, ma non cambiano nulla dei permessi — non mostrano mai un record che il running user non potrebbe vedere.

Trappole tipiche d’esame

• Cartella e dati sono due cose diverse. Viewer, Editor, Manager regolano l’accesso al report come oggetto, mai alle righe. Se il testo dice “vede le colonne ma nessun record”, la causa e’ nell’accesso ai record, non nella condivisione della cartella.
• Il page layout non nasconde niente sul serio. Tolto il campo dal layout, resta in report, list view e ricerca. Solo la field-level security lo fa sparire ovunque; e quando l’esame descrive un campo nascosto in FLS ma lasciato sul layout, l’utente semplicemente non vede quel campo sulla pagina, senza errori e senza righe mancanti.
• Le sharing rule ampliano, non restringono. Non possono essere piu’ strette dell’org-wide default e hanno senso solo con OWD Private o Public Read Only. Un distrattore che “usa una sharing rule per togliere accesso” e’ sempre sbagliato.
• Profilo e permission set non risolvono un problema di record. Danno accesso all’oggetto e ai campi; per far comparire i record di altri servono role hierarchy, sharing rule, manual sharing, team.
• Running user fisso contro dashboard dinamica. “Tutti vedono gli stessi numeri” e’ un running user fisso; “ognuno vede i propri” e’ una dashboard dinamica. Se la domanda aggiunge cartella privata, schedulazione o sottoscrizione, la dashboard dinamica diventa la risposta sbagliata.
• Un componente, un report. Chi cerca di unire due report in un widget sbaglia; e prima di dare per vietato un joined report come sorgente, ricorda che quel divieto e’ caduto da diverse release.