Création d'une hiérarchie des rôles

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

• Expliquer en quoi une hiérarchie des rôles est différente de l'organigramme d'une organisation
  
• Afficher et modifier une hiérarchie des rôles
  
• Créer et attribuer des rôles pour simplifier l'accès aux enregistrements
  

Remarque

Vous souhaitez apprendre en français ? Commencez le défi dans un Trailhead Playground en français et utilisez les traductions fournies entre crochets pour naviguer. Copiez et collez uniquement les valeurs en anglais, car les validations de défi reposent sur les données en anglais. Si vous ne réussissez pas le défi dans votre organisation en français, nous vous recommandons (1) de définir le paramètre régional sur les États-Unis, (2) de définir la langue sur l’anglais en suivant les instructions ici, puis (3) de cliquer à nouveau sur le bouton « Vérifier le défi ».

Consultez le badge Trailhead dans votre langue pour découvrir comment profiter de l’expérience Trailhead traduite.

Création et modification des rôles

Une hiérarchie de rôles fonctionne avec des paramètres de partage afin de déterminer les niveaux d'accès des utilisateurs à vos données Salesforce. Les utilisateurs peuvent accéder aux données de tous les utilisateurs de rang immédiatement inférieur au leur dans la hiérarchie.

Les utilisateurs qui doivent afficher de grandes quantités de données (par exemple les PDG, les vice-présidents et autres dirigeants) figurent souvent en haut de la hiérarchie. Cependant, il n'est pas nécessaire que la hiérarchie des rôles corresponde exactement à l'organigramme de votre organisation. Chaque rôle d'une hiérarchie représente seulement un niveau d'accès aux données dont un utilisateur ou un groupe d'utilisateurs a besoin.

• Les utilisateurs ont toujours accès aux données détenues par leurs subordonnés ou partagées avec ceux-ci dans la hiérarchie des rôles, quels que soient les paramètres par défaut à l’échelle de l’organisation. La seule exception concerne les objets personnalisés, dont vous pouvez désactiver l’accès à l’aide de hiérarchies.
  
• Les utilisateurs qui accèdent généralement à des enregistrements de même type peuvent être regroupés. Nous allons utiliser ces groupes plus loin en évoquant les règles de partage.
  

Selon les paramètres de partage de votre organisation, les rôles peuvent contrôler le niveau de visibilité des utilisateurs sur vos données Salesforce. Les utilisateurs, quel que soit le niveau de leur rôle, peuvent afficher, modifier et générer des rapports sur toutes les données détenues ou partagées par les utilisateurs de niveau inférieur dans la hiérarchie des rôles, sauf indication contraire dans le modèle de partage d'un objet de votre organisation. Plus précisément, dans la liste associée Organization-Wide Defaults (Valeurs par défaut à l’échelle de l’organisation), si l’option Grant Access Using Hierarchies (Octroyer l’accès par le biais des hiérarchies) est désactivée pour un objet personnalisé, seul le propriétaire de l’enregistrement et les utilisateurs disposant d’un accès via les paramètres par défaut de l’organisation ont accès aux enregistrements de l’objet.

Au-delà de la définition des paramètres de partage par défaut à l'échelle de l'organisation pour chaque objet, vous pouvez spécifier si les utilisateurs ont accès aux données appartenant à ou partagées avec leurs subordonnés dans la hiérarchie. Par exemple, la hiérarchie de rôles accorde automatiquement l'accès aux enregistrements aux utilisateurs de niveau supérieur au propriétaire de l'enregistrement dans la hiérarchie. Par défaut, l’option Grant Access Using Hierarchies (Octroyer l’accès par le biais des hiérarchies) est activée pour tous les objets. Elle peut être modifiée uniquement pour des objets personnalisés.

Pour contrôler l’accès en partage à un objet personnalisé en utilisant les hiérarchies, saisissez Sharing Settings (Paramètres de partage) dans la zone Quick Find (Recherche rapide), puis sélectionnez Sharing Settings (Paramètres de partage). Dans la section Organization Wide Defaults (Valeurs par défaut à l’échelle de l’organisation), cliquez sur Edit (Modifier). Désélectionnez l’option Grant Access Using Hierarchies (Octroyer l’accès par le biais des hiérarchies) si vous souhaitez empêcher les utilisateurs d’accéder automatiquement aux données appartenant à ou partagées par leurs subordonnés dans les hiérarchies.

