Rôles et permissions
Les cinq postes, ce à quoi chacun a accès, et les trois façons de restreindre encore l'accès
Chaque membre de votre organisation a un rôle. Le rôle détermine quelles pages existent pour lui, et le serveur l'applique : une page absente de votre barre latérale est aussi une page qui ne s'ouvrira pas si vous tapez son adresse.
Les cinq postes
| Rôle | À quoi il sert |
|---|---|
| Propriétaire | Contrôle total. Équipe, marque, clés, webhooks, flux, décisions de révision, tout |
| Responsable de revue | Fait tourner la console. Tout ce que peut faire un propriétaire, sauf ajouter des personnes à l'équipe ou changer ce à quoi leurs postes ont accès |
| Développeur | Intègre. Clés API, webhooks, flux, journaux, export de l'utilisation, et données des demandeurs pour le débogage. Pas d'équipe, pas de paramètres de sécurité, pas de décisions de révision |
| Évaluateur | Traite la file de révision. Décide les dossiers, voit et modifie les données des demandeurs, et voit la page Fraude derrière les dossiers. Pas de clés, de webhooks, de flux, d'utilisation ni d'équipe |
| Lecteur | Lecture seule sur toute la console, et jamais l'identité des demandeurs |
Un rôle est un point de départ, pas une cage. Sur la page membre d'un collègue, un propriétaire peut activer ou désactiver des permissions une par une, et le rôle n'est que le préréglage d'où partent ces cases. Changer le rôle de quelqu'un efface toutes ses permissions individuelles, car le nouveau rôle apporte les siennes.
Deux règles encadrent l'ensemble. Personne ne peut accorder une permission qu'il ne détient pas lui-même, et quelques-unes des plus lourdes de conséquences ne peuvent être accordées que par un propriétaire : voir l'identité des demandeurs, la modifier, l'exporter, décider des dossiers, les journaux d'intégration, créer des clés API, composer l'équipe, l'expéditeur sortant, les règles de pays du compte, et l'activité de l'équipe. Un responsable de revue peut pourvoir les postes en dessous du sien sans hériter de la capacité de distribuer des identifiants de production.
Pourquoi certaines permissions vont ensemble
Certaines capacités en impliquent une autre et sont accordées ensemble, car détenir l'une sans l'autre produit un poste incapable de faire son travail.
Décider un dossier inclut la capacité de voir qui est le demandeur. Décider d'un contrôle d'identité sans voir l'identité revient à deviner, les deux forment donc un seul poste. Exporter des vérifications exige de pouvoir les révéler, pour la raison évidente qu'un fichier d'identités de demandeurs ne doit pas être accessible depuis un poste qui n'a pas le droit d'en voir une seule à l'écran.
Modifier les données du demandeur inclut la capacité de voir les données des demandeurs, car changer une valeur suppose de lire celle qu'elle remplace. Les propriétaires, les responsables de revue et les évaluateurs la détiennent par défaut ; les développeurs et les lecteurs non. Elle est distincte de Relire un document, qui demande au moteur de relire les images : un développeur qui reproduit un problème de lecture a besoin de celle-ci, et n'a aucune raison de réécrire l'identité d'un client déjà décidé. La modification est décrite sur Vérifications.
Faire remonter un dossier et résoudre la remontée de quelqu'un d'autre sont volontairement séparés. Une remontée existe pour éloigner une décision de la personne qui l'a soulevée, donc quiconque pourrait en résoudre une du seul fait de pouvoir décider pourrait résoudre la sienne.
Retirer des dossiers est séparé de les décider pour la raison inverse, et c'est la seule permission de révision qui n'inclut pas la capacité de voir l'identité des demandeurs. Retirer n'enregistre aucun résultat sur qui que ce soit, cela n'a donc aucune raison d'exiger le droit de consulter d'abord ses documents. Cette permission revient aux propriétaires et aux responsables de revue plutôt qu'aux évaluateurs : vider un arriéré est une décision sur le fonctionnement de l'activité, pas un travail sur des dossiers.
Trois façons de restreindre un poste
Le rôle est le premier axe. Deux autres se trouvent à côté, sur la page Équipe, et tous deux sont courants dans les comptes réels.
Environnements. Un membre a accès au sandbox, à la production, ou aux deux. C'est la seule chose qui sépare un collègue des données réelles des demandeurs. Voir Environnements.
Flux. Un compte regroupe souvent plusieurs activités sous un même toit. Un poste peut être restreint à des flux précis, ce qui masque chaque vérification, personne et dossier de révision qui n'en font pas partie. Restreignez quelqu'un à rien du tout et il ne voit rien du tout, ce dont la console vous avertit au moment où vous le faites.
Ce qui se passe lorsqu'une page vous est fermée
Vous voyez une courte page indiquant que vos permissions n'incluent pas cette section, et qui peut changer cela : un propriétaire, ou toute personne de votre équipe qui gère les accès, depuis votre page membre.
Dans une page que vous pouvez ouvrir, les contrôles que vous n'avez pas le droit d'utiliser ne sont pas masqués, ils sont désactivés, avec une ligne expliquant que votre rôle peut consulter ces paramètres mais pas les modifier. C'est voulu. Savoir qu'un contrôle existe, c'est savoir quoi demander.
Consulter l'identité d'un demandeur est toujours enregistré
Les noms, dates de naissance, numéros de document et photographies sont chiffrés, et les révéler est une action qui porte votre nom. Chaque consultation apparaît dans Activité de l'équipe, quel que soit votre rôle. Les exports vont plus loin et demandent d'abord un code de votre application d'authentification, car un fichier d'identités sur un ordinateur portable est quelque chose que nous ne pourrons jamais rappeler, faire expirer ni auditer après la première seconde.