Qui peut voir un enregistrement dans Salesforce ? Le partage expliqué

Si vous administrez une org Salesforce suffisamment longtemps, quelqu”un finira par vous demander : « Comment cette personne arrive-t-elle à voir cet enregistrement ? » La réponse honnête est que Salesforce ne décide jamais de la visibilité d”un enregistrement à un seul endroit. Il superpose plusieurs mécanismes les uns sur les autres et accorde leur union.

Ce guide passe en revue chaque couche dans l”ordre où Salesforce l”évalue, afin que vous puissiez raisonner sur n”importe quelle question de type « qui voit quoi » à partir des principes de base.

La seule règle qui explique tout

Le partage Salesforce est additif et la plus permissive l”emporte. On part de la base définie par les org-wide defaults, puis tout autre mécanisme ne peut qu”ajouter de l”accès par-dessus. Rien dans le modèle de partage standard ne retire de l”accès.

Ainsi, lorsque vous cherchez à comprendre pourquoi un utilisateur peut voir un enregistrement, vous ne cherchez jamais à la fois la règle qui l”autorise et la règle qui le bloque. Vous cherchez une seule autorisation — car une seule suffit.

Si ne serait-ce qu”un seul mécanisme accorde l”accès, l”utilisateur a accès. Point final.

Couche 1 — Les permissions d”objet décident du si, pas du quoi

Avant même que le partage ne soit pris en compte, l”utilisateur a besoin d”un accès au niveau de l”objet via son profil ou ses permission sets :

• Read / Create / Edit / Delete sur l”objet.
• View All ou Modify All sur l”objet, qui ignorent entièrement le partage pour cet objet.

Si un utilisateur n”a aucune permission Read sur les Opportunities, aucune règle de partage au monde ne lui montrera une opportunité. Les permissions d”objet sont la porte ; le modèle de partage est ce qui se passe après l”avoir franchie.

Couche 2 — Les org-wide defaults fixent le plancher

Les org-wide defaults (OWD) définissent la base la plus restrictive pour chaque objet :

• Private — seul le propriétaire de l”enregistrement (et les personnes au-dessus de lui dans la hiérarchie des rôles) peut le voir.
• Public Read Only — tout le monde peut le consulter, seul le propriétaire peut le modifier.
• Public Read/Write — tout le monde peut le consulter et le modifier.

Tout ce qui suit existe pour élargir l”accès au-dessus de ce plancher pour des personnes spécifiques.

Couche 3 — La hiérarchie des rôles fait remonter l”accès

Si l”option Grant Access Using Hierarchies est activée pour l”objet, toute personne située au-dessus du propriétaire de l”enregistrement dans la hiérarchie des rôles hérite de l”accès du propriétaire. C”est pourquoi un directeur des ventes voit les affaires de ses commerciaux sans aucune règle explicite — et c”est de loin la raison la plus fréquente d”un accès inattendu.

Couche 4 — Les règles de partage ouvrent l”accès latéralement

Les règles de partage étendent l”accès en travers de la hiérarchie, vers les pairs et d”autres branches :

• Basées sur la propriété — partager les enregistrements détenus par un groupe d”utilisateurs avec un autre groupe.
• Basées sur des critères — partager les enregistrements correspondant à des valeurs de champ (par ex. Region = EMEA) avec un groupe, un rôle ou un territoire.

Toutes deux accordent l”accès à un groupe d”utilisateurs d”un coup, ce qui fait d”une règle basée sur des critères trop large un coupable fréquent lorsque « trop » de personnes peuvent voir quelque chose.

Couche 5 — Partages manuels et implicites

• Partage manuel — le bouton Partager sur un enregistrement, accordant à un utilisateur ou un groupe précis l”accès à ce seul enregistrement.
• Partage implicite — comportement intégré, comme l”accès à un compte parent impliquant un accès limité à ses cases et contacts enfants.
• Apex managed sharing — partages programmatiques créés par du code personnalisé, souvent les plus difficiles à repérer.

Couche 6 — Équipes et territoires

• Les équipes de compte, d”opportunité et de case accordent aux membres de l”équipe listés l”accès à cet enregistrement.
• Enterprise Territory Management accorde l”accès en fonction des territoires auxquels un utilisateur et un enregistrement appartiennent.

Tout assembler : comment tracer n”importe quel accès

Pour répondre à « pourquoi cet utilisateur peut-il voir cet enregistrement », vérifiez chaque couche jusqu”à trouver une autorisation :

1. L”utilisateur a-t-il la permission Read (ou View All) sur l”objet via son profil/permission set ?
2. L”OWD est-il déjà public pour cet objet ?
3. Est-il au-dessus du propriétaire dans la hiérarchie des rôles ?
4. Une règle de partage l”inclut-elle ?
5. Existe-t-il un partage manuel, implicite ou Apex ?
6. Fait-il partie d”une équipe, ou d”un territoire correspondant ?

Le premier « oui » est votre réponse — et n”oubliez pas qu”il peut y en avoir plusieurs. Pour la version étape par étape de ce traçage, voir un utilisateur peut voir un enregistrement qu”il ne devrait pas voir ; le même modèle régit qui peut voir un fichier, puisque les fichiers héritent de l”accès aux enregistrements.

C”est exactement le travail qu”AgentForceAccess automatise : demandez en langage clair pourquoi un utilisateur peut voir un enregistrement, et l”outil trace chaque couche ci-dessus et cite l”autorisation précise qui l”accorde.

Questions fréquentes

Un System Administrator contourne-t-il le modèle de partage ?

Oui. Les permissions « View All Data » et « Modify All Data » — accordées par défaut au profil System Administrator — contournent entièrement les org-wide defaults, les règles de partage et la hiérarchie des rôles. Les permissions « View All » / « Modify All » au niveau de l'objet font de même pour un seul objet.

Si deux règles de partage s'appliquent au même enregistrement, laquelle l'emporte ?

La plus permissive. L'accès Salesforce est additif : il accorde l'union de toutes les règles applicables. L'accès ne peut jamais être réduit en ajoutant une autre règle — seulement élargi.

Pourquoi un manager peut-il voir des enregistrements qui ne lui ont jamais été explicitement attribués ?

La hiérarchie des rôles accorde aux managers l'accès aux enregistrements détenus par (ou partagés avec) les utilisateurs situés sous eux dans la hiérarchie, à condition que l'option « Grant Access Using Hierarchies » soit activée pour cet objet.

Les permissions d'objet et les paramètres de partage font-ils la même chose ?

Non. Les permissions d'objet (sur les profils et les permission sets) décident si un utilisateur peut accéder à un objet et ce qu'il peut en faire. Le modèle de partage décide quels enregistrements précis de cet objet il peut voir.