Gérer les accès au niveau de l'organisation

Présentation

Tout le reste de ce cours provisionne de la structure. Cette leçon provisionne la portée d'accès.

L'accès sur la plateforme n'est pas une seule échelle. Il s'agit de trois choses séparées, et les confondre est la manière dont des personnes finissent avec plus d'accès que prévu.

Ces trois niveaux sont ceux qui accordent l'accès. Les équipes existent encore au niveau organisation, mais elles n'accordent rien aujourd'hui et n'ont pas d'interface de gestion : elles sont conservées pour de futures fonctionnalités à l'échelle de l'organisation. Les personnes d'un projet sont des membres du projet, ajoutés directement et individuellement ; rien n'est accordé à un projet par une équipe.

Comment un projet obtient son premier membre

Une organisation et ses projets sont provisionnés par l'Org Admin, c'est-à-dire Kapitable. Le client ne crée pas les projets.

Chaque projet commence donc par un acte délibéré : l'Org Admin invite une personne comme Project Admin. À partir de là, le client fonctionne seul : ce Project Admin invite le reste de l'équipe et gère leurs rôles, sans avoir à revenir vers nous.

Cette forme compte pour deux raisons. Elle garde la gestion des membres du projet entre les mains des personnes qui savent qui doit être sur le deal, et elle signifie que la première invitation est l'attribution à bien faire : la personne qui la reçoit peut étendre l'accès à n'importe qui d'autre.

Ce que vous allez apprendre

• Pourquoi Super Admin n'est pas un accès aux données

• Ce qui rend Org Admin qualitativement différent d'un rôle de projet

• Pourquoi retirer l'accès est la moitié la plus difficile

• Ce qu'il faut revoir, et à quelle fréquence

Super Admin n'est pas un accès aux données

Cela mérite d'être posé d'abord parce que c'est contre-intuitif : le statut Super Admin ne donne pas à lui seul accès aux données client. Un Super Admin administre la plateforme. Pour voir les projets d'un client, il doit être délibérément ajouté comme Org Admin de cette organisation.

Cette séparation est une fonctionnalité. Ne traitez pas Super Admin comme un rôle d'accès complet.

Org Admin est l'attribution à manier avec prudence

Un Org Admin a accès à chaque projet sous l'organisation, y compris, surtout, les projets qui n'existent pas encore. Une attribution faite aujourd'hui couvre les deals signés l'an prochain.

Comparez cela à un rôle de projet, qui atteint exactement un projet et doit être accordé à nouveau pour le suivant. Org Admin est qualitativement différent, pas seulement plus large, et la boîte de dialogue d'invitation n'indique pas cette portée future.

Donc :

• Accordez-le à peu de personnes, et à des personnes dont le rôle couvre réellement tout le portefeuille de la firme.

• Ne l'accordez pas pour résoudre un problème au niveau d'un projet. Une personne à qui il manque un bouton sur un projet a besoin d'un rôle de projet (A2.6), pas d'une portée organisationnelle.

• Revoyez-le. Un rôle de projet devient inutile lorsqu'un projet se termine ; une attribution Org Admin n'expire pas.

L'invitation est une simple adresse e-mail, et la plateforme vous indique si cette personne détient déjà le rôle.

Retirer l'accès est la moitié la plus difficile

Les rôles de projet sont par projet. Retirer quelqu'un d'un projet ne le retire pas d'un autre, et il n'existe pas d'écran unique qui retire une personne partout.

Les départs nécessitent donc une checklist, pas de la mémoire. Écrivez-la pour votre organisation : quels projets, et quelles attributions Org Admin.

Comptes utilisateurs dans l'espace d'administration liste les utilisateurs de la plateforme et la date de création de leurs comptes. C'est un annuaire plutôt qu'un outil de révocation, mais savoir qui existe est la première étape pour savoir qui ne devrait plus exister.

Soyez conscient de la lacune que cela laisse : il n'existe pas de vue unique de l'accès d'une personne. Pour répondre à « que peut voir cette personne ? », vous devez vérifier la liste des membres de chaque projet, plus les attributions Org Admin. Dans une organisation avec vingt projets, une checklist est le contournement honnête.

Conseils pratiques

• Le niveau le plus étroit qui fonctionne, toujours.

• Org Admin délibérément et rarement.

• Jamais Super Admin comme raccourci vers les données.

• Les départs nécessitent une checklist couvrant chaque projet.

• Revoyez périodiquement les attributions Org Admin : rien d'autre ne vous y invitera.

Problèmes fréquents

Un Super Admin ne peut pas voir le projet d'un client. Intentionnel. Ajoutez-le comme Org Admin de cette organisation s'il en a besoin.

Quelqu'un a encore accès après avoir quitté un deal. Les rôles de projet sont par projet. Vérifiez chacun.

Vous êtes sur le point d'accorder Org Admin pour corriger un contrôle manquant. Ne le faites pas. C'est une question de rôle au niveau du projet (A2.6).

Personne ne sait qui a accès à quoi. Il n'existe pas de vue unique de l'accès d'une personne dans l'organisation. Tenez votre propre registre.

Articles liés

• C1.1 — Organisations · où Org Admin est accordé

• A1.4 — Rôles et visibilité · les rôles au niveau du projet

• A2.6 — Le contrôle des accès en pratique · résoudre correctement un problème au niveau du projet

• A5.10 — Traçabilité : ce que la plateforme enregistre · l'autre moitié d'une conversation sur les contrôles