Google sheets keeps on saying coloums has been been changes i have refreshed deleted the node added a new one same isssue

Questions
1

Column names were updated after the node’s setup
Refresh the columns list in the ‘Column to Match On’ parameter. Updated columns: email → user_id, phone → email, channel → phone, last_message → channel, intent → last_message, is_lead_related → intent, status → is_lead_related, last_updated → status i got this error i have refreshed columns and it still hass the issue what do i do

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Hi @SAM_M

Please can you share a screenshot of your google sheets node properties. This error generally means that you or someone changed the google sheets columns header in your sheet after you had setup your node. This could be either name changes or changing the order of the columns.

3

did you manage to fix it? I’m having the same issue. even after deleting the node, adding a new one, and remapping everything

4

The node caches column mappings internally, so deleting and re-adding doesn’t always fix it. Open the Google Sheets node, click into the “Column to Match On” dropdown, and use the small refresh icon right next to it. That forces n8n to re-read the actual sheet headers. If it still persists, check if any column header in the sheet has a trailing space or was renamed since you first configured the node.

5

Je vérifie quand ce problème sera corrigé. Sheets Node v3 n’a pas ce problème. Nous avons besoin que les colonnes puissent être référencées dynamiquement. Cela casse plusieurs de mes flux qui doivent pouvoir placer les mêmes données dans plusieurs feuilles avec des ordres de colonnes différents mais les mêmes noms de colonnes. S’il vous plaît, permettez à la prochaine version de Google Sheets Node de ne pas mettre en cache les colonnes.

6

TylerH, la repro utile est les mêmes noms de colonnes dans un ordre différent sur deux feuilles, pas l’ancien cas « renommer un en-tête puis actualiser ».

Peux-tu publier l’exemple minimal avec les en-têtes de la Feuille A, les en-têtes de la Feuille B, l’opération Google Sheets/la version du nœud exacte, et si le même workflow fonctionne en v3 ? Cela donne à l’équipe n8n un test propre de mappage en cache par rapport au mappage dynamique au lieu d’une autre boucle d’actualisation des colonnes.

7

Une chose qui corrige généralement le cache de colonnes bloqué : dans le nœud Google Sheets, basculez « Mode de mappage des colonnes » de « Mapper automatiquement » à « Mapper chaque colonne manuellement », enregistrez, puis revenez à « Mapper automatiquement » - cela force n8n à abandonner le schéma en cache et à le recharger directement depuis la feuille. Si cela ne fonctionne toujours pas, exportez le JSON du workflow, trouvez les paramètres du nœud Google Sheets, et supprimez manuellement les clés schema et schemaType du JSON, puis réimportez. Cela efface complètement le cache de colonnes intégré, peu importe ce que fait l’actualisation de l’interface utilisateur.

8

Nous avons rencontré la même erreur lors du packaging des workflows n8n, et dans notre cas, le déclencheur n’était pas un changement du côté de la feuille de calcul. Deux mesures au cas où elles aideraient à réduire le champ.

1. Re-sélectionner le Document ou la Feuille dans le nœud réinitialise silencieusement la configuration des colonnes.

Reproduites deux fois sur n8n autohébergé 2.31.5. Dès que nous avons repris le Document/la Feuille dans les listes déroulantes, le nœud a perdu :

  • mappingMode (autoMapInputData a basculé vers un mappage manuel vide)
  • matchingColumns
  • options.cellFormat (RAW a basculé vers la valeur par défaut)

Aucune erreur, aucun avertissement — le nœud semble toujours configuré. Nous avons vu le même chemin effacer les matchingColumns sauvegardées et les valeurs d’un mappage defineBelow également. Donc « les noms de colonnes ont été mis à jour après la configuration du nœud » peut se déclencher même si personne n’a touché aux en-têtes de la feuille : ouvrir le nœud et reprendre la feuille suffit pour le déclencher.

2. Ce qui a fonctionné pour nous, c’était d’éviter complètement la liste déroulante.

Au lieu de sélectionner dans la liste, nous avons défini documentId sur Par URL (rempli à partir d’une expression, avec l’URL de la feuille conservée dans un nœud de paramètres) et sheetName sur Par Nom avec une chaîne fixe. Sans sélection de liste déroulante nulle part dans le flux, il n’y a pas d’événement de re-sélection pour réinitialiser le mappage. C’est une prévention plutôt qu’une réparation, elle complète donc le correctif de Jay qui supprime schema / schemaType du JSON exporté, ce que nous utiliserions pour récupérer un nœud déjà cassé.

3. Il vaut la peine de vérifier cellFormat après toute réinitialisation de ce type.

Quand il bascule silencieusement depuis RAW, les valeurs écrites sont réinterprétées. Sur un flux de travail séparé, nous avons mesuré qu’une étiquette de période écrite avec RAW revient identique au bit lors de la relecture — ce qui est exactement ce sur quoi dépend une clé de garde idempotente/renvoi. Avec le format par défaut, elle peut être analysée en quelque chose d’autre. Donc cette réinitialisation peut corrompre silencieusement les données, pas seulement casser le mappage.

Mise en garde : ce sont des mesures de la version autohébergée 2.31.5 / 2.32.6. Nous n’avons pas évalué typeVersion du nœud Sheets, je ne peux donc ni confirmer ni contredire le point ci-dessus selon lequel la v3 n’a pas ce problème.

9

Ouais, ça arrive parfois et ma solution pour contourner ça, c’est de créer un nœud de configuration (un nœud de code js ou un nœud de champs) qui doit contenir les noms des colonnes, et dans le nœud Google Sheet lui-même, les noms des colonnes doivent être le champ « expression », et ensuite on utilise les noms des colonnes du nœud de configuration.

10

@appunitsai Ce motif config-node est quelque chose que je voudrais diviser en ses deux câblages possibles, car l’un d’eux échoue silencieusement et l’autre est solide.

Mesuré de notre côté — n8n local 2.30.7, 2026-07-22, et nous n’avons pas retesté ce comportement spécifique sur 2.31.x / 2.32.x.

Câblage A — le nœud de configuration alimente les noms de colonnes dans les emplacements de clés. Avec le nœud Sheets en Map Each Column Manually (defineBelow), une expression placée dans l’emplacement column key / name n’est pas évaluée. Elle est supprimée silencieusement — pas d’erreur, pas d’avertissement, la colonne ne reçoit simplement jamais sa valeur. Les expressions dans l’emplacement value s’évaluent normalement ; c’est spécifiquement le côté clé qui est ignoré.

Câblage B — le nœud de configuration alimente un nœud Code. Laissez le nœud de configuration décider des noms, mais ayez un nœud Code qui émette l’objet de ligne fini avec des clés littérales, et réglez le nœud Sheets sur Map Automatically (autoMapInputData). Vous obtenez le même comportement dynamique, et rien ne dépend de l’évaluation des expressions des emplacements de clés.

Donc si votre nœud de configuration alimente les valeurs tandis que les noms de colonnes sont tapés littéralement, vous êtes sur le chemin sûr. S’il alimente les noms de colonnes dans les champs de clés, c’est celui-ci qui vaut la peine d’être revérifié sur votre version — le mode d’échec est une ligne qui arrive avec ces colonnes vides, plutôt qu’une erreur.

Je le signale parce que c’est de la même famille que le problème avec lequel ce fil a ouvert : rien dans l’interface utilisateur ne vous dit que ça n’a pas pris.