Dans Salesforce, aucun champ ne dit qui a le droit de lire
La visibilité d’une fiche Salesforce se compose. Le partage par défaut de l’objet fixe une base, la hiérarchie des rôles ouvre vers le haut, les règles de partage ouvrent vers des groupes et des rôles, les équipes de compte et d’opportunité ajoutent des personnes nommées, et un partage manuel ajoute qui l’on veut. Le résultat est exact dans Salesforce, et il n’est écrit nulle part en un seul endroit lisible.
Un connecteur a deux façons d’affronter cela. Il peut réimplémenter le moteur de partage, ce qui revient à parier sur la reproduction fidèle d’un mécanisme que l’éditeur fait évoluer sans nous prévenir. Il peut aussi ne ranger que les fiches dont il prouve l’audience, et laisser les autres en attente. Le connecteur Kastel prend la seconde voie, et cette page montre où elle mène.
Ce que dit votre Salesforce, et ce que votre Kastel en fait
Chaque ligne se vérifie dans votre propre organisation, dans les paramètres de partage de l’objet et sur la fiche elle-même.
| Ce que dit votre Salesforce | Ce que votre Kastel en fait |
|---|---|
| Le partage par défaut de l’objet est Privé | La condition de base est remplie, le calcul de l’audience continue |
| Le partage par défaut est Lecture publique | Aucune fiche de cet objet n’est rangée. Toutes attendent un administrateur |
| Le partage par défaut est Contrôlé par le parent | La fiche attend, parce que son audience se lit sur le parent |
| Le propriétaire est une personne d’un seul service | La fiche se range dans ce service, et personne d’un autre service ne l’atteint |
| Le propriétaire est une file d’attente | Les membres de la file sont dépliés, et ils doivent tenir dans un seul service |
| Une règle de partage ouvre la fiche à un groupe ou un rôle | Le groupe est déplié en personnes. Un groupe imbriqué fait attendre la fiche |
| Une équipe de compte, d’opportunité ou de requête est renseignée | Ses membres entrent dans le calcul. Un membre d’un autre service fait attendre |
| Le jeton connecté ne peut pas lire la table de partage de l’objet | La fiche attend, parce que son audience n’est pas prouvable |
Une seule règle produit toutes ces lignes. Une fiche se range dans un service unique ou aucune IA ne l’atteint, et aucun échec de calcul n’ouvre une fiche à toute l’entreprise. Un administrateur peut ranger ce qui attend, et sa décision est enregistrée.
Quatre objets standard, aucun objet à vous
Le CRM est la source où l’on est le plus tenté de tout prendre. Voici les cinq objets que le connecteur lit, et ce qu’il laisse à Salesforce.
Les champs de description sont du texte libre, donc leur contenu dépend de ce que vos équipes y écrivent. Une requête client peut y contenir une information personnelle, et c’est une raison de plus pour qu’une fiche ne soit lisible que par un service prouvé.
Un changement de partage ne se voit pas dans le flux des modifications
Le connecteur suit l’horodatage système d’une fiche, celui qui bouge aussi quand Salesforce recalcule ses partages. Une nouvelle ligne de partage, un changement de rôle, une équipe modifiée ou un changement du partage par défaut ne le déplacent pourtant pas de façon fiable, et n’émettent aucun signal fiche par fiche. Un connecteur qui se contenterait du flux des modifications garderait donc éternellement le rangement d’avant.
Une passe de rapprochement périodique existe pour cette raison précise. Elle recalcule l’audience de chaque fiche déjà connue à partir de son propriétaire, de ses partages, de ses équipes et du partage par défaut du moment, puis déplace la fiche quand le résultat a changé. Une audience élargie ou devenue impossible à prouver renvoie la fiche en attente, et une audience déplacée retire la version rangée dans l’ancien service.
Cette passe ne tourne pas à chaque lecture. Pendant l’intervalle, une fiche garde le service où elle était rangée, donc un changement de partage met un moment à se propager jusqu’aux IA branchées. Nous l’écrivons ici parce que c’est le décalage réel du connecteur et que personne ne devrait le découvrir en réunion.
Votre Kastel retient une projection, il ne réplique pas Salesforce
De chaque fiche, le connecteur retient une liste de champs nommés dans son code, rendue en texte lisible. Un compte donne son nom, son secteur, son site, son téléphone et sa description. Une opportunité donne son nom, son étape, son montant, sa date de clôture et sa description. Un contact, une requête et une piste suivent le même principe, avec leurs champs propres.
Ce que le connecteur ne nomme pas n’entre pas, y compris un champ que vous ajouteriez demain. Vos objets et vos champs personnalisés restent donc dehors, et c’est souvent là que vit votre méthode de vente. La limite se sent tout de suite, donc autant la lire ici.
Les activités journalisées restent dehors aussi. Une tâche, un événement, un mail archivé sur une opportunité ou un fil de discussion interne n’entrent pas dans votre Kastel, parce que le connecteur n’interroge que les cinq objets de son périmètre. Un autre CRM fait un autre choix sur ce point précis, et la page HubSpot le dit franchement.
Ce que ce connecteur ne fait pas
Il ne réimplémente pas le partage de Salesforce, et cela se paie au premier branchement. Une organisation dont un objet est en lecture publique, ce qui est un réglage courant et parfaitement légitime, verra toutes les fiches de cet objet rester en attente. Un administrateur peut les ranger, et rien ne se déverrouille tout seul.
Il range par service, là où Salesforce raisonne par personne. Une fiche prouvée confinée à son propriétaire devient lisible par le service entier de cette personne, donc plus largement que dans Salesforce, où la hiérarchie des rôles décide au cas par cas. Le grain du connecteur est le service, et une direction commerciale très découpée doit le savoir avant de brancher un portefeuille sensible.
Il ne lit aucune activité, et c’est la différence la plus visible avec les autres CRM du catalogue. Une négociation entière peut vivre dans les tâches et les mails journalisés d’une opportunité, et rien de tout cela n’entre. Ce périmètre pourrait s’étendre, cela n’a pas été fait.
Une fiche supprimée dans Salesforce n’est pas effacée de votre Kastel. Elle y est signalée comme disparue à la source et retenue, avec le même lectorat qu’avant, jusqu’à l’effacement décidé par un administrateur. Le branchement, lui, se fait organisation par organisation, avec sa propre autorisation et son propre domaine, et un groupe qui exploite trois organisations branche trois connexions qui ne se voient pas entre elles.
Le cœur de Kastel est gratuit, connecteur Salesforce compris.
Le cœur s’installe chez vous sans rien payer, avec tous ses connecteurs. La page des tarifs dit ce que les plans payants ajoutent, et à partir de quelle taille d’équipe ils commencent.
Voir les tarifs
