Restriction, scoping et sharing rules : quelles différences ?

L”essentiel du modèle de partage de Salesforce ne sait faire qu”une chose : ouvrir l”accès. Les restriction rules et les scoping rules sont les outils plus récents qui changent la donne — mais elles font des choses très différentes, et on les confond facilement. Voici comment ces trois mécanismes s”articulent.

La carte en une ligne

• Sharing rules — ouvrir l”accès. Donner des enregistrements à des utilisateurs qui ne les verraient pas autrement.
• Restriction rules — réduire l”accès. Écarter des enregistrements qu”un utilisateur aurait normalement le droit de voir.
• Scoping rules — recentrer la vue. Changer quels enregistrements s”affichent par défaut, sans modifier l”accès.

Deux de ces mécanismes touchent à la sécurité ; le troisième non. C”est la distinction à garder en tête.

Sharing rules : ouvrir l”accès

Les sharing rules s”appuient sur l”org-wide default et accordent un accès supplémentaire par propriétaire ou par critères. Elles ne peuvent qu”élargir l”accès — jamais le restreindre. Si vous avez besoin d”une piqûre de rappel sur leur comparaison avec la hiérarchie, voyez sharing rules vs hiérarchie des rôles.

C”est le comportement additif, où le plus permissif l”emporte, au cœur du modèle d”accès aux enregistrements.

Restriction rules : réduire l”accès

Les restriction rules sont l”exception à la règle « le partage Salesforce ne fait qu”ouvrir l”accès ». Une restriction rule définit les enregistrements qu”un utilisateur est autorisé à voir, et s”applique par-dessus tout ce que le modèle de partage a accordé — filtrant ainsi le résultat.

Si l”org-wide default, la hiérarchie des rôles et les sharing rules montreraient ensemble 10 000 enregistrements à un utilisateur, une restriction rule peut ramener ce nombre au sous-ensemble qui correspond à ses critères.

Exemple. Les agents de support disposent d”un large accès aux Cases via une sharing rule, mais les prestataires parmi eux ne devraient voir que les cases non confidentielles. Une restriction rule sur Case — Confidential = false pour le permission set des prestataires — retire les cas confidentiels de ce qu”ils peuvent voir, alors même que le partage les leur avait techniquement accordés.

C”est l”outil à dégainer lorsque la vraie question est « comment retirer un accès ».

Scoping rules : du recentrage, pas de la sécurité

Les scoping rules contrôlent quels enregistrements apparaissent par défaut dans les vues en liste, les recherches et les rapports — selon des conditions comme le propriétaire, le rôle ou la région. Point crucial :

Les scoping rules ne limitent pas l”accès. Un utilisateur peut basculer le périmètre sur « tous les enregistrements auxquels j”ai accès » et voir tout ce que le partage lui accorde.

C”est une fonctionnalité de productivité : montrer en premier sa propre région à un commercial débordé, sans l”y enfermer. Si un utilisateur doit être empêché de voir des enregistrements, les scoping rules sont le mauvais outil — utilisez les restriction rules.

Comparaison côte à côte

	Sharing rules	Restriction rules	Scoping rules
Effet sur l”accès	Ouvre	Réduit	Aucun
Contrôle de sécurité ?	Oui	Oui	Non (recentrage seul)
L”utilisateur peut-il contourner ?	Non	Non	Oui (changer de périmètre)
Direction	Ajoute de l”accès	Retire de l”accès	Filtre la vue par défaut
Limite typique	Nombreuses	~2 actives/objet	~2 actives/objet

Les combiner

Un objet réaliste peut utiliser les trois : un OWD Private, des sharing rules pour donner aux équipes l”accès dont elles ont besoin, une restriction rule pour soustraire un sous-ensemble sensible aux prestataires, et une scoping rule pour que chaque utilisateur arrive par défaut sur sa propre région. Chacune fait un seul travail ; ensemble, elles façonnent à la fois ce que les utilisateurs peuvent voir et ce qu”ils voient en premier.

Le piège : l”accès effectif est une somme

Empiler des outils qui ouvrent, qui réduisent et qui recentrent rend la question « que peut réellement voir cet utilisateur ? » véritablement difficile à trancher à l”œil nu — les accès accordés par le partage moins les filtres de restriction, en ignorant le scoping. C”est exactement le calcul qu”AgentForceAccess effectue pour vous : demandez ce à quoi un utilisateur a vraiment accès, et l”outil tient compte du partage qui l”accorde et des restriction rules qui le rabotent, en langage clair.

Questions fréquentes

Quelle est la différence en une phrase ?

Les sharing rules accordent un accès dont l'utilisateur ne disposait pas, les restriction rules retirent un accès qu'il possédait, et les scoping rules se contentent de préfiltrer les vues en liste et les recherches sans toucher à l'accès.

Une restriction rule peut-elle l'emporter sur une sharing rule ou la hiérarchie des rôles ?

Oui. Les restriction rules s'appliquent par-dessus le modèle de partage et filtrent les enregistrements qu'un utilisateur peut voir, y compris ceux que l'org-wide default, la hiérarchie des rôles ou les sharing rules exposeraient autrement. C'est ainsi que l'on réduit réellement un accès dans Salesforce.

Les scoping rules masquent-elles des enregistrements à des fins de sécurité ?

Non. Les scoping rules changent seulement l'ensemble d'enregistrements affichés par défaut dans les vues en liste, les recherches et les rapports. Un utilisateur peut basculer le périmètre sur « tous les enregistrements auxquels j'ai accès » : elles relèvent donc du confort et de la productivité, pas de la sécurité. Utilisez les restriction rules lorsque l'accès doit vraiment être limité.

Ces règles sont-elles soumises à des limites ?

Oui. Les restriction rules et les scoping rules sont généralement plafonnées à 2 règles actives par objet, et disponibles pour les objets personnalisés ainsi qu'une sélection d'objets standard tels que Account, Case, Contact, Event, Lead, Opportunity et Task. Vérifiez les limites en vigueur pour votre édition.