Abonnez-vous à notre newsletter

Merci pour votre inscription !

Record Access Roadmap

S'il y a bien une session à Dreamforce qui nous semblait utile juste en voyant le titre, c'était celle-ci 🤩 Avec toutes les nouveautés liées à la visibilité qui sont sorties aux cours des dernières releases, un petit récapitulatif n'était pas superflu !

Au programme :

  1. Système de visibilité

  2. Sharing Hierarchy

  3. Restriction Rules

  4. Scoping Rules

  5. Autres évolutions :


1. Système de visibilité

La session commence par un rappel du système de visibilité. A ce niveau-là, rien de neuf à l'horizon. On est toujours sur les mêmes principes de calcul des accès aux enregistrements, passant successivement par le ownership > les OWD > les rôles > les teams > les sharings.

Mais on note malgré tout certaines évolutions assez sympa dans la gestion de la visibilité, et qui seront tout particulièrement appréciées par les admins 👇


2. Sharing Hierarchy

On connaissait déjà l'option permettant de visualiser l'ensemble des utilisateurs ayant accès au record depuis le bouton "Sharing Hierarchy".

Il est à présent possible de visualiser les permissions pour un utilisateur spécifique, et la raison de cet accès.


Et puisque depuis quelques releases, nous devons également composer avec les Restriction Rules (ben oui, c'était pas assez compliqué comme ça 😂), celles-ci devraient être ajoutées en Summer '23 aux options de "Sharing Hierarchy" pour couvrir la totalité des cas de visibilités.


Donc à priori, cela facilitera la vie aux admins qui auront à répondre à l'éternelle question : "Pourquoi je ne vois pas cet enregistrement?"


3. Restriction Rules

On a beau les critiquer ou penser que cela rajouter une Nième complexité à la gestion de la visibilité, les Restriction Rules n'en sont pas moins utiles.

Dans certains cas, impossible de faire autrement que de s'en servir puisque c'est la seule manière de limiter un accès dans Salesforce.


Pour rappel, le principe des droits d'accès va toujours croissant ⬆️ (on donne plus de droits, on ne peut pas en supprimer) et ce n'est qu'avec leur apparition que le mécanisme inverse ⬇️ (on supprime des droits) a pu se faire.


Les Use Cases les plus classiques à gérer sont les suivants :

  • Je veux donner accès à un account, mais pas forcement à tous les enregistrements de Tasks/Events/Contracts qui lui sont liés

  • Sans Restriction Rules, toute personne ayant accès à l'Account aura accès à celle-ci.

  • Je dois maintenir une relation de Master/Detail sur des objets custom MAIS je ne veux pouvoir gérer l'accès aux enregistrements enfants (du côté Detail)

  • De base, l'accès aux Details est fonction de l'accès au Master

  • Je veux pouvoir limiter l'accès à certains enregistrements qui sont partagés par du Sharing ou la hiérarchie de rôles

  • On se retrouve très vite à monter une usine à gaz pour gérer ces cas,

Aujourd'hui, il est donc possible de gérer des restrictions sur :

  • Les custom objects et les external objects

  • Les Events/Tasks/Contracts

  • Les TimeSheet et TimeSheetEntry (pour ceux qui utilisent FSL)

Et à partir de la Spring '23, on aura également la possibilité de restreindre la visibilité pour les architectures multi-org.

Quelques exemples de Restrictions Rules qui pourraient être utiles :

  • Je veux restreindre l'accès à mes propres enregistrements, peu importe ma position dans la hiérarchie de rôles (Object.OwnerId = User.Id)

  • Je veux que mes enregistrements soient uniquement visibles par les utilisateurs ayant le même rôle que moi (Object.Owner.UserRoleId = User.UserRoleId)

  • Je veux que mes enregistrements soient uniquement visibles par les utilisateurs de mon département (Object.Owner.Department = User.Department)

Dernier point :

En Winter '23, on a la possibilité de comparer sur plusieurs valeurs (valeurX OU valeurY). Ex : Object.RecordType.Name = Sales, Marketing


D'autres potentielles évolutions sont déjà dans le viseur, mais dépendront des votes et de la priorisation, notamment le fait de pouvoir indiquer une clause AND (conditionX ET conditionY) ou encore la prise en charge d'autres objets standards tels que les Accounts, Cases, EmailMessage, Contact et Opportunity


4. Scoping Rules

Entre le "Je donne toujours accès" (Sharing rules) et le "Je ne donne jamais accès" (Restriction Rules), il y a également le "Je donne plus ou moins accès" 😅


Disons que les Scoping Rules, permettent de filtrer à haut niveau les List Views, les rapports ou les enregistrements remontés par les composants (SOQL).

Pour faire simple, cela va permettre de masquer certains enregistrements sur base des caractéristiques de l'utilisateur.


Alors, gardons bien en tête que c'est juste un filtre, et qu'il est toujours possible de voir les enregistrements par lien direct, dans les Related Lists,... Ne mélangez pas Restriction et Scope !


5. Et ensuite?

A plus long terme, d'autres fonctionnalités devraient voir le jour. Et pour certaines, on les attends avec impatience (pour ne pas dire qu'il était temps!). En vrac :


