Un utilisateur voit un enregistrement interdit : trouver pourquoi
Une méthode pas à pas pour diagnostiquer pourquoi un utilisateur Salesforce voit un enregistrement interdit : OWD, hiérarchie des rôles, règles et partages.
Pourquoi cette personne voit-elle cet enregistrement ? est la question d’accès la plus fréquente dans Salesforce, et la plus difficile à trancher à l’œil nu, car la plateforme ne décide jamais de la visibilité en un seul endroit. Elle accorde l’union de plusieurs mécanismes. Ce guide vous donne un ordre reproductible pour trouver celui qui a ouvert l’accès.
D’abord, le modèle mental
Le partage Salesforce est additif et c’est le plus permissif qui l’emporte. Vous ne cherchez pas une règle qui autorise l’accès et une règle qui le bloque. Vous cherchez une seule autorisation, car une seule suffit. (Pour la superposition complète, voir qui peut voir un enregistrement dans Salesforce.)
Si ne serait-ce qu’un seul mécanisme accorde l’accès, l’utilisateur l’a. Votre travail consiste à trouver lequel.
Étape 1 — Lire le bouton Partage
Sur l’enregistrement, cliquez sur Partage (disponible pour les objets dont la valeur par défaut à l’échelle de l’organisation n’est pas entièrement publique). La liste affiche les utilisateurs ayant accès ainsi qu’une colonne Motif : Propriétaire, Hiérarchie des rôles, Règle de partage, Partage manuel, Équipe, etc. Dans la plupart des cas, elle désigne immédiatement le coupable.
Si l’utilisateur n’y figure même pas mais voit pourtant l’enregistrement, soupçonnez un contournement au niveau du profil — passez à l’étape 2.
Étape 2 — Écarter les contournements au niveau des autorisations
Ceux-ci ignorent entièrement le modèle de partage :
- View All Data / Modify All Data (autorisations système, par exemple sur le profil System Administrator).
- View All / Modify All au niveau de cet objet précis.
Si l’utilisateur dispose de l’une de ces autorisations via un profil ou un ensemble d’autorisations, les modifications de partage ne masqueront pas l’enregistrement. Vous devez retirer l’autorisation. Vérifiez son profil et chaque ensemble d’autorisations attribué.
Étape 3 — Parcourir les couches de partage, de haut en bas
S’il s’agit véritablement d’une autorisation de partage, identifiez la couche concernée :
La valeur par défaut à l’échelle de l’organisation est trop ouverte
Si l’OWD de l’objet est Public en lecture seule ou Public en lecture/écriture, tous ceux qui ont accès à l’objet voient chaque enregistrement. La correction est structurelle : resserrez la valeur par défaut à l’échelle de l’organisation et ré-accordez l’accès délibérément.
La hiérarchie des rôles fait remonter l’accès vers le haut
Si l’utilisateur se situe au-dessus du propriétaire de l’enregistrement dans la hiérarchie des rôles et que « Grant Access Using Hierarchies » est activé, il hérite automatiquement de l’accès du propriétaire. C’est la surprise la plus fréquente.
Une règle de partage trop large
Une règle par critères comme Region = EMEA → partager avec le rôle X peut inclure bien plus de personnes que prévu, surtout après des changements de données ou de rôles. Examinez les règles ciblant le rôle de l’utilisateur, les groupes publics ou le territoire.
Un partage manuel ou implicite
- Partage manuel : quelqu’un a utilisé le bouton Partager de l’enregistrement.
- Partage implicite : l’accès à un compte parent accorde un accès limité en lecture à ses requêtes et contacts enfants. Tout le monde oublie celui-ci en permanence, et il est toujours en lecture seule.
- Partage géré par Apex : du code personnalisé a créé le partage ; le bouton Partage l’affiche mais l’origine se trouve dans le code.
Équipes et territoires
L’appartenance à une équipe de compte/opportunité/requête, ou un territoire correspondant sous Enterprise Territory Management, accorde un accès de manière indépendante.
Étape 4 — Confirmer qu’il ne s’agit pas d’un délai de recalcul
Si l’accès semble incohérent, vous observez peut-être la fin d’un recalcul du partage après un changement récent de propriété, de rôle ou de règle. Laissez-le se terminer avant de déclarer un bug.
Une liste de contrôle de diagnostic
- Bouton Partage → lisez le Motif pour cet utilisateur.
- Profil + ensembles d’autorisations → un View All / Modify All ?
- L’OWD est-il trop ouvert pour cet objet ?
- L’utilisateur est-il au-dessus du propriétaire dans la hiérarchie des rôles ?
- Une règle de partage (surtout par critères) les inclut-elle ?
- Un partage manuel, implicite ou Apex ?
- Membre d’une équipe ou territoire correspondant ?
- Changement récent → attendez le recalcul.
Le premier « oui » est votre réponse — et il peut y avoir plus d’un chemin accordant le même accès. Pour le problème inverse — un utilisateur qui ne peut pas voir un enregistrement qu’il devrait voir — consultez la liste de contrôle pour diagnostiquer un accès manquant.
Le faire en quelques secondes plutôt qu’en un après-midi
Parcourir huit couches par paire utilisateur-enregistrement, à travers les profils, les ensembles d’autorisations et six mécanismes de partage, c’est exactement le travail manuel fastidieux qui masque les expositions réelles. AgentForceAccess le fait pour vous : demandez en langage clair pourquoi un utilisateur voit un enregistrement, et l’outil retrace chaque couche et cite l’autorisation précise, pour vous amener directement à la correction.
Questions fréquentes
Quelle est la première vérification la plus rapide ?
Ouvrez l'enregistrement, cliquez sur le bouton Partage et lisez la colonne « Motif » pour cet utilisateur. Pour la plupart des objets standard, elle nomme le mécanisme qui accorde l'accès : Propriétaire, Hiérarchie des rôles, Règle de partage, Manuel, etc. Vérifiez aussi que l'utilisateur ne dispose pas simplement de « View All Data » ou d'un « View All » au niveau de l'objet.
Le bouton Partage indique « Hiérarchie des rôles » — et maintenant ?
Quelqu'un situé sous l'utilisateur dans la hiérarchie des rôles possède l'enregistrement (ou se l'est vu partager), et l'option « Grant Access Using Hierarchies » est activée pour l'objet. Pour supprimer cet accès, il faudrait modifier la hiérarchie, la propriété ou désactiver l'accès par hiérarchie pour les objets personnalisés, aucune de ces options n'étant à prendre à la légère.
Une autorisation de profil, et non un partage, pourrait-elle être en cause ?
Oui. « View All Data »/« Modify All Data » et les « View All »/« Modify All » au niveau de l'objet contournent entièrement le modèle de partage. Si l'utilisateur dispose de l'une de ces autorisations, aucune modification du partage ne masquera l'enregistrement : vous devez plutôt retirer l'autorisation.
Pourquoi l'accès apparaît-il et disparaît-il par intermittence ?
Le recalcul du partage. Après un changement de propriété, un déplacement de rôle ou la modification d'une règle, Salesforce retraite les partages de façon asynchrone. Pendant ce laps de temps, l'accès peut sembler incohérent. Laissez le recalcul se terminer avant de conclure à un bug de configuration.
Voyez-le sur votre propre org
AgentForceAccess explique, en langage clair, pourquoi n'importe quel utilisateur peut voir n'importe quel enregistrement ou fichier — à travers chaque mécanisme de partage Salesforce.
Demander un accès anticipé