L’export annonce cinq clients, mais le fichier n’en contient que deux

Votre export Salesforce annonce cinq clients traités, mais le fichier n’en contient que deux. Les appels ont répondu sans erreur et le commercial croit disposer de toute sa sélection. La BI risque ensuite de consolider cette sortie partielle comme population définitive. Avant de chercher les fiches manquantes dans l’ERP, comparez le compteur affiché aux objets effectivement reçus : le connecteur peut avoir repris le total de la requête tout en abandonnant sa continuation.

En pratique, un nombre annoncé par la source ne prouve ni une lecture complète ni un fichier utilisable. Pour une requête REST SOQL ordinaire, le diagnostic distingue le total annoncé, les enregistrements de la réponse, la fin du parcours et les confirmations de sortie. Le défaut devient visible lorsque ces quatre lectures cessent de raconter la même progression.

Vous allez suivre cinq identités fictives sur trois réponses locales, puis comparer huit situations. La simulation montre une première page seule, une dernière réponse absente, une identité répétée et une sortie non confirmée. Elle n’interroge aucune organisation Salesforce et n’écrit aucun fichier client : les confirmations sont des ensembles en mémoire, dont les limites seront précisées avant toute proposition de reprise.

Notre accompagnement en intégration API entre vos logiciels cadre les échanges et leurs preuves de résultat. Une intégration Salesforce avec votre système d’information peut qualifier ce parcours de lecture avec vos équipes CRM et BI, puis vérifier ce que le connecteur transmet réellement aux applications destinataires.

Pour qui : le fichier CRM manque de lignes malgré un compteur terminé

Choisir un export dont le périmètre peut être expliqué

Ce diagnostic concerne un connecteur qui lit des objets Salesforce par l’API REST et produit un fichier, une table de travail ou une alimentation BI. Il devient utile lorsque le résultat paraît complet dans le suivi, alors que les équipes retrouvent des comptes absents. Prenez une exécution précise, son organisation, son utilisateur technique et sa requête réellement envoyée.

Le mot « client » décrit ici l’usage métier des identités fictives. Votre extraction peut porter sur Account, Contact ou un objet personnalisé, avec un filtre propre à l’organisation. La complétude se juge par rapport à cette sélection déclarée. Un compte exclu par le filtre ou inaccessible à l’utilisateur technique ne devient pas un résultat manquant de la pagination.

Distinguer ce parcours des autres exports Salesforce

Un téléchargement depuis un rapport, un job Bulk ou une lecture GraphQL possède un contrat différent. La présence du nom Salesforce dans un ticket ne suffit donc pas à appliquer la même correction. Identifiez l’interface, le type de requête et le composant qui transforme sa réponse avant de discuter des limites de volume ou de la taille des lots.

Nous retenons une requête ordinaire renvoyant des enregistrements identifiés, sans agrégation. Un résultat compté ou regroupé ne se compare pas mécaniquement à une liste d’identifiants clients. Si le ticket concerne plutôt le choix du transport, la lecture Salesforce sous charge, Bulk, CDC et Pub/Sub aide à replacer l’extraction dans son architecture.

Anatomie du défaut : le total annoncé remplace la liste reçue

Lire ensemble le total, les objets et la continuation

La référence officielle Salesforce Query décrit quatre éléments : totalSize, records, done et nextRecordsUrl. Le premier annonce le total de la requête ; records porte les objets de la réponse ; done indique si d’autres résultats restent à obtenir ; nextRecordsUrl fournit la continuation quand elle existe. Ils répondent à des questions différentes.

Notre première réponse fictive annonce cinq objets et en porte seulement deux. Son indicateur de fin reste faux, avec une continuation. Le compteur défectueux affiche directement cinq « exportés », puis clôture la tâche après cette réponse. Aucun mauvais calcul arithmétique n’est nécessaire : une valeur correcte a simplement reçu une signification que sa source ne garantit pas.

Retrouver le passage qui transforme une annonce en preuve

