Profils, rôles et partage dans une organisation REDA
REDA fournit des ensembles d’autorisations et des modèles de partage sur ses objets. Les profils, la hiérarchie des rôles et les règles de partage de votre organisation restent à configurer selon vos besoins. Cet article précise les responsabilités : les ensembles contribuent à déterminer les fonctionnalités utilisables ; profils, ensembles et partage définissent ensemble les accès de base et les enregistrements visibles par chacun. Les procédures détaillées renvoient à Salesforce. Vous pourrez ainsi vérifier ce que le package fournit et compléter la configuration de votre organisation.
Autorisations nécessaires. Selon l’action, il faut pouvoir gérer les profils et ensembles d’autorisations, gérer les rôles ou gérer le partage. Attribuez les droits administratifs appropriés ; le package Sales Cloud fournit notamment ces autorisations dans REDA - Multi Factor Authentication Admin. Cet ensemble étendu ne constitue pas un accès courant à attribuer à tous.
Deux responsabilités distinctes
Distinguez ces deux niveaux complémentaires, puis vérifiez leur combinaison effective pour chaque responsabilité :
- Accès aux fonctionnalités : cette personne peut-elle gérer les locations, la facturation, les réservations ou les inspections ? REDA fournit cet accès avec ses ensembles d’autorisations (voir Créer des utilisateurs et leur accorder l’accès à REDA).
- Accès de base et visibilité des enregistrements : ouvrir les comptes, exécuter des rapports et voir les fiches d’autres personnes dépend des profils, des ensembles attribués, de la hiérarchie des rôles et des paramètres de partage. Vous configurez ce modèle dans votre organisation en tenant compte des autorisations et valeurs initiales fournies.
Les profils dans une organisation REDA
Un profil porte les réglages de base d’un utilisateur, dont l’application par défaut. Les ensembles d’autorisations peuvent compléter ses droits sur les objets, rapports, flux et onglets. Vérifiez les droits cumulés avant d’ajouter ce qui manque :
- Objets standard : certains ensembles REDA accordent déjà l’accès aux comptes et contacts, notamment Property Leasing User. Vérifiez séparément les droits requis sur les tâches et événements, et les droits précis de lecture, création ou modification de chaque objet.
- Rapports, flux et modification des tâches : plusieurs ensembles REDA accordent déjà ces droits. Par exemple, Property Leasing User fournit RunReports, RunFlow et EditTask dans les deux éditions. Complétez uniquement les autorisations qui manquent au parcours utilisateur.
- Application par défaut et visibilité des onglets : les applications REDA et REDA Admin sont fournies. Vérifiez leur disponibilité et les onglets via le profil et les ensembles attribués ; le profil définit l’application par défaut.
En pratique, conservez des profils minimaux pour les accès de base, puis ajoutez les ensembles fonctionnels REDA.
Pourquoi REDA utilise des ensembles d’autorisations plutôt que des profils
Le package ne fournit aucun profil personnalisé ni groupe d’ensembles d’autorisations. Vous attribuez ses ensembles individuels selon les responsabilités. Vous pouvez créer vos propres groupes dans l’organisation pour faciliter ces attributions. Vérifiez néanmoins les profils existants : l’administrateur peut y avoir configuré des accès REDA.
La hiérarchie des rôles
La hiérarchie des rôles est le mécanisme Salesforce qui permet à un responsable de consulter les enregistrements des personnes placées sous sa responsabilité. REDA ne fournit aucune hiérarchie : vous la concevez. Dans une organisation REDA, elle sert principalement à donner au responsable d’agence la visibilité sur les opérations, les biens et les tickets de son équipe. La création des rôles suit la procédure Salesforce ; l’objectif est ici la visibilité managériale.
Partage : valeurs par défaut de l’organisation et règles de partage
Les paramètres par défaut à l’échelle de l’organisation (OWD) définissent la visibilité de base. Les règles de partage étendent cet accès. Les objets du package portent des modèles initiaux, mais le package ne définit aucune hiérarchie ni règle de partage propre à votre organisation. Vérifiez l’état réellement configuré avant de l’adapter.
Les objets transactionnels dotés de leur propre modèle de partage comprennent l’Opportunité Platform, la Propriété, la Demande de renseignements, le Ticket et la commission. Les factures et charges d’opportunité sont, elles, contrôlées par leur parent dans les métadonnées des deux éditions. Les données de référence ne sont pas nécessairement publiques : la Région, par exemple, est déclarée privée dans les packages récupérés. Les droits d’objet et le partage doivent tous deux permettre l’accès.
Dans les métadonnées Platform récupérées, Propriété, Demande de renseignements, Ticket et Région sont Privé, alors qu’Opportunité est Accès public en lecture/écriture. Ce sont des valeurs de référence du package, pas une observation du partage actuel de votre organisation. Adaptez les objets modifiables aux besoins de confidentialité ; ceux contrôlés par le parent héritent de sa visibilité.
Répartition des responsabilités
Ce tableau distingue ce que REDA fournit de ce que vous configurez :
| Sujet | Fourni par REDA | Configuration dans votre organisation |
|---|---|---|
| Accès aux fonctions : location, facturation, réservations… | 31 ensembles Platform ; 27 Sales Cloud, avec des droits et libellés propres à chaque édition | Attribuer selon les responsabilités |
| Objets standard : Compte, Contact, Tâche, Événement | Certains ensembles accordent déjà les comptes, contacts et objets CRM selon l’édition | Vérifier les droits cumulés et compléter les accès nécessaires |
| Rapports, exécution de flux, modification de tâches | Accordés par plusieurs ensembles, notamment Property Leasing User | Vérifier chaque parcours et compléter les droits manquants |
| Profils personnalisés | — (aucun dans le package) | Créer des profils minimaux pour les accès de base |
| Groupes d’ensembles d’autorisations | — (aucun dans le package) | Facultatif : créer vos propres groupes pour regrouper les ensembles REDA |
| Hiérarchie des rôles | — (aucune dans le package) | La concevoir pour la visibilité des responsables sur leurs équipes |
| Valeurs OWD et règles de partage | Modèles de partage initiaux sur les objets ; pas de règles propres à votre organisation | Vérifier les valeurs effectives et configurer les règles adaptées, en respectant les objets contrôlés par le parent |
| Visibilité des applications et des onglets | Applications REDA et REDA Admin fournies | Vérifier profil et ensembles attribués ; définir l’application par défaut dans le profil |
Exemple : les accès d’une agence de six personnes
L’agence Meridian Properties comprend un responsable, trois agents de location, un comptable et un auditeur. La conception de leurs accès porte sur les trois niveaux :
Si l’agence souhaite ensuite attribuer des accès groupés en une seule opération, elle peut réunir les ensembles REDA les plus utilisés dans son propre groupe d’ensembles d’autorisations. REDA n’en fournit pas, mais vous pouvez en créer.
Pour aller plus loin
- Créer des utilisateurs et leur accorder l’accès à REDA : créer l’utilisateur et attribuer les ensembles REDA.
- Comprendre les ensembles d’autorisations REDA : les 31 ensembles Platform et 27 ensembles Sales Cloud.
- Le modèle d’accès REDA : identifier l’ensemble requis pour une tâche.
- Sécuriser votre organisation REDA : sécuriser l’authentification et les sessions.
- Éditions : OEM et ISV : connaître les objets de chaque édition.
Questions fréquentes
Le package ne fournit pas de profil personnalisé. Configurez vos profils et attribuez les ensembles REDA appropriés, puis vérifiez les droits cumulés. Certains ensembles accordent déjà des objets standard, rapports et flux ; complétez les besoins restants.
Vérifiez les droits d’objet, la hiérarchie des rôles et le partage réellement configuré. Définissez la visibilité managériale et les règles nécessaires ; les paramètres initiaux du package ne remplacent pas cette conception.
Choisissez selon les besoins de confidentialité et de collaboration de votre organisation. L’objet Opportunité Platform est déclaré en accès public lecture/écriture dans les métadonnées récupérées, mais votre organisation peut avoir un autre réglage. Les factures et charges contrôlées par leur parent suivent sa visibilité.
Oui. Créez votre propre groupe d’ensembles d’autorisations dans l’organisation. REDA n’en fournit pas, mais vous pouvez combiner ses ensembles pour les attribuer en une seule opération.
Les questions de visibilité sont communes, mais les paramètres disponibles et les modèles initiaux ne sont pas nécessairement identiques. Sales Cloud utilise notamment Piste, Opportunité, Requête et Campagne standard ; Platform utilise leurs équivalents personnalisés. Examinez les objets et réglages effectifs de votre édition.
Cet article vous a-t-il été utile ?