Sharing Settings

Dans les Org qui ont des 10aines d'objets provenant de packages, ou custom, il faut bien dire que cette page devient vite une horreur. On en a parfois mal au doigt de scroller (oui ok, le CTRL+F ça existe, on sait).

Et c'est sans compter les Sharing Rules qui sont affichées, peu importe qu'elles soient mises en place ou pas.

On devrait donc avoir dans le futur des interfaces plus User Friendly permettant de filtrer les objets sur base de leur nom, ou de leur niveau d'accès (public R/W, Private...), ou encore faire des recherches sur les accès de certains types d'utilisateur (par exemple le Guest User).


De ce qu'on en comprend, ces paramètres devraient également repasser sur les pages de setup des objets pour une meilleure centralisation du paramétrage.


Impact des Public Groups

On connait déjà le bouton "Where is it used". Ce serait bien de l'avoir sur les Public Group n'est-ce pas ?


Cela permettrait de voir, lorsqu'on y ajoute un utilisateur, les différents accès que celui-ci obtiendra, notamment via les Sharing Rules, sur les éléments contenus dans les Folders , l'accès aux List Views,...


Pas de date à l'horizon pour cette feature, mais les PM l'ont identifiée comme axe d'amélioration future.


User Access Policy

Plus qu'une simple Feature, c'est un tout nouveau système d'administration qui devrait sortir avec le "User Access Policy".


Cette interface permettra de visualiser en un coup d'oeil l'ensemble des permissions d'un utilisateur en croisant Permissions Sets, Permission Set Groups, Licences, Groups, Queues et Assignment Rules.


Idem pour les accès mais cette fois-ci au niveau d'un User spécifique. Cela viendra compléter les informations données entre autre par les options de "Sharing Hierarchy" que nous avons expliquées plus haut.


Et pour finir, dernière fonctionnalité mais pas des moindres, la comparaison entre deux utilisateurs pour en finir avec le jeux des 7 erreurs de la configuration des accès aux records 😆

Ah oui! Une toute toute dernière info concerne les tables de sharing. Lors du recalcul du sharing, tous les implicit sharing sont également recalculés. Pour améliorer le temps nécessaire pour ces opérations, Salesforce envisage de ne plus pousser ces lignes dans les tables __Share, mais ceci reste à l'étude pour le moment.


Aucune date n'a été donnée pour ces dernières fonctionnalités que nous attendons avec impatience. C'est toutes les infos que nous avons pu récolter à date.

 

Voilà pour ce qui est des grandes fonctionnalités que nous retenons de cette session. En espérant que cela vous sera utile pour vos projets.


N'oubliez pas que ces features ne sont pas en GA...forward-looking statement... safe harbor... vous connaissez la chanson 😉



et un tout grand merci aux Speakers pour toutes ces informations :

  • Larry Tung - Director, Product Management, Salesforce

  • Subhash Uppalapati - LMTS, Salesforce

  • Shyam Naren Kandala - SMTS, Salesforce

  • Sundar Sarangan - Lead Member Technical Staff, Salesforce

462 vues

Posts similaires

Voir tout