Suivez la valeur jusque dans l’écran ou le journal de traitement. Un champ initialement nommé « nombre annoncé » peut devenir « lignes écrites » après une normalisation. La transformation est parfois cachée dans le payload normalisé commun à plusieurs connecteurs, dont les champs ont perdu le sens de la réponse source. Demandez une trace du nombre et de son origine, plutôt qu’une capture où toutes les colonnes portent seulement le mot « total ».

Un premier signal faible apparaît quand le nombre affiché reste exactement identique à chaque réponse, tandis que le fichier continue de grandir. Un second apparaît lorsque le traitement se déclare terminé sans trace d’une fin de parcours. Ces symptômes orientent le contrôle ; ils ne prouvent pas la cause tant que la réponse reçue et la décision du consommateur n’ont pas été rapprochées.

Poursuivre la lecture sans déduire sa fin de la taille d’une page

Suivre la continuation réellement fournie par la source

La référence Query More Results explique comment obtenir les réponses suivantes avec le locator retourné, jusqu’à l’indication de fin. Le connecteur ne remplace pas cette suite par une nouvelle requête métier supposée équivalente. Une reprise doit conserver le lien avec l’exécution et le périmètre auxquels appartient la continuation.

La documentation Query indique aussi qu’une réponse synchrone peut contenir jusqu’à deux mille enregistrements, et parfois moins selon la taille et la complexité des données. Une page moins remplie que votre attente ne suffit donc pas à déclarer le parcours terminé. Le nombre maximal est une limite de réponse, pas une preuve que tous les résultats tiennent dans l’appel effectué.

Garder la miniature pédagogique séparée du réglage réel

Les trois réponses de notre exercice portent deux, deux et une identités afin de rendre leur progression lisible. Cette miniature ne simule pas une option Salesforce demandant des lots natifs de deux enregistrements. Elle fournit des enveloppes locales préparées à l’avance et teste seulement les décisions prises depuis leurs champs. Aucun locator n’est consommé sur un serveur.

Dans votre intégration, examinez la documentation de la version utilisée et la réponse effectivement obtenue. Ne déduisez pas une durée de validité, une taille imposée ou une garantie de photographie immuable depuis le seul exemple. Les capacités d’un curseur et les conséquences d’une interruption doivent être vérifiées avant de promettre une reprise automatique sur une extraction réelle.

Séparer les objets reçus des lignes dont la sortie est confirmée

Nommer les quatre nombres suivis par l’exploitation

Le suivi proposé conserve le nombre annoncé, les occurrences reçues, les identités distinctes reçues et les identités dont la sortie est confirmée. Une occurrence répétée augmente le deuxième nombre sans augmenter le troisième. Une erreur d’écriture peut laisser le troisième supérieur au quatrième. Ces différences rendent visible l’étape encore à examiner, même si tous les appels réseau ont réussi.

Le compte rendu affiche également si le parcours source est terminé. Un nombre reçu égal au total annoncé ne remplace pas cet indicateur dans notre politique locale. À l’inverse, une fin annoncée avec moins d’identités distinctes que prévu ouvre une revue. Le rapprochement suppose que les nombres portent sur le même objet, le même filtre et la même exécution ; sinon leur comparaison manque de sens.

Décider ce qui constitue une confirmation pour la sortie choisie

Un fichier doit être finalisé et contrôlé selon son procédé d’écriture. Une table doit conserver les enregistrements selon sa transaction et ses contraintes. Une transmission vers une autre application demande encore une preuve appropriée à son interface. Recevoir la dernière réponse Salesforce ne démontre aucun de ces effets ; le contrat de sortie doit nommer celui qui autorise le libellé « export terminé ».

Notre simulation représente cette preuve par une liste d’identités confirmées, sans écrire le moindre fichier. Elle distingue les compteurs, mais ne teste ni stockage durable, ni coupure pendant une écriture, ni reprise après redémarrage. Cette limite évite de présenter une décision correcte en mémoire comme une garantie de livraison réelle des données à votre outil de reporting.

