"View All / Modify All" in Salesforce: il bypass da sorvegliare

Gran parte del modello di sharing di Salesforce consiste nel concedere con attenzione l’accesso ai record. View All e Modify All mandano all’aria tutto questo: permettono a un utente di vedere o modificare qualsiasi cosa, ignorando completamente lo sharing. Sono essenziali per gli admin e pericolosi quando si diffondono. Ecco cosa fanno e come tenerli sotto controllo.

Cosa fanno davvero

Questi permessi scavalcano il modello di sharing: org-wide defaults, gerarchia dei ruoli, sharing rules, tutto quanto:

View All — vedere ogni record di un oggetto.
Modify All — vedere, modificare, eliminare e trasferire ogni record di un oggetto.

Un utente con View All sui Case vede ogni case nell’org, anche con un org-wide default Private e nessuna sharing rule all’orizzonte. Lo sharing semplicemente non si applica a lui per quell’oggetto.

Quando sono presenti, il resto del modello di sharing è irrilevante: questi permessi gli stanno sopra.

Due ambiti: oggetto vs intera org

Permesso	Ambito	Effetto
View All (oggetto)	Un oggetto	Vedere tutti i record di quell’oggetto
Modify All (oggetto)	Un oggetto	Controllo completo di tutti i record di quell’oggetto
View All Data	Intera org	Vedere (quasi) tutti i record, tutti gli oggetti
Modify All Data	Intera org	Controllo completo di (quasi) tutti i record, tutti gli oggetti

Le versioni a livello di oggetto sono delimitate e talvolta legittime. Le versioni a livello di sistema View All Data / Modify All Data sono l’artiglieria pesante: potenti, e quelle da custodire con più attenzione.

Da dove arrivano

Profilo System Administrator — viene fornito con View All Data e Modify All Data per impostazione predefinita.
Profili e permission set personalizzati — concessi di frequente per risolvere un caso isolato (“fai semplicemente vedere tutti i case al supporto”) e poi dimenticati.

Poiché i permessi di un utente sono l’unione del suo profilo e di ogni permission set assegnato, questi possono nascondersi in uno qualsiasi dei vari permission set: ed è proprio ciò che li rende facili da perdere di vista. Sono strettamente legati a profili e permission set.

Perché sono la prima cosa da controllare quando l’accesso appare sbagliato

Quando un utente può vedere un record che non dovrebbe, il pulsante Sharing potrebbe non mostrare nulla, perché l’accesso non proviene affatto dallo sharing. View All / Modify All concedono l’accesso senza comparire come una condivisione. Quindi, prima di scavare tra le sharing rules, escludi questi permessi.

Perché contano doppiamente per gli agenti AI

Un agente AI eredita i permessi del proprio running user. Se quell’identità porta con sé View All Data, l’agente può leggere su richiesta ogni record dell’org, scavalcando ogni sharing rule che hai configurato. Confermare che l’identità dell’agente sia priva di questi permessi è un passaggio fondamentale nell’audit degli accessi prima della messa in produzione.

Tenerli sotto controllo

Inventaria ogni profilo e permission set per View All/Modify All a livello di oggetto e per View All Data/Modify All Data a livello di sistema.
Elenca gli utenti che li possiedono, direttamente o tramite permission set.
Applica il privilegio minimo — sostituisci il View All generalizzato con sharing rules delimitate ovunque l’accesso non debba realmente essere esteso all’intera org.
Ricontrolla dopo le modifiche — un nuovo permission set può reintrodurre un bypass in silenzio.

Far emergere il bypass automaticamente

La parte difficile è che questi permessi non compaiono dove cerchi lo sharing: sono un interruttore a parte, in uno qualsiasi dei tanti permission set, che scavalca silenziosamente tutto il resto. AgentForceAccess li considera automaticamente: quando spiega perché un utente (o l’utente di un agente) può vedere un record, “ha View All Data — lo sharing non si applica” viene mostrato con la stessa chiarezza di qualsiasi sharing rule, così il bypass smette di essere ciò che ti sfugge.

Domande frequenti

Cosa fanno esattamente View All e Modify All?

Concedono l'accesso a ogni record di un oggetto, ignorando il modello di sharing. View All significa vedere ogni record; Modify All significa vedere, modificare, eliminare e trasferire ogni record. Le versioni a livello di oggetto si applicano a un solo oggetto; le versioni a livello di sistema "View All Data" e "Modify All Data" si applicano (quasi) a tutti gli oggetti contemporaneamente.

Chi possiede questi permessi per impostazione predefinita?

Il profilo System Administrator include View All Data e Modify All Data. Oltre a questo, compaiono su profili e permission set personalizzati, spesso aggiunti per risolvere una singola esigenza di accesso e mai più rimossi. Verifica ogni profilo e permission set, non solo gli admin.

Perché sono pericolosi per gli agenti AI?

Un agente eredita i permessi del proprio running user. Se quell'utente ha View All Data, l'agente può leggere su richiesta ogni record dell'org, scavalcando tutto lo sharing che hai configurato con cura. Prima di mettere in produzione un agente, conferma che la sua identità non porti con sé questi permessi.

Come faccio a trovare chi ha View All / Modify All?

Controlla ogni profilo e permission set per View All/Modify All a livello di oggetto e per View All Data/Modify All Data a livello di sistema, poi elenca gli utenti assegnati. Manualmente è laborioso, perché il permesso può arrivare da uno qualsiasi dei vari permission set assegnati a un utente.