Sharing rules ou role hierarchy dans Salesforce : la différence

La role hierarchy et les sharing rules sont les deux mécanismes que les administrateurs utilisent le plus — et les deux que l’on confond le plus souvent. Tous deux élargissent l’accès aux enregistrements, mais dans des directions différentes et pour des raisons différentes. Bien saisir la distinction, c’est la différence entre un modèle de partage propre et un enchevêtrement de règles qui se chevauchent.

La différence en une ligne

Role hierarchy — accorde l’accès automatiquement et verticalement : toute personne située au-dessus du propriétaire de l’enregistrement dans l’organigramme hérite de l’accès du propriétaire.
Sharing rules — accordent l’accès de façon délibérée et horizontale : à des pairs, à d’autres équipes ou à des groupes que la hiérarchie ne relierait jamais, selon la propriété ou des critères de champ.

Les deux reposent sur l’org-wide default et ne peuvent qu’ouvrir l’accès, jamais le restreindre. (Voyez l’empilement complet dans qui peut voir un enregistrement.)

Role hierarchy : l’accès remonte vers le haut

Lorsque Grant Access Using Hierarchies est activé pour un objet, les managers héritent automatiquement de l’accès aux enregistrements détenus par — ou partagés avec — les utilisateurs situés sous eux. Aucune règle, aucune configuration par enregistrement.

Exemple. Un org-wide default Private sur les Opportunities. Un commercial détient une affaire. Son manager, et le VP de ce manager, peuvent la voir automatiquement parce qu’ils se trouvent au-dessus du commercial dans la hiérarchie. C’est la role hierarchy qui fait son travail.

C’est parfait pour la visibilité manager-voit-son-équipe, et c’est aussi la source la plus fréquente des surprises du type « pourquoi peuvent-ils voir ça ? » — parce que personne ne l’a configuré par enregistrement.

Les sharing rules étendent l’accès à travers la hiérarchie, vers des utilisateurs que l’organigramme maintient séparés. Deux variantes :

Basées sur la propriété (ownership-based) — partagent les enregistrements détenus par un groupe (rôle, public group, territoire) avec un autre groupe.
Basées sur des critères (criteria-based) — partagent les enregistrements qui correspondent à des valeurs de champ (par ex. Region = EMEA) avec un groupe, un rôle ou un territoire.

Exemple. Les ventes EMEA et APAC sont des branches distinctes de la hiérarchie, donc aucune ne voit les affaires de l’autre. Une règle basée sur des critères — Region = EMEA → partager en Read avec le groupe APAC Leadership — ouvre exactement cet accès inter-branches sans toucher à la hiérarchie.

Quand utiliser l’une ou l’autre

Besoin	Utiliser
Les managers voient les enregistrements de leur équipe	Role hierarchy
L’accès suit automatiquement les lignes hiérarchiques	Role hierarchy
Deux équipes de même niveau doivent voir leurs enregistrements respectifs	Sharing rule (basée sur la propriété)
Partager les enregistrements correspondant à des critères de champ (région, type, étape)	Sharing rule (basée sur des critères)
Partager avec un public group ou un territoire	Sharing rule
Accès ponctuel à un seul enregistrement	Partage manuel (ni l’une ni l’autre)

Elles s’empilent — et c’est le piège

Parce que l’accès est additif et que c’est la règle la plus permissive qui gagne, la role hierarchy et les sharing rules se combinent. Un utilisateur peut obtenir l’accès à un même enregistrement via la hiérarchie et via deux sharing rules à la fois. Aucune n’écrase les autres ; une seule suffit.

C’est aussi pourquoi un partage trop large s’installe insidieusement : chaque règle paraît raisonnable isolément, mais c’est l’union entre hiérarchie + règles + partages manuels qui détermine ce qu’un utilisateur voit réellement — et personne ne garde cette image complète en tête.

Aucune ne restreint — par conception

Si vous devez réduire l’accès, les sharing rules et la role hierarchy ne peuvent rien pour vous. Resserrez l’org-wide default, ou utilisez des restriction rules. Ajouter une sharing rule supplémentaire ne peut jamais qu’ouvrir davantage d’accès.

Voir l’effet combiné

Le plus difficile n’est ni l’un ni l’autre mécanisme — c’est leur somme. Pour savoir pourquoi un utilisateur voit un enregistrement, il faut évaluer ensemble la hiérarchie et chaque sharing rule applicable et les partages manuels.

AgentForceAccess calcule cette union pour vous : demandez pourquoi un utilisateur peut voir un enregistrement et l’outil vous indique s’il s’agit de la role hierarchy, d’une sharing rule précise, ou des deux — en langage clair, avec le mécanisme cité.

Questions fréquentes

Quelle est la différence essentielle en une phrase ?

La role hierarchy ouvre l'accès vers le haut et automatiquement le long des lignes hiérarchiques, tandis que les sharing rules ouvrent l'accès latéralement et intentionnellement, vers des utilisateurs qu'une hiérarchie ne relierait jamais.

Si les deux pouvaient accorder l'accès au même enregistrement, laquelle l'emporte ?

Peu importe — l'accès Salesforce est additif et c'est la règle la plus permissive qui gagne. Si la role hierarchy ou une sharing rule accorde l'accès, l'utilisateur l'obtient. Vous n'avez jamais besoin que les deux « soient d'accord ».

Une sharing rule peut-elle retirer un accès ?

Non. Les sharing rules et la role hierarchy ne peuvent qu'étendre l'accès au-delà de l'org-wide default. Pour réduire l'accès, vous modifiez l'org-wide default ou utilisez des restriction rules — pas des sharing rules.

Ai-je encore besoin de sharing rules si ma role hierarchy est bien construite ?

En général oui. Une hiérarchie n'exprime que l'accès vertical, du manager vers ses subordonnés. Dès que deux équipes de même niveau, ou un rôle dans une autre branche, doivent voir leurs enregistrements respectifs, seule une sharing rule peut l'exprimer.