Définition d'une hiérarchie des rôles

La mise en œuvre d'une hiérarchie des rôles sur la plate-forme est aisée une fois que vous l'avez définie. Il est préférable de commencer en suivant l'organigramme de votre société, puis de regrouper diverses fonctions dans des rôles uniques dès que possible.

Par exemple, si un groupe de développement logiciel inclut un ingénieur logiciel senior et un ingénieur logiciel junior, ces postes peuvent être regroupés dans un rôle Ingénieur logiciel unique dans la hiérarchie. Une fois terminé, vous pouvez commencer à définir la hiérarchie des rôles.

1. Dans Settings (Configuration), dans la zone Quick Find (Recherche rapide), saisissez Roles (Rôles), puis sélectionnez Roles (Rôles). Si une page de démarrage appelée Understanding Roles (Compréhension des rôles) s’affiche, cliquez sur Set Up Roles (Configurer des rôles) en bas de la page pour passer à l’outil proprement dit. La vue par défaut de cette page est la vue arborescente, comme indiqué dans la liste déroulante située à droite de la barre de titre Role Hierarchy (Hiérarchie des rôles). Lors de la création d'une hiérarchie des rôles, il est préférable de conserver cette vue ou d'utiliser la vue de liste, car elles permettent d'observer comment les rôles s'organisent dans la hiérarchie. La vue de liste triée est préférable si vous connaissez le nom d'un rôle que vous souhaitez retrouver alors que vous ne connaissez pas son emplacement dans la hiérarchie, ou si vous souhaitez ouvrir tous les nœuds de l'arborescence. Dans notre exemple, nous allons conserver la vue arborescente. Lorsque vous commencez à définir une hiérarchie des rôles, la vue arborescente affiche un nœud d’espace réservé unique portant le nom de votre organisation. À ce stade, nous devons ajouter le nom du rôle le plus élevé dans la hiérarchie, soit PDG dans notre exemple. Si vous créez votre application avec une organisation Developer Edition ou Trailhead Playground gratuite, vous pouvez recevoir un exemple de hiérarchie des rôles prédéfinie. Ne vous inquiétez pas. Vous pouvez suivre notre progression et créer d'autres rôles.
   
2. Sous le nom de la société, cliquez sur Add Role (Ajouter un rôle). Si le rôle de PDG existe déjà, cliquez sur Edit (Modifier).
   
3. Dans la zone de texte Label (Étiquette), saisissez CEO (PDG). La zone de texte Role Name (Nom du rôle) est automatiquement renseignée avec CEO (PDG).
   
4. Dans la zone de texte This role reports to (Rattachement hiérarchique de ce rôle), cliquez sur l'icône de référence, puis cliquez sur Select (Sélectionner) en regard du nom de l'organisation. En sélectionnant le nom de l’organisation dans la zone de texte This role reports to (Rattachement hiérarchique de ce rôle), nous indiquons que ce rôle de PDG est le poste le plus élevé dans notre hiérarchie des rôles et qu’il n’a pas de supérieur.
   
5. Dans la zone de texte Role Name as displayed on reports (Nom du rôle tel qu’il est affiché dans les rapports), saisissez CEO (PDG). Ce texte est utilisé dans les rapports pour indiquer le nom d'un rôle. Les noms de rôle longs tels que Vice-Président du développement des produits occupent un espace excessif dans les colonnes de rapport. Par conséquent, nous recommandons d'utiliser une abréviation explicite.
   
6. Laissez les autres options, telles que Opportunity Access (Accès à l’opportunité), définies sur leur valeur par défaut, puis enregistrez. Ces options d’accès ne concernent pas notre application de recrutement. Elles s’affichent uniquement si vous avez des paramètres par défaut à l’échelle de l’organisation définis sur un niveau plus restrictif que Public Read/Write (Accès public en lecture/écriture) pour un objet standard.
   
