Paminga Tips
Paminga Tip #06 - Droits et Permissions dans Paminga
4 vues
View transcript
Bonjour à tous, on se retrouve aujourd'hui pour un nouveau Paminga Tip sur les permissions. Quiconque a travaillé dans une solution de marketing automation sait que pour travailler efficacement en équipe, vous devez pouvoir définir précisément les droits de chacun, en interne comme en externe. L'agence aura par exemple le droit de créer des assets dans la solution, mais pas d'activer les campagnes ou de voir la database. Le junior pourra créer les campagnes, mais pas les activer, et ainsi de suite. On va voir aujourd'hui comment Paminga résout cette solution de manière très fine et élégante. Je suis dans la partie Account Settings de mon Paminga, et je vais pouvoir trouver les permissions ici et les users ici. Et sur cet écran, je vais pouvoir créer autant de rôles que je souhaite, et créer des équipes afin d'y mettre mes users. Donc en fait, je vais avoir les users qui font partie ou pas d'équipes, les équipes qui sont associées à des rôles, et les rôles qui vont pouvoir définir précisément les droits de ce que je peux faire dans l'application. J'ai commencé à créer un rôle junior ici, en imaginant que je souhaitais pouvoir donner ce rôle à quelqu'un qui n'aurait pas le droit par exemple d'exécuter des campagnes ou de modifier quoi que ce soit d'important dans l'application. Donc ici, je vais avoir mon rôle découpé en cinq grandes familles. Les droits administratifs, les assets, les automations, les workflows, le data management et le finder. Donc évidemment, sur la partie assets, mon junior ne va pas pouvoir changer grand-chose. J'ai même les droits ici de décider que cette personne ne va pas modifier les champs de quiconque dans la base. Donc quand je dis les champs, c'est les valeurs des champs. C'est-à-dire que, vous l'avez vu, Paminga a une petite partie CRM où je peux gérer mes comptes et mes personnes, et même créer des contacts directement dans Paminga, modifier les champs, que ce soit à la main ou à travers les workflows ou à travers les API. Ici, ce droit va être retiré pour ce rôle. Donc j'ai tous les droits correspondant à toute la partie gauche de mon menu, là évidemment. Je vais pouvoir fermer ça. Sur les assets, je vais pouvoir définir qui gère les kits de marques, qui crée mes ajours, supprime ou publie ou applique les kits de marques sur les call to action, les emails, les formulaires, les landing pages. Sur la partie export, là, c'est l'export des soumissions. Sur la partie workflow, évidemment, mon junior, il ne va pas pouvoir créer les action sets, il va pouvoir créer les workflows, mais il ne va pas pouvoir gérer l'exécution. Donc là, il faudra qu'il demande à quelqu'un qui a ce droit de le faire pour lui. Et sur la partie data management, idem, il va pouvoir créer des choses, mais il ne va pas pouvoir supprimer des assets, des custom objects, des comptes, des contacts, et ainsi de suite. Sur la partie finder, on a toute la partie des permissions qui permettent de partager les workspaces ou les folders et la partie suppression qui ne sera pas accordée. Donc je peux vraiment affiner très précisément le droit que je souhaite faire pour ce junior. Idem, si j'avais une agence externe qui travaille sur mes assets, je pourrais donner le droit sur les assets, mais retirer tous les droits sur la partie automation, data management et finder pour qu'ils gèrent uniquement les assets et qu'ils n'aient pas vision sur quoi que ce soit d'autre dans l'application. On peut créer à l'infini des rôles comme ça, c'est pas mal. On peut créer aussi des équipes, et ensuite je vais pouvoir dire quels sont les membres de mon équipe ici et les rôles associés à l'équipe. Et je peux mettre plusieurs rôles et ce sera cumulatif bien sûr. Je peux aussi décider que ce rôle est directement attribué à une personne sans passer par une équipe. Donc je ne suis pas obligé d'utiliser les équipes, mais c'est quand même bien pratique. Donc si je me suis logué avec une personne ici, avec mon profil, avec mon adresse perso, dans la partie sur Firefox, ici avec un login différent, donc on voit bien que je n'ai pas le droit de modifier, si je rafraîchis, je n'ai pas le droit de modifier l'affiche de la personne. Si je vais sur le compte, idem, je ne peux pas modifier quoi que ce soit. Ici, je vais pouvoir voir les formulaires par exemple, mais je n'ai pas le droit de les supprimer, comme on l'a bien dit. Et si je vais sur un asset, qu 'est-ce que je vais pouvoir faire ? Après, il y a plein de droits qui ont été retirés. Je vais par exemple, je n'ai pas fini là, je peux appliquer le kit de marque, mais je ne vais pas pouvoir typiquement créer, je ne peux pas créer le brand kit. Donc c'est bien le profil que je souhaitais pour mon junior. Il peut travailler, mais il ne peut pas tout casser dans l'application tant qu'il n'est pas confortable avec mon application. Donc vraiment, une gestion des permissions qui permet de travailler, qu'on soit une PME ou un grand compte, en définissant précisément les différents niveaux pour le groupe, les régions, les utilisateurs dans les pays, l'équipe globale, l'équipe locale, les agences externes, les juniors, les champions et ainsi de suite. A très vite pour un prochain Paminga Tip.