Exercice corrigé : huit situations autour de cinq identités fictives

Comparer la progression attendue aux sorties du contrôle local

Les identités A à E sont artificielles et ne désignent aucun client. Le cas complet les reçoit sur trois réponses, puis les retrouve dans les confirmations simulées. Les variantes interrompent ce parcours, retirent une confirmation ou répètent une identité. Les attentes sont fixées avant exécution et les entrées restent inchangées après chaque contrôle.

Les huit décisions correspondent aux attentes. Deux compteurs erronés sont calculés séparément : le premier annonce cinq exportés après deux objets reçus ; le second additionne cinq sur chacune des trois réponses et affiche quinze pour cinq occurrences réellement obtenues. Remplacer la première erreur par une accumulation du même champ crée donc une autre présentation fausse du résultat.

Conserver les refus et les limites de la recette

Douze entrées sont refusées : total booléen, négatif ou textuel, indicateur de fin textuel, liste d’objets absente, continuation requise absente, identité manquante, total changeant, continuation répétée, confirmation étrangère, réponse inexistante et page ajoutée après la fin. La stabilité du total est une politique prudente du contrôle local ; une divergence observée exige une enquête, pas une accusation automatique contre Salesforce.

Le cas H est volontairement contradictoire pour éprouver le refus d’une clôture fondée sur l’égalité numérique. Le cas G ne démontre pas que l’entreprise ne possède aucun client : il décrit seulement la sélection vide fournie à notre fonction. Aucun scénario ne prouve l’exhaustivité des droits, la concurrence, la persistance d’un checkpoint ou le contenu d’un fichier physique.

Reprendre l’extraction en conservant le périmètre et les effets connus

Retrouver ce qui a été reçu avant de relancer une lecture

Le dossier d’incident relie organisation, identité technique, version d’API, objet, requête, réponses, compteur et sortie connue. Il garde les identifiants nécessaires au rapprochement dans un stockage autorisé, avec des journaux de diagnostic réduits. Une continuation peut être sensible selon son contexte ; elle ne doit pas être copiée dans un outil public pour rendre un ticket plus commode.

La reprise après un timeout de lecture dépend de la possibilité réelle de continuer ce parcours. Si cette possibilité est inconnue ou indisponible, préparez une nouvelle extraction identifiable, puis rapprochez-la de ses sorties. Ne mélangez pas ses nombres avec ceux de l’exécution précédente. Réinterroger une source peut produire une nouvelle sélection ; la continuité ne se suppose pas depuis deux totaux identiques.

Traiter une sortie partielle sans la présenter comme terminée

Le cas D demande de retrouver pourquoi la dernière identité n’a pas de confirmation. Elle peut avoir été rejetée par le mapping, retenue pour revue ou perdue pendant une écriture ; le modèle en mémoire ne choisit aucune cause. La recette réelle doit couper le parcours à cette frontière et vérifier comment le résultat reste identifiable après redémarrage.

Contre-intuitivement, faire simplement disparaître le badge vert peut protéger davantage le métier qu’une relance immédiate. Une sortie marquée incomplète évite que la BI consolide un fichier partiel comme population définitive. Le responsable du reporting décide alors s’il peut travailler avec ce résultat provisoire, attendre sa finalisation ou utiliser une autre extraction dont les limites sont documentées.

Mesurer les conséquences d’un fichier partiel sans inventer des clients perdus

Rattacher la différence au bon usage métier

Un export incomplet peut alimenter un rapport, une comparaison ERP ou une préparation commerciale. Sa conséquence dépend des décisions prises depuis ce fichier. Recherchez les traitements aval et leurs dates, plutôt que conclure que tous les comptes non présents ont été oubliés par les ventes. Une absence dans le fichier n’établit ni la perte d’une opportunité ni une disparition de la fiche Salesforce.

