Chaque enregistrement de Pipedrive porte son propre réglage de visibilité
Pipedrive laisse régler la visibilité affaire par affaire. Une équipe qui vend depuis quelques années se retrouve donc avec des affaires réservées à leur propriétaire, d’autres ouvertes à toute l’entreprise, et quelques-unes rattachées à un groupe de visibilité créé pour une raison que plus personne ne se rappelle.
Ce désordre reste supportable tant que Pipedrive circule entre humains, parce qu’un collègue trop curieux se remarque. Il change de nature le jour où une IA lit le pipeline, puisqu’une IA lit tout ce qu’on lui donne, vite et sans que personne s’en aperçoive.
Le connecteur Pipedrive part donc du réglage que vous avez déjà, au lieu de vous demander de le refaire ailleurs.
La visibilité est lue avant le propriétaire
Le connecteur regarde deux choses sur chaque enregistrement, dans cet ordre. D’abord le réglage de visibilité, ensuite le propriétaire. L’ordre compte, parce que le propriétaire ne sert à ranger l’enregistrement que si la visibilité prouve qu’il est le seul concerné.
Quand Pipedrive déclare une affaire réservée à son propriétaire et à ses abonnés, le connecteur résout ce propriétaire en une personne de votre organisation, puis range l’affaire dans le service de cette personne. Une IA branchée pour quelqu’un de ce service atteint l’affaire, et une IA branchée pour un autre service ne l’atteint pas.
Dans tous les autres cas, l’affaire attend la décision d’un administrateur. Une affaire ouverte à toute l’entreprise est donc moins lisible par une IA qu’une affaire réservée à son propriétaire, ce qui surprend au premier abord. La raison tient au sens des réglages de Pipedrive, qui dépend de votre offre et de l’activation des groupes de visibilité. Le connecteur n’agit que sur le réglage dont il peut prouver le sens, et il refuse de deviner les autres.
Ranger une affaire visible par un groupe dans le service de son propriétaire donnerait accès à des collègues de ce service qui ne sont pas dans le groupe. C’est le genre d’écart que personne ne remarque avant qu’une IA le mette en évidence. Sur HubSpot, le connecteur se cale sur le seul propriétaire de la fiche, faute d’un réglage de ce genre à reprendre, et la page HubSpot le détaille.
Ce que le connecteur conclut, enregistrement par enregistrement
Chaque ligne se vérifie dans votre Pipedrive, en ouvrant l’enregistrement concerné et en regardant son réglage de visibilité.
| Ce que Pipedrive dit de l’enregistrement | Ce qui décide de son lectorat |
|---|---|
| Une affaire réservée à son propriétaire et à ses abonnés | Le service du propriétaire, résolu par son adresse professionnelle |
| Une affaire ouverte à toute l’entreprise | Aucun service, parce que son lectorat réel dépasse celui du propriétaire |
| Une affaire rattachée à un groupe de visibilité | Aucun service, parce que ce groupe peut traverser plusieurs services |
| Une note ou une activité | Aucun service, parce que Pipedrive ne leur donne pas de réglage de visibilité |
| Un enregistrement sans propriétaire, ou dont le propriétaire n’a plus d’adresse | Aucun service, parce que l’origine ne désigne plus personne |
Un administrateur peut trancher enregistrement par enregistrement. Il peut aussi resserrer la visibilité dans Pipedrive, et le passage suivant rangera les affaires concernées sans autre intervention.
Les notes et les activités n’ont aucun réglage de visibilité
Pipedrive donne un réglage de visibilité aux affaires, aux personnes et aux organisations. Il n’en donne pas aux notes ni aux activités, qui ne portent aucun champ de visibilité qu’un connecteur puisse lire.
Leur contenu est pourtant lu. Une note entre avec son texte, une activité entre avec son objet, son type, sa date d’échéance, son lieu et son commentaire. C’est la matière la plus riche d’un CRM, et souvent la plus indiscrète, puisque c’est là qu’un commercial écrit ce qu’il pense vraiment d’un interlocuteur.
Faute de réglage à reprendre, toutes ces entrées attendent la décision d’un administrateur. Elles sont lues, elles ne sont rangées dans aucun service, et aucune IA branchée ne les atteint avant qu’une personne ait tranché. C’est le refus le plus large de ce connecteur, et le seul défendable sur un contenu dont Pipedrive lui-même ne dit pas qui a le droit de le voir. La page sur la gouvernance du contexte décrit comment cette décision se prend et se garde en mémoire.
Les quatre objets lus, et les champs que vous avez ajoutés
Le connecteur nomme les champs qu’il écrit, type d’objet par type d’objet. Voici cette liste, et ce qu’elle laisse de côté.
Quand une personne porte plusieurs adresses mail ou plusieurs numéros dans Pipedrive, seule l’entrée marquée principale est écrite. Les autres restent dans Pipedrive.
Un changement de visibilité ne se signale pas de lui-même
Pipedrive marque chaque enregistrement de sa date de dernière modification, et le connecteur s’en sert pour ne relire que ce qui a bougé. Une reprise de portefeuille passe par là. Quand une affaire change de propriétaire, sa date bouge, elle ressort au passage suivant et elle se range dans le service du nouveau propriétaire, si sa visibilité l’autorise toujours.
Un changement de visibilité, lui, ne fait pas forcément bouger cette date, et une modification d’appartenance à un groupe encore moins. Un passage de rapprochement re-résout donc le lectorat de chaque enregistrement suivi, sans regarder si son contenu a changé. Entre deux rapprochements, un enregistrement peut rester rangé comme il l’était. Quand ce re-rangement échoue, l’enregistrement reste suivi à son rangement précédent, jamais à un rangement plus large, et il est repris au rapprochement suivant.
Ce rapprochement périodique existe parce que Pipedrive superpose deux signaux, le propriétaire et la visibilité, qui ne bougent pas ensemble. Le connecteur Zoho CRM ne lit pas de seconde couche de ce genre, et il se passe donc d’un passage de rattrapage.
La même prudence gouverne la lecture des listes. Quand une page de résultats annonce une suite sans donner le moyen de l’atteindre, le passage échoue bruyamment et le type d’objet concerné sort de la comparaison, au lieu de conclure que les enregistrements non lus ont disparu.
La clé de lecture est un jeton créé au niveau de votre société Pipedrive, et elle voyage dans un en-tête de requête. L’authentification classique de Pipedrive place ce jeton dans l’adresse appelée, ce que le connecteur refuse, parce qu’une adresse finit dans des journaux et dans des serveurs intermédiaires.
Ce que ce connecteur ne fait pas
L’étape d’une affaire arrive comme un identifiant, jamais comme le libellé que vous lisez dans Pipedrive. Une IA branchée saura donc distinguer deux affaires qui n’en sont pas au même point, sans pouvoir nommer l’étape où elles se trouvent.
Les champs que votre équipe a créés dans Pipedrive restent dehors. Le connecteur écrit une liste de champs arrêtée dans son code, et la note de qualification que vous avez ajoutée l’an dernier n’y figure pas. Les intégrer est possible, ce n’est pas fait, et nous préférons l’écrire ici.
Le rattrapage d’un changement de visibilité se fait au passage de rapprochement, pas à la seconde où vous modifiez le réglage. Un enregistrement peut donc rester rangé comme il l’était pendant ce délai. La dérive va toujours dans le même sens, celui du rangement précédent, jamais vers un lectorat plus large.
Une affaire supprimée ou archivée dans Pipedrive n’est pas effacée de votre Kastel. Elle porte désormais la mention d’une disparition à la source, elle reste consultable par les mêmes personnes, et seul un effacement décidé par un administrateur la retire.
Comparez les plans avant de brancher votre pipeline.
La grille dit ce que le cœur gratuit contient déjà, tous les connecteurs compris, et ce que chaque plan payant ajoute autour, notamment pour une organisation qui doit prouver qui a accès à quoi et qui a validé.
Voir les tarifs
