En bref : sur une plateforme Multi-Org, deux réglages différents décident de ce qu'une personne voit. Le rôle dit ce qu'elle peut faire. L'organisation dit sur quelles données elle le fait. Les confondre est la cause la plus fréquente des « pourquoi je ne vois pas cette application ».
Deux réglages, deux questions différentes
Réglage | La question à laquelle il répond |
Rôle | Cette personne peut-elle modifier une autorisation, créer une campagne, gérer les utilisateurs ? |
Organisation | Sur le parc de quelle entité peut-elle le faire ? |
Un Admin reste un Admin de son entité. Il a tous les droits de la plateforme, appliqués à un périmètre de données qui n'est pas celui du Groupe.
Rattacher une personne à son organisation
Le champ Organisation apparaît dans le formulaire d'un utilisateur, sous le rôle. Il n'existe que si votre plateforme est en Multi-Org et si des domaines sont configurés.
Paramètres puis Rôles et Permissions puis Utilisateurs.
Ouvrez la fiche de la personne, ou créez-la.
Dans Organisation, sélectionnez son entité.
Enregistrez.
À partir de là, la personne travaille dans le périmètre de cette entité : l'inventaire des applications, les Fiches Produit, les fiches de dimension, la matrice de priorisation, les workflows, les thèmes et champs personnalisés, et le périmètre interrogé par Ask Beamy.
ℹ️ L'assistant répond dans le périmètre de qui l'interroge. Deux personnes de deux entités qui posent la même question à Ask Beamy obtiennent deux réponses différentes, et les deux sont justes.
⚠️ Le champ est obligatoire quand il s'affiche. Une personne sans organisation sur une plateforme Multi-Org est une personne dont le périmètre n'est pas défini : réglez-le à la création, pas au premier ticket.
Ouvrir les fonctionnalités Groupe
Sous le champ Organisation, un interrupteur porte le nom de votre domaine racine, en général Accès fonctionnalités Groupe. Il ouvre deux choses, et seulement deux :
Visualiser l'ensemble des données consolidées de la plateforme, toutes entités confondues.
Définir des règles de gouvernance à propager à l'ensemble de l'organisation.
C'est ce second point qui compte le plus. C'est lui qui permet de poser une autorisation Groupe par-dessus les autorisations que chaque entité définit pour elle-même.
⚠️ Le droit Groupe n'est pas un rôle supérieur, c'est une levée de cloison. Il ne donne aucune permission nouvelle : quelqu'un qui ne peut pas modifier une autorisation dans son entité ne le pourra pas davantage au niveau du Groupe. Le rôle dit toujours ce qu'on peut faire ; le droit Groupe élargit seulement le périmètre sur lequel on le fait.
Réservez-le aux personnes qui pilotent réellement la politique commune. Trois ou quatre par groupe suffisent en général.
Le diagnostic à faire avant d'ouvrir un ticket
Quand quelqu'un dit « je ne vois pas cette application », posez les questions dans cet ordre :
Quelle est son organisation ? Si l'application appartient à une entité sœur, c'est le cloisonnement qui fonctionne, pas un bug.
A-t-il le droit Groupe ? Sans lui, les données consolidées lui restent fermées, quel que soit son rôle.
Quel est son rôle ? C'est seulement ici que se joue le droit de modifier plutôt que de lire.