Une projection complète peut aussi différer volontairement certains objets selon sa règle métier. Le suivi doit alors distinguer objets reçus, objets retenus et objets rejetés avec motif. La bonne unité de comparaison n’est plus forcément une ligne par identité. Le responsable BI définit le résultat attendu avant que l’intégrateur transforme cette convention en critère de recette.

Chiffrer le travail de rapprochement observé

Dans une estimation fictive, douze exécutions demandent chacune dix-sept minutes pour comparer le fichier, les traces et les fiches. La charge représente deux cent quatre minutes, soit trois heures et vingt-quatre minutes. Ce calcul mesure une hypothèse de contrôle, sans annoncer une économie client ni déduire un gain commercial depuis la seule réparation du compteur.

Le coût complet distingue cette recherche, la reconstruction du fichier et la reprise des rapports déjà utilisés. Le pilote mesure leurs durées sur des dossiers autorisés. Un compteur fiable peut réduire les investigations inutiles, mais son effet doit être observé : nommer correctement une tâche incomplète ne répare pas automatiquement tous les usages qui ont déjà consommé son ancienne sortie.

Erreurs fréquentes : réparer le compteur tout en abandonnant les objets

La première correction visible peut déplacer l’erreur vers une autre étape. Les choix suivants doivent être examinés avec la personne qui possède le résultat métier, car ils ne produisent pas les mêmes effets sur la lecture, la transformation et la sortie. Une valeur plus plausible dans l’écran n’est pas encore une extraction complète.

• Additionner le total à chaque réponse : compter plusieurs fois la population annoncée au lieu de mesurer les objets reçus. Les trois pages fictives donnent alors quinze, sans aucune identité supplémentaire.
• Arrêter après une page moins remplie : remplacer l’indicateur de fin par une supposition sur la taille. Une réponse courte demande encore l’examen de son contrat de continuation.
• Dédupliquer uniquement pour obtenir le bon nombre : retirer une occurrence sans expliquer son recouvrement. Le cas E conserve quatre identités et exige une revue du parcours.
• Clôturer dès la dernière réponse : ignorer les rejets ou confirmations manquantes de la sortie. Le cas D sépare fin de lecture et disponibilité du résultat attendu.
• Attribuer le défaut aux permissions sans preuve : confondre le périmètre accessible et l’abandon d’une suite effectivement fournie. Les droits et la continuation demandent des contrôles distincts.

Le seuil de repli proposé est une tâche qui annonce la complétude sans retrouver ses réponses et sa preuve de sortie. Elle passe en revue avec son résultat connu, tandis que les usages automatiques concernés sont identifiés. L’arrêt doit rester borné à cette extraction ; une anomalie de comptage ne justifie pas de suspendre tous les échanges du CRM.

Plan d’action : recetter une extraction avant de corriger les rapports

Fixer le contrat avec CRM, intégration et BI

L’administrateur CRM qualifie l’organisation, l’objet, les filtres et l’accès. L’intégrateur retrouve la requête et les réponses, puis examine la décision de continuation. La BI définit le fichier ou la population qu’elle attend. L’exploitation vérifie les traces et les interruptions. Chaque responsabilité porte ainsi une preuve différente, au lieu de discuter d’un seul total affiché.

La mise en œuvre conserve une identité d’exécution, la version du mapping, les dépendances de sortie et un statut incomplet explicite. L’observabilité compare les étapes, tandis que la journalisation retrouve les motifs d’arrêt. Le contrat prévoit un rollback du traitement et une sortie provisoire reconnaissable, sans supprimer les traces nécessaires pour comprendre pourquoi le premier rapport manquait de données.

Choisir les conditions de passage et les essais à différer

Corriger d’abord la signification du compteur et la boucle qui suit la continuation. Différer le changement d’interface ou de taille de lot tant que le défaut exact n’est pas reproduit. Refuser une clôture qui repose seulement sur le total annoncé. Ces arbitrages donnent une recette précise au développeur et un résultat compréhensible au responsable du reporting.

