Order email automation n8n: from inbox to checked row

An order email lands in the shared inbox. It has a few product codes, the quantities, and a delivery date near the bottom. Someone in the office opens the order spreadsheet and types it all in again, line by line.

On a busy Tuesday it happens again and again, and now and then a quantity goes in wrong or a delivery date never reaches the sheet.

This article explains order email automation in n8n. n8n can receive emails through its IMAP Email trigger and connect a Gmail Trigger to more than 1000 other services.¹,² In this article, we sketch a workflow for receiving an email, reading its data, checking it and writing it to a spreadsheet. We follow one ordinary email, "Order #4821", from the inbox to a proposed row that a named person checks before anything is saved.

What happens to an order email today

Consider the route an emailed order takes through your team. A customer sends an order by email. Someone reads it, opens the spreadsheet or the order system, and copies over the customer name, product codes, quantities, delivery address and date.

The work is not hard, but it is constant and it needs attention every time. One customer writes "10 boxes", another writes "10 pcs", a third attaches a PDF. A code gets mistyped, or the delivery date sits in the second paragraph and is missed. Usually the mistake shows up later, when the wrong goods are packed or a customer calls to ask where the delivery is.

This is the kind of order and document entry that software can prepare well. The aim is not to remove the person from the process. The aim is to remove the retyping and keep the decision with someone who knows the customers.

If many of your orders also arrive by WhatsApp, treat that as a separate source to plan and test. This walkthrough covers email, but the same review step should apply to every source.

Order email automation n8n: how a new order is noticed

The IMAP Email node receives emails from an IMAP email server and acts as a workflow trigger.¹ In plain words, the trigger is the starting step: a matching email arrives and the workflow begins.

You decide which mailbox it watches, so it can be the shared orders inbox instead of the owner's personal one.¹ You can also set your own rules for which emails it picks up.¹

The node can leave received emails unread, so the office still sees them as new in the inbox.³

If your company uses Gmail, n8n also has a Gmail trigger, which can be connected to more than 1000 other services.²

A third-party email trigger can pass incoming email to n8n.⁴ For example, the Atomic Mail Trigger checks the inbox on a schedule, every 5 minutes by default, and produces one item for each new message.⁵ When it is first switched on, it marks a starting point so the mail already in the inbox is not processed again.⁵

Choose a mailbox trigger based on where your mail lives, and vet any additional service before adding it.

Turning the email into a proposed row

An email as you see it is a block of text. To fill a spreadsheet, the system needs structured JSON, which simply means the email split into labelled fields such as sender, subject and body.

One email trigger parses incoming messages as JSON before streaming them to n8n.⁴ The parsed email reaches n8n within a second or two.⁴ Its published example even uses an email with the subject "Order #4821 confirmed".⁴

The subject line alone is not enough, so the workflow fetches the whole message. The IMAP node's Resolved format returns the full email with its data resolved and attachments stored as binary data.³ With the Atomic Mail service, the full body is fetched through a separate request.⁵

From there, the system prepares the row: customer, product codes, quantities and delivery date. That reading is done by an AI model step, which picks out codes, quantities and dates from free text, or by fixed rules when a customer always uses the same layout. If one email lists several products, the system prepares one line per product under the same order number, so the reviewer checks them together.

Checks for quantities and missing details

A proposed row is only useful if it tells the reviewer where to look. That is the job of the checks, which run before the row reaches a person.

Unusual quantities. If an order quantity looks unusual for that customer, flag the row for review. The same goes for units and pack sizes that do not match the price list, and for orders that arrive after your cut-off time.

Unknown product codes. Each code is compared with your price list. A code that does not match, or a product name written in a new way, is marked for review.

Missing details. No delivery address, no date, or no customer the system can match to your customer list. The row is still prepared, with the empty field clearly marked.

Duplicate order numbers. Customers sometimes resend an order or send a correction. If an order number is already in the sheet, flag the new row as a possible duplicate.

Each flag comes with a short reason, such as "quantity is much higher than this customer's usual order". Nothing is fixed silently. The reviewer sees what looked wrong and why, and decides what to do.

