Lorsque votre organisation compte de nombreux utilisateurs, l’un des défis auxquels toute entreprise est confrontée est de s’assurer qu’ils disposent du bon niveau de visibilité sur les données et des droits appropriés.
De nos jours, les profils sont de moins en moins utilisés pour gérer les autorisations des utilisateurs, car il existe d’autres mécanismes pour définir les actions qu’ils peuvent effectuer et les ressources auxquelles ils ont accès. C’est d’ailleurs ce qui est préconisé par Salesforce. Parmi ces mécanismes de droits et visibilité, on peut citer les Permission Sets, les Public Groups ou encore les Queues.
Des stratégies différentes pour un but commun
J’ai observé différentes approches pour gérer la création d’un utilisateur et ses droits, allant des méthodes les plus sophistiquées aux plus manuelles :
- La gestion centralisée au niveau de l’entreprise, utilisant des systèmes de fédération d’identité qui associent des groupes Active Directory aux permissions correspondantes.
- L’utilisation de lots (Batch), de déclencheurs (Trigger) ou de flux (Flow) basés sur les caractéristiques de l’utilisateur.
- Une approche manuelle (et oui!), utilisant des feuilles de calcul Excel répertoriant les différentes autorisations.
Cependant, quelle que soit l’approche utilisée, une question reviendra tôt ou tard : « Pourquoi cet utilisateur ne voit-il pas tel enregistrement ? » Pire encore, il peut arriver que l’utilisateur voie des enregistrements auxquels il ne devrait pas avoir accès.
Cela nécessite alors une analyse approfondie pour comprendre la source du problème.
Des mécanismes de visibilité imbriqués
Si vous êtes confus quant à la nature du problème, un petit rappel pourrait s’avérer utile.
L’image ci-dessus représente 2 mécaniques de partage de la visibilité : Les Publics Groups et les Queues. Il en existe bien d’autres tels que les Teams par exemple. On voit bien qu’il ne suffira pas d’aller voir les membres d’un groupe ou d’une file d’attente pour répondre à notre question.
Dans un monde idéal, nous aurions une fonctionnalité, au niveau de la configuration, permettant de vérifier les affectations aux groupes, aux permissions, aux files d’attente… et d’obtenir une vue détaillée des droits associés à chacun d’eux.
Dans un monde idéal, nous pourrions assigner ou supprimer directement les droits et accès depuis cette interface.
User Access Policies : le premier pas vers la centralisation
L’année dernière, lors de la conférence Dreamforce, j’avais participé à la session sur la Roadmap de la sécurité. Une refonte complète de la visibilité et des permissions avait été annoncée. Les captures d’écran prometteuses ci-dessous en témoignent.
Il serait donc possible de sélectionner un utilisateur et d’afficher toutes ses affiliations.
Voir de comparer deux utilisateurs et mettre en avant les différences.
Dans la version Summer ’23, une nouvelle fonctionnalité est introduite, permettant d’automatiser certaines actions lors de la création ou de la modification des utilisateurs :
Lien vers la oage Release Notes
Son fonctionnement est simple :
- Trigger Type : On détermine l’événement déclencheur.
- Applicable User : On choisit le profil auquel la policy sera appliquée.
- Additional User Field Filters : On peut ajouter des filtres supplémentaires si nécessaire.
- Actions : On définit les actions à appliquer, par exemple ajouter des :
- Permission sets
- Permission set groups
- Permission set licenses
- Managed package licenses
- Groups
- Queues
Cela vous rappelle quelque chose ? En effet, cette fonctionnalité suit la même logique que les déclencheurs (triggers) ou les flux (flows) que vous auriez pu mettre en place.
Alors, vous pourriez vous demander pourquoi utiliser cette fonctionnalité alors qu’il est possible de réaliser la même chose avec des Triggers ou des Flows ? La réponse est simple : parce que nous devons toujours envisager le Low Code et les fonctionnalités standard, avant d’envisager toute autre mécanique.
Conclusion
Le principal avantage que j’y vois est que cette fonctionnalité est désormais disponible de manière déclarative. Plus besoin de passer par l’Apex. De plus, elle est bien plus simple à mettre en place que les Flows. Soyons honnêtes, cette approche est beaucoup plus simple à mettre en œuvre.
Maintenant, est-ce que cette fonctionnalité révolutionne la version Summer ’23 ? Je dirais que cela dépend des cas. Pour les projets où aucune automatisation liée aux droits n’a été mise en place, cela offre une opportunité de démarrer l’étude et de l’implémenter.
Dans les autres cas, il pourrait être envisageable de remplacer les déclencheurs existants par cette approche standard.
En conclusion, je suis ravie de voir cette fonctionnalité dans la version Summer ’23, car cela laisse présager d’autres améliorations à venir. Tout comme les autres features (scoping rules, sharing rules details) qui figuraient également dans la Roadmap et qui ont depuis été mises en œuvre.
De belles évolutions en perspective !