7. Vous avez créé votre premier rôle. Vous pouvez maintenant lui attribuer l'utilisateur approprié. Cliquez sur CEO (PDG), puis sur la page de détail du rôle PDG, cliquez sur Assign Users to Role (Affecter des utilisateurs au rôle). 
   
8. Dans la liste déroulante Available Users (Utilisateurs disponibles), sélectionnez All Unassigned (Tous les non attribués).
   
9. Choisissez un utilisateur dans la liste, cliquez sur Add (Ajouter) pour déplacer son nom vers la liste Selected Users for CEO (Utilisateurs sélectionnés pour PDG), puis enregistrez.
   

Si vous revenez à la page Roles (Rôles) dans Setup (Configuration), le rôle de PDG est désormais affiché dans la hiérarchie. Vous pouvez définir le reste des rôles en fonction de votre organigramme de hiérarchie des rôles. Il n'est pas nécessaire d'attribuer immédiatement des utilisateurs à chaque rôle, vous pouvez le faire plus tard en créant les autres utilisateurs et en testant votre application.

Pour accélérer le processus d’ajout d’un nouveau rôle, cliquez sur Add Role (Ajouter un rôle) directement sous le nom du rôle auquel il est subordonné. Dans ce cas, la zone de texte This role reports to (Rattachement hiérarchique de ce rôle) est automatiquement renseignée avec le nom du rôle approprié.

Hiérarchie des rôles pour l'application de recrutement

Examinons une branche de la hiérarchie des rôles avec une société fictive qui utilise notre exemple d’application de recrutement. Souvenez-vous, avec les paramètres par défaut de l'organisation que nous avons définis, les responsables du recrutement sont autorisés à afficher (pas à créer ni à mettre à jour) tous les enregistrements de poste, de publication d'offre d'emploi et de site Web d'emploi, et à afficher et mettre à jour les autres enregistrements de recrutement qui leur appartiennent. Notre application n'est pas très utile ainsi. Cependant, lorsque notre hiérarchie des rôles est en place, nos utilisateurs peuvent récupérer les données dont ils ont besoin et notre application est opérationnelle.

Cette hiérarchie des rôles accorde automatiquement les types d'autorisations suivants au niveau de l'enregistrement :

• La PDG, Cynthia, peut afficher et mettre à jour chaque enregistrement que toute autre personne de l'organisation peut afficher et mettre à jour.
  
• Le Vice-président du développement, Andrew, peut afficher et mettre à jour n'importe quel enregistrement que ses responsables ou les employés de ses responsables peuvent afficher ou mettre à jour.
  
• La Vice-présidente des ressources humaines, Megan, peut afficher et mettre à jour n'importe quel enregistrement que Phil, son responsable du recrutement, ou Mario, le recruteur de Phil, peut afficher et mettre à jour.
  
• Le Responsable du recrutement, Phil, peut afficher et mettre à jour n'importe quel enregistrement qui appartient à Mario, son recruteur.
  
• Le Responsable de développement logiciel, Ben, peut afficher et mettre à jour n'importe quel enregistrement qui appartient à Melissa, Tom ou Craig, ses ingénieurs logiciel.
  
• Le Directeur du contrôle qualité, Clark, peut afficher et mettre à jour n'importe quel enregistrement qui appartient à Flash ou Harry, ses ingénieurs qualité.
  

Comme vous pouvez le constater, la hiérarchie des rôles est une méthode puissante pour ouvrir l'accès aux données aux personnes qui en ont besoin.

Une fois les paramètres par défaut de l'organisation et la hiérarchie des rôles définis, vous en avez bientôt terminé avec les autorisations d'accès au niveau de l'enregistrement pour l'application de recrutement. Il ne reste plus qu'à partager des enregistrements associés au recrutement entre des groupes situés dans des branches séparées de la hiérarchie des rôles et entre des membres d'un groupe unique. Nous pouvons accomplir ces deux tâches avec une combinaison de règles de partage et de partage manuel.

Ressources

• Contrôle d'accès avec les hiérarchies
  
• Guide de mise en œuvre de la sécurité