The person who approves the row

Every proposed row goes to a named reviewer. This is usually the person who enters orders today, because they already know the customers, the products and the usual mistakes.

The reviewer sees the proposed row next to the original email, with any flags at the top. They have three choices. They can approve the row as it is, correct a field and then approve it, or reject it, for example when the email turns out to be a question and not an order. Only approved rows are written to the spreadsheet, so nothing that a person has not seen ends up in the order sheet.

For example, the order file could have two tabs: "To check", where proposed rows wait with Status and Flag reason columns, and "Orders", the main sheet. When the reviewer sets Status to approved, the workflow copies the row to "Orders". A change or cancellation after approval arrives as a new email; the duplicate check spots the order number, and the reviewer updates the existing row instead of adding another.

Also name a backup person, and agree who makes the decisions on unusual cases. If the main reviewer is on holiday, or an order needs a decision about price or stock, it goes to someone who can decide.

n8n's list of example workflows includes a simple human-in-the-loop email-response system using AI and IMAP.⁶ We describe the wider approach in how human review keeps AI workflows reliable.

Over time, the review step tells you something useful. If the reviewer approves most rows without changes, your business may decide that some simple, unflagged orders can be saved directly. That is a decision for the business, made later and on evidence, not something switched on from the start. Even then it would cover only unflagged rows from known customers, with regular spot checks and the option to switch review back on.

What it takes to set up, and what about Latvian emails

Most of the work is in understanding your real orders and agreeing what counts as a problem. A non-technical owner or office manager can do the preparation below; connecting and testing the workflow is usually done by someone with workflow experience, on your team or from outside.

Before go-live, test the workflow on real orders in the languages your customers actually use: Latvian, Lithuanian, Estonian, Russian or English. Run the sample emails, including forwarded orders and PDFs, through the workflow and compare each proposed row with what your team typed. Then run a short pilot alongside manual entry and track corrections, review time and how often rows are flagged.

Plan for failures too. If a step fails or the spreadsheet cannot be reached, the workflow should stop, leave the email unread and notify the reviewer.

Check whether order emails contain personal data and handle them according to applicable privacy requirements. Give the workflow access only to the orders mailbox, limit who can open the review tab, and check how the tools you choose handle data. One documented email trigger parses messages and streams them to n8n, so ask where that service processes and keeps them.⁴

Ask for an estimate based on your own order volume that covers hosting and use of the AI reading step. Someone also needs to look after the workflow when the mailbox or the sheet changes. Agree in advance whether that is someone on your team or the people who built it. You can read more about our order processing workflows, or about choosing your first automation if order entry is only one of several candidates.

Frequently Asked Questions

Does this work with Gmail or with our own company mailbox?

Both can work. n8n has a Gmail trigger that connects to more than 1000 other services.² Other mailboxes can be read through an IMAP email server using the IMAP Email node.¹ For the IMAP Email node, you can choose which mailbox it receives emails from.¹

Will it go through all our old emails when it is switched on?

Not if it is set up carefully. Fetching rules decide which emails are picked up.¹ On first activation, the Atomic Mail Trigger sets a watermark, a starting point, so existing email is not replayed.⁵ Emails can also be left unread so your team still sees them as new.³

Can it read orders sent as PDF attachments?

The IMAP node's Resolved format returns the full email with attachments stored as binary data.³ Reading what is inside a PDF is a separate step, and it should be tested on your real files before go-live. Scanned or handwritten orders need closer checking by the reviewer.

How quickly does a new order show up for review?

It depends on how the inbox is checked. One third-party trigger checks every 5 minutes by default,⁵ while a relay service delivers parsed emails within a second or two.⁴ Decide whether a delay matters for your order process, even when a person reviews the row.

Does it handle order emails written in Latvian?

This needs testing before go-live, on real order emails in the languages your customers use, whether Latvian, Lithuanian, Estonian, Russian or English. The reading step is set up with written instructions and examples from your own orders, which is why those tests matter. Product names and units written in different ways are a common cause of flags. Part of the reviewer's job is to spot errors that the automatic checks have missed.