Importing a spreadsheet sounds simple. It is not, for four reasons.<\/p>\n
Volume.<\/strong> Hundreds or thousands of rows, each needing a record created.<\/p>\n Duplicates.<\/strong> Run it twice and you get two of everything, unless something prevents it.<\/p>\n Bad rows.<\/strong> Missing fields, wrong formats, values that do not match anything.<\/p>\n Partial failure.<\/strong> It gets to row 340 and something breaks. What now?<\/p>\n Odoo’s own import handles simple cases well.<\/strong> A workflow earns its place when the file needs validating, transforming, or checking against existing records first.<\/p>\n A Spreadsheet File node<\/strong> converts CSV or Excel from binary into structured records the workflow can work with.<\/p>\n Each row becomes an item.<\/strong> Which means the next node runs once per row \u2014 500 rows, 500 executions.<\/p>\n That is usually what you want<\/strong>, and it is also why bulk imports need batching. More on that below.<\/p>\n Do not rely on the file’s column names matching your fields.<\/strong><\/p>\n Map them in one visible place \u2014 source column to target field. Restaurant name to partner name, licence number to reference, expiry date to a date field.<\/p>\n Two reasons this matters:<\/strong><\/p>\n Source column names change.<\/strong> A published spreadsheet gets reformatted and suddenly “Licence No” is “Licence Number”. With mapping in one place, that is a five-minute edit.<\/p>\n It documents itself.<\/strong> Somebody reading the workflow can see exactly what goes where.<\/p>\n FIGURE 1: THE IMPORT CHAIN<\/p>\n Read the file<\/p>\n Validate<\/p>\n Check existing<\/p>\n Create in batches<\/p>\n Check each row before doing anything with it.<\/strong><\/p>\n What to check:<\/strong><\/p>\n Required fields present.<\/strong> A row with no identifier cannot be matched or created sensibly.<\/p>\n Formats correct.<\/strong> Dates that parse. Numbers that are numbers. Phone numbers in a consistent shape.<\/p>\n Values that must match something.<\/strong> A category, a country, a currency \u2014 does it exist in Odoo?<\/p>\n What to do with a bad row:<\/strong><\/p>\n Skip it, log it, and continue.<\/strong> Then report all the skipped rows at the end.<\/p>\n Not:<\/strong> stop the whole run. One bad row out of 500 should not block the other 499.<\/p>\n Not:<\/strong> import it anyway with blanks. That creates records somebody has to clean up later, and nobody will.<\/p>\n The most important part of any import workflow.<\/strong><\/p>\n Imports get re-run. Somebody tests it. A file gets sent twice. A scheduled job overlaps with itself.<\/p>\n Without a duplicate check, each of those doubles your data.<\/strong><\/p>\n The pattern:<\/strong><\/p>\n Search Odoo<\/strong> for the record using a stable identifier.<\/p>\n If found<\/strong>, either update it or skip it \u2014 decide which, per import.<\/p>\n If not found<\/strong>, create it.<\/p>\n Match on something that does not change.<\/strong> A licence number, a registration number, a SKU, an order reference.<\/p>\n Never match on a name.<\/strong> Names get edited, and the day somebody fixes a spelling you get a duplicate \u2014 silently.<\/p>\n FIGURE 2: THE FOUR THINGS EVERY IMPORT NEEDS<\/p>\n A duplicate check<\/p>\n Row validation<\/p>\n Batching<\/p>\n A run summary<\/p>\n Sending 500 records one at a time is slow<\/strong> and it loads Odoo unnecessarily.<\/p>\n Batch them.<\/strong> Process 50 at a time, or use Odoo’s ability to create several records in one call.<\/p>\n Two benefits:<\/strong><\/p>\n Speed.<\/strong> Fewer round trips.<\/p>\n Reliability.<\/strong> Fewer chances for a timeout, and less strain on the target system.<\/p>\n Find the right batch size by testing.<\/strong> Too small and you gain nothing. Too large and a single failure takes the whole batch with it.<\/p>\n Decide in advance what happens when it fails at row 340.<\/strong><\/p>\n Option 1 \u2014 continue.<\/strong> Log the failure, carry on, report everything at the end. Right for most data imports, where one bad row should not block the rest.<\/p>\n Option 2 \u2014 stop.<\/strong> Right when the rows depend on each other, or when a partial import would leave inconsistent data.<\/p>\n Whichever you choose, you must know where it got to.<\/strong> A run that failed halfway with no record of what was created is the worst outcome \u2014 you cannot safely re-run and you cannot safely continue.<\/p>\n Which is why the duplicate check matters even more here.<\/strong> With it, re-running a failed import is safe: the rows already created are found and skipped.<\/p>\n Every bulk import should end with a summary<\/strong>, sent to a person.<\/p>\n What it should say:<\/strong><\/p>\n Without this, an import that half-worked looks identical to one that fully worked.<\/strong> Somebody finds out three weeks later when a report is short.<\/p>\n Most imports create more than one thing per row.<\/p>\n A licence import<\/strong> creates a contact and a licence record linked to it.<\/p>\n A product import<\/strong> may create a category, then the product.<\/p>\n An order import<\/strong> creates a partner, then the order, then the lines.<\/p>\n The order matters.<\/strong> Create the parent first, get its ID, then create the child linked to it.<\/p>\n And each level needs its own duplicate check.<\/strong> The contact might exist even when the licence does not.<\/p>\n FIGURE 3: AN IMPORT THAT STAYS CLEAN AND ONE THAT DOES NOT<\/p>\n Stays clean<\/p>\n Creates cleanup<\/p>\n Three common sources, and each changes the trigger.<\/p>\n Uploaded by a person.<\/strong> A webhook receives the file, or it lands in a watched folder.<\/p>\n Sent by another system.<\/strong> A webhook, or fetched on a schedule.<\/p>\n Downloaded from somewhere.<\/strong> A published dataset, a supplier portal. Fetched on a schedule, or by a separate step if the source needs navigating.<\/p>\n One useful principle:<\/strong> send the whole file in one request rather than row by row. Fewer executions, and no risk of half a file arriving.<\/p>\n Test with a real file<\/strong>, not a clean sample.<\/p>\n Specifically test:<\/strong><\/p>\n The double-import test is the one that matters most.<\/strong> If running it twice creates duplicates, the workflow is not ready.<\/p>\n Bulk import is not just reading a file. It is validate, check, batch, and report.<\/strong><\/p>\n The duplicate check on a stable identifier is what makes it safe to re-run<\/strong> \u2014 and imports always get re-run eventually.<\/p>\n Skip bad rows and report them.<\/strong> Do not stop the run and do not import blanks.<\/p>\n And end every run with a summary somebody actually reads. An import that half-worked looks exactly like one that worked.<\/p>\n Spreadsheets being typed into Odoo by hand?<\/p>\n Get in touch. We build imports with validation, duplicate detection and a run summary \u2014 so re-running is safe and half-failures are visible.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The problem with bulk imports Importing a spreadsheet sounds simple. It is not, for four reasons. Volume. Hundreds or thousands of rows, each needing a record created. Duplicates. Run it twice and you get two of everything, unless something prevents it. Bad rows. Missing fields, wrong formats, values that do not match anything. Partial failure. […]<\/p>\n","protected":false},"author":3,"featured_media":9278,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[28],"tags":[],"class_list":["post-9277","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-n8n"],"yoast_head":"\nReading the file<\/h2>\n
Map the fields explicitly<\/h2>\n
\n
\n
\n
\n
Validate before you import<\/h2>\n
The duplicate check<\/h2>\n
\n
\n
\n
\n
Batching<\/h2>\n
Partial failure<\/h2>\n
The run summary<\/h2>\n
\n
Related records<\/h2>\n
\n
\n
Where the file comes from<\/h2>\n
Testing<\/h2>\n
\n
The short version<\/h2>\n