Ce texte a été traduit en utilisant le système de traduction automatisé de Salesforce. Répondez à notre sondage pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous aimeriez voir ensuite.
Note
Le modèle de partage Salesforce est un élément essentiel de la capacité de votre organisation à fournir un accès sécurisé aux données des applications. Par conséquent, il est crucial d'architecturer correctement votre modèle de partage pour répondre à vos exigences actuelles et futures en matière d'accès aux données. Dans ce document, nous allons examiner les composants d'accessibilité des données, les cas d'utilisation de modèle de partage et les vraies solutions de partage client, et nous allons fournir quelques consignes de dépannage.
Ce document est destiné aux administrateurs système et aux architectes avancés. Pour comprendre les concepts, vous devez avoir une Knowledge pratique du modèle de sécurité et de partage Salesforce. Les prérequis à ce guide sont les suivants :
Ce guide présente les principales fonctionnalités utilisées pour contrôler l'accès au niveau de l'enregistrement aux objets standard et personnalisés. Les sujets non abordés dans ce guide comprennent :
La sécurité au niveau de l'enregistrement permet d'accorder aux utilisateurs l'accès à certains enregistrements d'objet, mais pas à d'autres. Comme dans la plupart des applications, l'accès aux données commence par un utilisateur. L'application doit connaître l'utilisateur avant d'accorder l'accès. Pour Salesforce, il existe différents types d'utilisateur et, parfois, le niveau d'accès est différent selon le type. Au lieu de passer en revue chaque attribut de chaque type de licence, nous allons nous intéresser ici aux attributs intéressants qui ont un impact important sur l'accès aux données. La propriété de l'enregistrement et l'accès complet sont synonymes et interchangeables, et offrent à l'utilisateur le niveau d'accès le plus élevé à un enregistrement.
Utilisateurs haut volume
Les utilisateurs haut volume (y compris les utilisateurs détenteurs des types de licence Customer Community, High Volume Customer Portal et Authenticated Website) n'utilisent pas le modèle de partage, car leurs types de licence ne prennent pas en charge les rôles. Ces licences ont leur propre modèle de partage qui fonctionne par correspondance de clé étrangère entre l'utilisateur (titulaire de la licence) et les données des références Compte et Contact. Les administrateurs peuvent créer des ensembles de partages ou des groupes de partage pour accorder aux utilisateurs haut volume l'accès aux enregistrements.
Licences Chatter Free et Chatter External
Les licences Chatter Free et Chatter External ne suivent pas le modèle de partage standard. Ces licences n'ont pas accès aux enregistrements CRM (objets standard ou personnalisés) et à la fonctionnalité Contenu, et ne prennent pas en charge les rôles. Par conséquent, il n'y a pas de partage.
Pour la suite de ce document, nous supposons un type d'utilisateur Salesforce utilisant un modèle de partage complet. Pour plus d'informations sur chaque type de licence disponible, consultez Licences utilisateur.
Profils et ensembles d'autorisations
Les profils et les ensembles d'autorisations offrent une sécurité au niveau de l'objet en déterminant les types de données que les utilisateurs affichent et s'ils peuvent modifier, créer ou supprimer des enregistrements. Pour chaque objet, les autorisations « Afficher tout » et « Modifier tout » ignorent les règles et les paramètres de partage, ce qui permet aux administrateurs d'accorder rapidement l'accès aux enregistrements associés à un objet donné dans l'ensemble de l'organisation. Ces autorisations sont souvent préférables aux autorisations administratives « Afficher toutes les données » et « Modifier toutes les données », qui permettent aux utilisateurs d'afficher ou de modifier toutes les applications et données.
Les profils et les ensembles d'autorisations contrôlent également la sécurité au niveau du champ, qui détermine les champs de chaque objet auquel les utilisateurs ont accès. Par exemple, un objet peut inclure 20 champs, mais la sécurité au niveau du champ peut être configurée pour empêcher les utilisateurs d'afficher cinq des 20 champs.
Nous recommandons vivement d'utiliser des ensembles d'autorisations et des groupes d'ensembles d'autorisations au lieu de profils pour gérer les autorisations d'objet de vos utilisateurs. Comme vous pouvez réutiliser de plus petits blocs de construction d'ensembles d'autorisations, vous pouvez éviter de créer des dizaines, voire des centaines de profils pour chaque utilisateur et fonction.
Propriété des enregistrements et files d'attente
Chaque enregistrement doit appartenir à un seul utilisateur ou à une file d'attente. Le propriétaire a accès à l'enregistrement, en fonction des Paramètres d'objet de son profil. Par exemple, si le profil du propriétaire dispose de l'autorisation Créer et Lire sur un objet, mais pas de l'autorisation Modifier ou Supprimer, le propriétaire peut créer un enregistrement pour l'objet et afficher le nouvel enregistrement. Cependant, le propriétaire ne peut pas modifier ni supprimer l'enregistrement. Les utilisateurs de rang supérieur dans une hiérarchie (rôle ou territoire) héritent du même accès aux données que leurs subordonnés pour les objets standard. Si le subordonné a accès en lecture seule, les utilisateurs de rang supérieur dans la hiérarchie des rôles le seront également. Cet accès s'applique aux enregistrements appartenant à des utilisateurs, ainsi qu'aux enregistrements partagés avec eux.
Les files d'attente aident à prioriser, à distribuer et à attribuer des enregistrements aux équipes qui partagent des charges de travail. Les membres de file d'attente et les utilisateurs de rang supérieur dans la hiérarchie des rôles peuvent accéder aux files d'attente à partir de vues de liste et s'approprier les enregistrements d'une file d'attente.
Si un seul utilisateur possède plus de 10 000 enregistrements, la meilleure pratique consiste à :
L'enregistrement utilisateur du propriétaire ne doit pas avoir de rôle dans la hiérarchie des rôles.
Si l'enregistrement utilisateur du propriétaire doit contenir un rôle, placez-le en haut de la hiérarchie dans sa propre branche de la hiérarchie des rôles.
Pour plus d'informations, consultez Salesforce Well-Architected - Reliable.
Paramètres par défaut de l'organisation
Les paramètres de partage de l'organisation spécifient le niveau d'accès par défaut des utilisateurs aux enregistrements des autres utilisateurs. Vous utilisez les paramètres de partage de l'organisation pour verrouiller vos données au niveau le plus restrictif. Utilisez les autres outils de sécurité et de partage au niveau de l'enregistrement pour accorder sélectivement l'accès à d'autres utilisateurs. Par exemple, les utilisateurs disposent d'autorisations au niveau de l'objet pour lire et modifier les opportunités, et le paramètre de partage à l'échelle de l'organisation est Lecture seule. Par défaut, ces utilisateurs peuvent lire tous les enregistrements d'opportunité, mais ne peuvent pas les modifier, sauf s'ils sont propriétaires de l'enregistrement ou s'ils disposent d'autres autorisations.
Les paramètres par défaut de l'organisation peuvent être modifiés d'un paramètre à l'autre (Privé à Contrôlé par parent, puis de nouveau à Privé). Cependant, ces modifications nécessitent un recalcul du partage et peuvent entraîner de longs délais de traitement selon le volume.
Pour des objets personnalisés uniquement, vous pouvez configurer le paramètre Octroyer l'accès en utilisant des hiérarchies. Si cette option n'est pas cochée (par défaut cochée), les utilisateurs de rang supérieur dans la hiérarchie des rôles ne peuvent pas hériter de l'accès. Ce paramètre se trouve dans les paramètres par défaut de l'organisation.
Hiérarchie des rôles
Une hiérarchie des rôles représente un niveau d'accès aux données dont un utilisateur ou un groupe d'utilisateurs a besoin. La hiérarchie des rôles garantit que les responsables ont toujours accès aux mêmes données que leurs employés, quels que soient les paramètres par défaut de l'organisation. Les hiérarchies de rôles ne doivent pas correspondre exactement à votre organigramme. À la place, chaque rôle dans la hiérarchie devrait représenter un niveau d'accès aux données dont un utilisateur ou un groupe d'utilisateurs a besoin.
Dans les organisations Salesforce créées dans Spring ’21 ou supérieur, vous pouvez créer jusqu'à 5000 rôles. Dans les organisations créées avant Spring ’21, vous pouvez créer jusqu'à 500 rôles et contacter le Support client de Salesforce pour augmenter cette limite. La meilleure pratique recommande de limiter le nombre de rôles internes à 25 000 et le nombre de rôles externes à 100 000.
La meilleure pratique consiste à limiter la hiérarchie des rôles à 10 niveaux maximum dans la hiérarchie.
Lorsque le rôle d'un utilisateur change, toutes les règles de partage pertinentes sont évaluées pour corriger l'accès si nécessaire. Les pairs d'un même rôle ne leur garantissent pas l'accès aux données des autres.
La modélisation de la hiérarchie des rôles commence par comprendre la structure de l'organisation. Cela est généralement construit à partir de la compréhension de la portée d'un responsable, en commençant par le haut. Le PDG supervise l'ensemble de l'entreprise. Le PDG a généralement des subordonnés directs qui peuvent ensuite être segmentés par unité commerciale (ventes ou support) ou région géographique (EMEA, APAC). Cette personne a alors des subordonnés directs qui pourraient être segmentés davantage, et ainsi de suite. Bien que cela ressemble beaucoup à un organigramme RH, lors de la modélisation de l'accès aux données, mettez l'accent sur l'accessibilité des données en tenant compte des rapports RH.
Les superpositions sont toujours la partie délicate de la hiérarchie. S'ils sont dans leur propre agence, ils ont besoin de règles de partage, d'équipes ou de gestion de territoire pour obtenir l'accès requis. S'ils sont intégrés dans la hiérarchie, cela peut avoir des répercussions sur les rapports.
Il est important de passer le temps à configurer la hiérarchie des rôles, car c'est l'un des aspects fondamentaux du modèle de partage.
| Cas d'utilisation de hiérarchie des rôles |
|---|
| Accès à la gestion : la possibilité pour les responsables de voir et de faire tout ce que leurs subordonnés peuvent voir et faire. |
| Rapports de gestion : la possibilité de cumuler les rapports de façon hiérarchique afin d'afficher plus de données pour tous les utilisateurs de rang supérieur dans la hiérarchie que pour les utilisateurs de rang inférieur. |
| Séparation entre les branches de l'organisation : les différentes unités commerciales n'ont pas besoin d'afficher les données des autres. Une hiérarchie dans laquelle vous pouvez définir des branches distinctes permet de séparer la visibilité au sein des unités commerciales, tout en continuant à cumuler la visibilité jusqu'aux niveaux de direction supérieurs à ces unités. |
| Ségrégation au sein d'un rôle : dans de nombreuses organisations/applications, les personnes qui jouent toutes le même rôle ne doivent pas nécessairement afficher les données des autres. Avoir des rôles hiérarchiques permet de définir un nœud « feuille » dans lequel toutes les données sont essentiellement privées, tout en cumulant ces données dans un rôle parent qui peut toutes afficher. |
Groupes publics
Un groupe public est un ensemble d'utilisateurs individuels, de rôles, de territoires, etc., qui ont tous une fonction en commun. Les groupes publics peuvent comprendre :
Les groupes peuvent être imbriqués (groupe A imbriqué dans groupe B), mais ne pas imbriquer plus de cinq niveaux. L'imbrication a un impact sur la maintenance et les performances du groupe en raison du calcul de l'appartenance au groupe. La meilleure pratique consiste à limiter le nombre total de groupes publics pour une organisation à 100 000.
| Cas d'utilisation de groupes publics |
|---|
| Lorsque vous devez accorder l'accès à un groupe arbitraire de personnes, vous créez un groupe public pour les collecter, puis utilisez d'autres outils de partage pour accorder l'accès nécessaire au groupe. L'appartenance à un groupe seule ne fournit pas l'accès aux données. |
| Les groupes peuvent également être imbriqués les uns dans les autres, ce qui permet à un groupe imbriqué d'obtenir le même accès que le groupe dans lequel il est inclus. Cela permet de créer des hiérarchies ad hoc plus petites qui n'interagissent pas nécessairement avec les hiérarchies de rôles ou de territoires. Si le Groupe A est membre du Groupe B, les membres du Groupe A auront accès aux données partagées avec le Groupe B au même niveau d'accès que les membres du Groupe B. |
| Les groupes ont également la possibilité de protéger les données partagées dans le groupe contre l'accès des personnes de rang supérieur dans la hiérarchie des rôles. Ceci (et traitant de l'accès des propriétaires d'enregistrement et de leur hiérarchie de gestion) permet de créer des groupes dans lesquels des informations très confidentielles peuvent être partagées - les données seront accessibles UNIQUEMENT aux membres du groupe, et à personne d'autre dans l'organisation. Pour ce faire, utilisez le paramètre Octroyer l'accès en utilisant des hiérarchies. |
Règles de partage basées sur le propriétaire
Les règles de partage basées sur le propriétaire autorisent des exceptions aux paramètres par défaut de l'organisation et à la hiérarchie des rôles qui accordent à des utilisateurs supplémentaires l'accès aux enregistrements dont ils ne sont pas propriétaires. Les règles de partage basées sur le propriétaire sont basées uniquement sur le propriétaire de l'enregistrement.
Les règles de partage basées sur le propriétaire du contact ne s'appliquent pas aux contacts privés ou aux contacts qui ne sont pas associés à un compte.
La limite en nombre total de règles de partage par objet est de 300.
| Cas d'utilisation de règle de partage basée sur le propriétaire |
|---|
| Gestion matricielle basée sur le rôle ou situations de superposition : une personne dans Service doit pouvoir afficher certaines données commerciales, mais elle vit dans différentes branches de la hiérarchie. Par conséquent, vous pouvez créer une règle qui partage des données entre des rôles dans différentes branches. |
| Pour accorder l'accès aux données à des pairs qui ont le même rôle ou territoire. |
| Accorder l'accès aux données à d'autres groupes d'utilisateurs (groupes publics, portail, rôles, territoires). Les membres des groupements propriétaires des enregistrements peuvent être partagés avec les membres d'autres groupements. |
Règles de partage basées sur des critères
Les règles de partage basées sur des critères permettent d'accéder aux enregistrements en fonction de leurs valeurs de champ (critères). Si les critères sont remplis (une ou plusieurs valeurs de champ), un enregistrement de partage est créé pour la règle. La propriété de l'enregistrement n'est pas une considération.
La limite en règles de partage basées sur des critères et pour utilisateurs invités par objet est de 50.
| Cas d'utilisation de règle de partage basée sur des critères |
|---|
| Pour accorder l'accès aux données à des utilisateurs ou à des groupes en fonction de la valeur d'un champ dans l'enregistrement. |
Règles de partage pour utilisateurs invités
Une règle de partage pour utilisateurs invités est un type spécial de règle de partage basée sur des critères utilisé pour accorder l'accès aux enregistrements aux utilisateurs invités non authentifiés. La limite en règles de partage basées sur des critères et pour utilisateurs invités par objet est de 50.
Avertissement : Le type de règle de partage utilisateur invité accorde l'accès aux utilisateurs invités sans identifiant de connexion. En créant une règle de partage pour utilisateurs invités, vous autorisez l'accès immédiat et illimité à tous les enregistrements correspondant aux critères de la règle de partage pour tous les utilisateurs. Pour sécuriser vos données Salesforce et accorder à vos utilisateurs invités l'accès aux informations dont ils ont besoin, tenez compte de tous les cas d'utilisation et implications de la création de ce type de règle de partage. Mettez en œuvre les contrôles de sécurité que vous jugez appropriés pour la confidentialité de vos données. Salesforce n'est pas responsable de l'exposition de vos données à des utilisateurs non authentifiés en fonction de cette modification des paramètres par défaut.
| Cas d'utilisation de règle de partage pour les utilisateurs invités |
|---|
| Pour accorder l'accès aux données aux utilisateurs invités non authentifiés. |
Partage manuel
Il est parfois impossible de définir un groupe cohérent d'utilisateurs qui doivent accéder à un ensemble d'enregistrements particulier. Les propriétaires d'enregistrements ou d'autres utilisateurs disposant de privilèges adéquats, tels que les administrateurs système, peuvent utiliser le partage manuel pour accorder des autorisations de lecture et de modification aux utilisateurs qui n'ont pas accès autrement. Le partage manuel n'est pas automatisé, comme les paramètres de partage de l'organisation, les hiérarchies de rôles ou les règles de partage. Il offre toutefois aux propriétaires d'enregistrement la flexibilité nécessaire pour partager des enregistrements avec les utilisateurs qui doivent les afficher.
Le partage manuel est retiré lorsque le propriétaire de l'enregistrement change ou lorsque l'accès en partage accordé n'accorde pas un accès supplémentaire au-delà du niveau d'accès par défaut en partage de l'organisation. Cela s'applique également aux partages manuels créés par programmation.
Les enregistrements de partage manuel sont définis comme des enregistrements de partage avec la cause de ligne définie sur partage manuel.
Tous les enregistrements de partage (objets standard et personnalisés) avec une cause de ligne définie sur partage manuel peuvent être modifiés et supprimés par le bouton Partager de la présentation de page de l'objet, même si l'enregistrement de partage a été créé par programmation.
| Cas d'utilisation du partage manuel |
|---|
| Permettre à l'utilisateur d'accorder l'accès (lecture seule ou lecture/écriture) à l'enregistrement actuel à d'autres utilisateurs, groupes ou rôles. |
Équipes
Une équipe est un groupe d'utilisateurs qui travaillent ensemble sur un compte, une opportunité commerciale ou une requête. Les propriétaires d'enregistrement peuvent créer une équipe pour chaque enregistrement qui leur appartient. Le propriétaire de l'enregistrement ajoute les membres de l'équipe et spécifie le niveau d'accès de chaque membre à l'enregistrement. Certains membres de l'équipe peuvent avoir accès en lecture seule, tandis que d'autres ont accès en lecture/écriture.
Seuls les propriétaires, les personnes de rang supérieur dans la hiérarchie et les administrateurs peuvent ajouter des membres à l'équipe et accorder un accès supérieur au membre. Un membre de l'équipe qui a accès en lecture/écriture peut ajouter un autre membre qui a déjà accès à l'enregistrement auquel l'équipe est associée. Le membre de l'équipe ne peut pas lui accorder un accès supplémentaire.
La création d'un membre d'équipe dans l'application crée deux enregistrements : un enregistrement d'équipe et un enregistrement de partage associé. Si vous créez des membres d'équipe par programmation, vous devez gérer l'enregistrement de l'équipe et l'enregistrement de partage associé. Il n'y a qu'une seule équipe par enregistrement (Compte, Opportunité ou Requête). Si plusieurs équipes sont nécessaires, selon vos besoins spécifiques, pensez à la gestion des territoires ou au partage par programmation.
| Cas d'utilisation d'équipe |
|---|
| Offrir à l'utilisateur la possibilité d'accorder l'accès (lecture seule ou lecture/écriture) à un seul groupe d'utilisateurs (l'équipe). |
| Si les équipes sont gérées en externe, par exemple via une commission externe ou un système de gestion des territoires, l'intégration peut être utilisée pour gérer l'équipe du compte. Dans certains cas, la gestion des territoires dans un système externe peut correspondre à une solution d'équipe dans Salesforce. |
| Plusieurs propriétaires d'un compte peuvent être gérés par l'équipe du compte. |
| Un seul groupe d'utilisateurs (équipe) nécessite un accès en lecture seule ou en lecture/écriture à un enregistrement d'opportunité. (Équipe d'opportunité) |
Hiérarchie du territoire
Lors de l'utilisation de la Gestion des territoires d'entreprise, vous configurez une hiérarchie de territoires qui montre la structure des territoires d'un modèle et sert de point d'interaction principal. Si la Gestion des territoires d'entreprise est activée, vous devez gérer la hiérarchie des rôles et la hiérarchie des territoires. Pour plus d'informations, consultez Gestion des territoires d'entreprise dans l'aide de Salesforce.
Partage géré Apex
Le partage géré Apex (également appelé partage par programmation) permet d'utiliser un code pour élaborer des paramètres de partage sophistiqués et dynamiques lorsqu'une exigence d'accès aux données ne peut être satisfaite par aucun autre moyen.
Si vous créez un enregistrement de partage par programmation et que la cause de ligne prête à l'emploi (partage manuel) est utilisée, vous pouvez gérer cet enregistrement de partage avec le bouton Partager dans l'application. L'enregistrement de partage est soumis à toutes les règles qui entraînent le partage manuel de la ligne, par exemple la suppression lors du transfert du propriétaire.
Vous pouvez également créer vos propres motifs de partage Apex pour des objets personnalisés afin de suivre les raisons d'un enregistrement avec un utilisateur ou un groupe d'utilisateurs et simplifier le codage requis pour effectuer des mises à jour et des suppressions d'enregistrements de partage.
Pour plus d'informations, consultez Partage d'un enregistrement avec Apex avant d'envisager le partage par programmation.
| Cas d'utilisation de partage géré Apex |
|---|
| Aucune autre méthode de partage (déclarative) ne répond aux besoins d'accès aux données. |
| Il existe un système de vérité externe pour les attributions d'accès utilisateur qui continuera à piloter l'accès et à être intégré à Salesforce. |
| Performances médiocres en utilisant des composants de partage natifs. (s'applique généralement à des volumes de données très importants) |
| Fonctionnalité de l'équipe sur des objets personnalisés. |
Règles de restriction
Dans votre configuration d'accès aux données, vous pouvez empêcher les utilisateurs d'afficher les enregistrements qui peuvent contenir des données confidentielles ou qui ne sont tout simplement pas essentiels à leur travail. Vous pouvez utiliser des règles de restriction pour autoriser les utilisateurs à accéder uniquement aux enregistrements qui remplissent les critères que vous spécifiez. Lorsqu'une règle de restriction est appliquée à un utilisateur, les enregistrements auxquels il a accès via les paramètres par défaut de l'organisation, les règles de partage et d'autres mécanismes de partage sont filtrés par les critères que vous spécifiez. Les règles de restriction fonctionnent de la même façon que les composants de partage abordés dans cette rubrique. Au lieu d'ouvrir l'accès aux utilisateurs, elles le limitent davantage.
Les règles de restriction sont disponibles pour les objets personnalisés, les objets externes, les contrats, les événements, les tâches, les feuilles de temps et les entrées dans les feuilles de temps. Vous pouvez créer jusqu'à deux règles de restriction actives par objet dans les éditions Enterprise et Developer, et jusqu'à cinq règles de restriction actives par objet dans les éditions Performance et Unlimited. Des règles de restriction sont appliquées aux fonctionnalités Salesforce suivantes :
| Cas d'utilisation de règles de restriction |
|---|
| Vous souhaitez que certains utilisateurs affichent uniquement un ensemble spécifique d'enregistrements. |
| Pour simplifier le contrôle de l'accès aux enregistrements contenant des informations confidentielles ou confidentielles. |
| Rendre l'accès aux contrats, aux tâches et aux événements vraiment privé, car cela peut s'avérer difficile en utilisant les paramètres par défaut de l'organisation. |
Partage implicite
Le partage implicite est automatique. Vous ne pouvez ni la désactiver ni l'activer, elle est native de l'application. En d'autres termes, le partage implicite n'est pas un paramètre configurable. Cependant, il est important pour tout architecte de le comprendre. Le partage implicite parent permet d'accéder aux enregistrements parents (compte uniquement) lorsqu'un utilisateur a accès à des opportunités, des requêtes ou des contacts enfants pour ce compte. Salesforce a une stratégie d'accès aux données qui indique si un utilisateur peut afficher un contact (ou une opportunité, une requête ou une commande), l'utilisateur affiche implicitement le compte associé. Le partage implicite enfant permet au propriétaire du compte d'accéder aux enregistrements enfants d'un compte. Cet accès est défini au rôle du propriétaire dans la hiérarchie des rôles. Le partage implicite enfant s'applique uniquement aux objets contact, opportunité et requête (enfants du compte). Les niveaux d'accès qui peuvent être fournis sont Afficher, Modifier et Aucun accès pour chaque objet enfant lors de la création du rôle. En définissant sur Afficher, le propriétaire du compte peut implicitement afficher les enregistrements d'objet associés (contact, opportunité ou requête). En définissant Modifier, le propriétaire du compte peut implicitement modifier l'objet associé (contact, opportunité ou requête).
Le partage implicite ne s'applique pas aux objets personnalisés.
Il n'existe pas de modèle de partage adapté à toutes les organisations Salesforce. Chaque organisation a des exigences et des défis différents en essayant d'architecturer le meilleur modèle de partage. Il est essentiel d'utiliser les composants d'accès aux données les plus adaptés aux exigences de partage de l'organisation. Les scénarios suivants sont des défis courants lorsque vous essayez d'élaborer un modèle de partage.
| Exigences ou défis | Solution |
|---|---|
| Deux dans une boîte: un responsable commercial d'une zone de couverture géographique souhaite également accéder à une autre zone de couverture géographique afin d'aider. | Règle de partage basée sur le propriétaire : Une règle de partage basée sur le propriétaire fonctionne ici, car il s'agit de cas marginaux et non de la norme. Il est également acceptable que la règle de partage basée sur le propriétaire accorde un accès supérieur à ce qui est réellement nécessaire, car il s'agit d'un responsable - une personne de confiance. |
| Les utilisateurs des opérations basées sur un pays doivent avoir accès à toutes les données commerciales du pays. | Règle de partage basée sur le propriétaire : Une règle de partage est souvent utilisée lorsqu'un autre service (autre que commercial) doit accéder aux données commerciales. |
| Au moins 80 % du temps, il y a une équipe « core 4 » sur un compte (Account Executive, Inside Sales Rep, Sales Consultant, Technical Sales Rep). Le système d'enregistrement de l'attribution de l'équipe de compte est externe. Un compte ne contient toujours qu'une seule équipe. | Équipes : Comme il n'y a toujours qu'une seule équipe par compte, même si de nombreux membres ont des rôles différents, la fonctionnalité de l'équipe de compte répond à cette exigence. |
| Les responsables de l'équipe doivent avoir le même accès que leurs subordonnés. | Hiérarchie des rôles : La hiérarchie des rôles résout cette exigence en permettant aux responsables d'accéder aux données de leurs subordonnés. |
| L'équipe de compte attribuée ne doit pas être modifiable. | Équipes : Cette exigence n'est pas réellement satisfaite avec la fonctionnalité d'équipe de compte. Cependant, cela ne doit pas non plus vous empêcher d'utiliser des équipes de compte. Il existe cependant plusieurs façons de verrouiller les équipes. Dans ce cas, le retrait de la présentation de page de l'équipe de compte est utilisé. |
| Il doit y avoir une fonctionnalité « copain » afin que lorsqu'une personne est malade ou en vacances, une personne sans accès standard à un compte ou à une opportunité puisse être accédée et couverte pendant ses congés. | Équipes : Un « copain » peut simplement être un rôle dans l'équipe qui répond à cette exigence. Cependant, le défi vient de l'exigence précédente dans laquelle les équipes ne doivent pas être modifiables. La seule solution est d'avoir un groupe défini de personnes qui peuvent modifier les équipes pour créer le rôle de copain lorsque nécessaire. |
| Lorsqu'une affaire nécessite une solution personnalisée, des personnes supplémentaires (qui ne sont pas nécessairement dans l'organisation commerciale) doivent avoir accès à l'affaire. | Équipes : Une utilisation assez standard de l'équipe d'opportunité en ajoutant manuellement un nouveau membre à l'équipe d'opportunité (via une liste associée). Peut également être réalisé via un déclencheur si vous savez toujours qui doit être ajouté. Dans ce cas, il s'agit d'opportunité par opportunité. |
| Exigences ou défis | Solution |
|---|---|
| Deux équipes d'opportunité différentes de deux unités commerciales distinctes (Ventes au détail et Remarketing) doivent accéder au même enregistrement de compte. Ils doivent partager des contacts et être informés de toutes les activités du compte. Ces deux unités commerciales ont leur propre hiérarchie et leurs propres cumuls. | Gestion des territoires : La meilleure façon de concevoir cette exigence est d'avoir deux branches d'une hiérarchie qui peuvent être structurées différemment. Ce qui justifie la gestion des territoires, c'est qu'il y a deux niveaux de ces deux branches différentes (les deux niveaux avec des membres = l'équipe d'opportunité de cette unité commerciale) qui doivent accéder au compte. Vous auriez pu satisfaire à cette exigence avec un concept Teaming, mais c'était trop granulaire. La segmentation des ventes n'était pas au niveau du compte, mais dans une hiérarchie. |
| Il existe un groupe distinct de développeurs commerciaux attribués et qui doivent accéder à des comptes spécifiques pour une équipe d'opportunité spécifique (un territoire). Les développeurs commerciaux sont des ressources partagées pour les équipes d'opportunité, ce qui signifie que chaque développeur commercial peut être attribué à un ou plusieurs comptes pour une ou plusieurs équipes d'opportunité. | Gestion des territoires : Comme il s'agit d'un groupe d'utilisateurs (ou d'une équipe), et que chaque équipe de développement commercial peut être différente selon le compte, et que la gestion des territoires était nécessaire pour une autre raison, la meilleure approche consiste probablement à établir des sous-territoires ou des succursales distinctes qui représentent ces équipes de développement commercial. |
| Certains rôles de support commercial non basés sur la commission doivent accéder aux comptes de façon ponctuelle. | Équipes : La partie clé de l’exigence est « unique ». Cela signifie qu'il est effectué compte par compte, donc les équipes de compte fournissent cela en natif. |
| Le service de crédit doit accéder à tous les comptes d'une unité commerciale donnée. | Règle de partage basée sur le propriétaire : C'est une situation où dans l'ensemble, pour une unité commerciale donnée, un groupe d'utilisateurs doit tout afficher. Cette exigence pourrait être satisfaite avec une règle de partage pour un rôle auquel le groupe appartient, une branche de la hiérarchie des rôles à laquelle le groupe appartient (rôle et subordonnés) ou même un groupe public.Gestion de territoire : Vous pouvez également satisfaire à cette exigence en modélisant le service de crédit en tant que territoire avec la même logique pour l'unité commerciale donnée. |
| Les responsables doivent avoir le même accès que leurs subordonnés. | Hiérarchie des rôles : La hiérarchie des rôles résout cette exigence en permettant aux responsables d'accéder aux données de leurs subordonnés. |
Que devient la hiérarchie des rôles ?
La hiérarchie des rôles n'est pas affectée si vous utilisez également une hiérarchie de territoires. Cependant, si vous utilisez ensemble les prévisions basées sur le territoire et les prévisions basées sur le rôle, vous devez gérer deux hiérarchies. Dans ce cas, nous recommandons d'utiliser la hiérarchie des rôles pour modéliser la structure hiérarchique des RH, puis d'utiliser la hiérarchie des territoires pour modéliser la hiérarchie commerciale réelle. La hiérarchie des territoires est plus efficace pour modéliser une structure hiérarchique matricielle, dans laquelle une personne peut rendre compte à plusieurs responsables.
Si vous n'utilisez pas ensemble les prévisions basées sur le territoire et les prévisions basées sur le rôle, vous pouvez utiliser uniquement la hiérarchie des territoires en tant que hiérarchie commerciale. Dans ce scénario, il est préférable de simplifier ou d'aplatir autant que possible la hiérarchie.
Nous recommandons de ne pas définir une hiérarchie des rôles et une hiérarchie des territoires identiques, car cela entraîne une activité de partage inutile.
Peut-on encore utiliser Teams ?
Réalignement et réattribution
Volumes de données importants
Que vous modélisiez pour le déploiement initial ou planifiez un changement de réalignement, vous devez prendre sérieusement en compte le volume de données. Il existe des seuils dans lesquels les performances peuvent devenir un facteur. Par conséquent, il est vivement recommandé de tester vos modifications dans une organisation sandbox avant la production. Ces tests vous donneront également une base de référence pour la durée de la modification.
Si vous avez plus de deux millions de comptes, et avez implémenté des équipes ou la Gestion des territoires d'entreprise, vous devez particulièrement faire attention aux performances. Ce sont des composants de modèle de partage complexes qui peuvent générer un volume énorme d'enregistrements de partage et, par conséquent, de longues transactions.
Report des calculs de partage
Données et propriétés biaisées
Les biais de données sont définis comme quelques enregistrements parents avec de nombreux enregistrements enfants. Ces biais peuvent vraiment vous nuire lorsque quelques comptes ont de nombreux contacts, opportunités ou requêtes. Le ratio où nous commençons à observer une dégradation des performances est de 1:10 000. La meilleure pratique recommande de garder le ratio aussi proche que possible (il est préférable de le réduire).
Les asymétries de propriété sont similaires aux asymétries de données, sauf que nous faisons référence à un utilisateur, un rôle ou un groupe unique possédant de nombreux enregistrements pour un objet. De la même façon que les asymétries de données, elles peuvent également entraîner de longues transactions en cours, entraînant une dégradation des performances en cas de changement. Le ratio recommandé entre le propriétaire et le nombre d'enregistrements est également de 1:10 000.
Si un seul utilisateur possède plus de 10 000 enregistrements, la meilleure pratique consiste à :
L'enregistrement utilisateur du propriétaire ne doit pas avoir de rôle dans la hiérarchie des rôles.
Si l'enregistrement utilisateur du propriétaire doit contenir un rôle, placez-le en haut de la hiérarchie dans sa propre branche de la hiérarchie des rôles.
Impact des hiérarchies de comptes sur l'accès aux données
Une fois l'architecture de votre modèle de partage terminée, vous serez probablement confronté aux raisons pour lesquelles un utilisateur peut ou ne peut pas afficher un enregistrement. Généralement, vous n'entendrez pas quand les utilisateurs peuvent afficher quelque chose qu'ils ne devraient pas, mais si nécessaire, vous pouvez afficher chaque utilisateur qui a accès à un enregistrement et pourquoi.
Le défi le plus difficile, et probablement le plus fréquent, est la raison pour laquelle un utilisateur ne peut pas afficher un enregistrement. Les couches de sécurité que vous avez conçues déterminent votre point de départ. Si vous connaissez bien le modèle de partage, vous saurez probablement quel composant aurait dû fournir l'accès et peut commencer là. Cependant, si vous êtes moins familier avec le modèle de partage, commencez par la hiérarchie des rôles et épluchez chaque couche pour déterminer laquelle doit accorder l'accès. Voici un flux de dépannage.
j