La CI peut rejouer les enveloppes locales ; la QA doit encore éprouver la lecture et la sortie dans un environnement autorisé. Un runbook décrit l’arrêt, le rapprochement et la reprise. Le seuil de passage retenu exige une fin de parcours expliquée et toutes les sorties attendues confirmées. L’élargissement attend aussi les essais d’interruption avant la dernière réponse et avant confirmation finale, avec des critères validés pour le stockage et les consommateurs réellement utilisés.

Guides complémentaires : architecture, charge et identité des comptes

Le compteur d’extraction est une partie du contrat CRM, tandis que le transport, l’autorité des données et leurs usages aval méritent d’autres contrôles. Les quatre lectures suivantes prolongent ces décisions. Elles ne changent pas la portée de notre simulation locale et ne prouvent pas qu’une organisation particulière présente le défaut étudié.

Qualifier l’architecture Salesforce et ses dépendances

La présentation de l’intégration Salesforce, middleware et reprise replace objets, accès et échanges dans le système d’information. Elle aide à identifier le composant qui décide de la sortie, avant de demander une correction limitée à son écran de suivi.

Gardez ensuite l’extraction choisie comme périmètre de recette, avec ses propres réponses et son consommateur. Le cadrage général ne remplace pas la comparaison des occurrences effectivement obtenues sur cette exécution.

Choisir un transport adapté au volume réel

La lecture Salesforce sous charge, Bulk, CDC et Pub/Sub distingue chargement, changements courants et réconciliation. Cette décision peut devenir pertinente après le diagnostic, lorsque le volume et les capacités aval imposent un autre mode de traitement.

Changer de transport ne dispense pas de mesurer ce qui a été reçu et appliqué. La nouvelle interface doit fournir sa propre preuve de fin et ses propres résultats, sans conserver le compteur erroné de l’ancien parcours.

Préserver le sens des informations transmises vers l’ERP

La lecture Salesforce, contrats, commandes et factures sépare les faits commerciaux des effets opérationnels et financiers. Elle prolonge la même prudence : un signal source doit garder sa signification lorsqu’une application destinataire le transforme en état métier.

Une liste complète de comptes ne démontre donc pas qu’une commande a été acceptée ou qu’une facture existe. L’export remet des objets à un consommateur ; les effets qu’il déclenche doivent rester qualifiés par leur propre contrat.

Expliquer les identités fusionnées avant de comparer des populations

Le cas de la fusion Pipedrive et du compte ERP à conserver traite un autre CRM et une autre cause d’écart. Il montre pourquoi compter des fiches ne suffit pas quand des identités source et des références aval ont changé.

Cette lecture aide à distinguer une population rapprochée d’un simple nombre de lignes. Ses interfaces Pipedrive ne décrivent aucun comportement Salesforce ; le contrat d’identité propre à votre extraction reste à vérifier séparément.

Conclusion : prouver la lecture puis la sortie avant d’annoncer l’export

La première réponse peut annoncer toute une sélection sans la contenir. Le diagnostic retrouve le nombre annoncé, les occurrences reçues, la continuation et les confirmations de sortie. Cette séparation explique un fichier incomplet sans transformer immédiatement ses absences en suppression de fiches ou en clients perdus.

Les huit situations fictives distinguent interruption, identité répétée, fin contradictoire et sortie non confirmée. Elles prouvent les décisions du contrôle en mémoire, avec douze refus, sans appel Salesforce ni export physique. La reprise réelle doit encore éprouver les droits, le stockage, les interruptions et les interfaces effectivement accessibles.

Commencez par une extraction retrouvable et son utilisateur métier. Notre accompagnement en intégration Salesforce peut qualifier le contrat de lecture et la preuve attendue par votre outil BI, avant d’étendre la correction à tous les flux CRM.

Dawap vous accompagne pour cadrer les preuves de lecture et de sortie avec vos équipes CRM, BI et exploitation. Nos prestations d’intégration API sur mesure permettent de recetter le parcours, préparer sa reprise et suivre ses écarts, avec un résultat dont l’exploitation peut expliquer la portée.