How to automate email to orders in Dynamics NAV
Short answer
Read a shared mailbox over Microsoft Graph, EWS or IMAP, extract the structured fields with a language model or rules, and create draft documents in NAV through a published codeunit. A person reviews low-confidence drafts, and the original email is attached to the NAV record.
Customer purchase orders, RFQs and supplier acknowledgements still arrive as email. A sales admin opens each message, finds the customer, looks up items and keys a Sales Order line by line. It is slow and the errors are expensive.
NAV is good at validating a document once it exists. The weak spot is turning an email into a correct draft. That is where extraction models help, as long as every output goes through NAV's own validation: customer exists, item exists, unit of measure is valid, price comes from the price list.
The principle is simple: the model proposes, NAV disposes, and a human sees anything uncertain.
What teams use it for
Customer PO to Sales Order
Parse PO number, ship-to, lines and requested dates, then create a draft Sales Header and Sales Lines for review.
RFQ to Sales Quote
Turn a request for quotation into a Sales Quote with matched items or placeholder lines for engineering.
Supplier acknowledgement updates
Read acknowledgement emails and propose Promised Receipt Date changes on Purchase Lines.
Invoice emails to purchase invoices
Route PDF attachments to the document capture path so a Purchase Invoice draft is created.
Shipment confirmation from carriers
Extract tracking numbers from carrier mails and add them to the Sales Shipment record.
Triage and routing
Classify general mail as quote request, complaint, order change or other and route to the right team queue.
Microsoft Dynamics NAV integration surface
- Incoming Documents (table 130, from NAV 2016) let you attach a file or email to a record and create purchase documents from it, which is a good landing zone for attachments.
- Web services published from codeunits can create Sales Header and Sales Line or Purchase Header and Purchase Line with validation, using the standard Validate logic rather than raw inserts.
- Document Attachment support in older builds is limited; many teams store the original email as a link or a record link, or in a custom table with a blob.
- Customer and Item cross-references (Item Cross Reference, renamed Item Reference in later products) map customer part numbers to your items, which is key for PO parsing.
- Job Queue Entries or a Windows service can poll your mailbox, while the NAV Application Server hosts the codeunit that applies drafts.
How it works
- 1
Choose the mailbox access
Use Microsoft Graph for Microsoft 365, EWS or IMAP for on-prem Exchange. Use a dedicated shared mailbox and a processed folder.
- 2
Classify the message
Decide if it is a PO, RFQ, acknowledgement, invoice or noise. Rules handle obvious senders; a model handles the rest.
- 3
Extract structured fields
Pull customer, PO number, line items, quantities, dates and addresses into a JSON structure. For PDFs, run the text or OCR step first.
- 4
Resolve against NAV
Match the sender to a Customer, use Item Cross Reference to map part numbers, and flag any unmatched value.
- 5
Create a draft through a codeunit
Call a published codeunit that creates the document with Validate calls so pricing, UoM and credit checks fire.
- 6
Score confidence
Auto-accept only when all fields resolve and totals match the PO. Everything else goes to a review queue.
- 7
Close the loop
Attach the source email, write the NAV document number back to the message, and move it to a processed folder.
Example flows
Clean customer PO
Trigger: A known buyer emails a PO with a PDF.
- The mailbox poller picks up the message.
- Extraction reads the PO number and four lines.
- Cross-references map customer part numbers to NAV items.
- The codeunit creates a draft Sales Order.
- The sales admin glances at it and releases.
Result: Entry time drops from many minutes to a quick check.
Ambiguous RFQ
Trigger: An email asks for a price on a part described in prose.
- Classifier marks it as an RFQ.
- The extractor finds quantity and delivery date but no item number.
- A match against Item descriptions returns two candidates.
- The draft goes to a review queue with both options.
Result: An estimator picks the item instead of retyping the request.
Supplier delay notice
Trigger: A supplier writes that a line will be late.
- The model extracts PO number and new date.
- The line is found by PO and item.
- A proposed date change is stored.
- The buyer accepts or rejects it.
Result: Promised dates reflect reality without manual chasing.
Keeping data on-prem
The mailbox, extraction model and NAV can all stay inside your network. Use on-prem Exchange with EWS or IMAP, or a Graph app with limited scope if you are on Microsoft 365. Run the language model on local GPUs so customer POs and pricing never leave the site. The application only needs read access to the mailbox, the ability to call the published NAV web service, and storage for source files. Treat attachments as untrusted and scan them before parsing.
Security checklist
- Use a dedicated mailbox identity with the minimum Graph or Exchange permissions.
- Scan attachments for malware and ignore macros and active content.
- Never let the model write directly to the NAV database; go through validated codeunits.
- Guard against prompt injection in email text by limiting the model to extraction with a fixed schema.
- Keep an audit link from every created document to its source email.
Ways to get it done
NAV Incoming Documents with a capture service
Effort: Days to configure, plus service fees.
Invoices and structured PDFs on NAV 2016 or later.
Custom mailbox processor with web services
Effort: 4 to 8 weeks for POs and RFQs.
Varied customer PO formats and RFQs.
Partner build with Netray
Effort: Scoped; pilot on one mailbox in a few weeks.
High volume, many formats, local model required.
Pitfalls
- !Auto-posting without review turns a misread quantity into a real shipment.
- !Customer part numbers without cross-references force fuzzy matching and errors.
- !Replies and forwards duplicate the same PO; dedupe by PO number and sender.
- !Embedded images of tables defeat text extraction unless OCR is added.
- !Pricing from the email should be compared to NAV prices, not blindly applied.
Frequently asked questions
Can NAV read emails by itself?
Not for order capture. NAV can send mail and, in some versions, handle Incoming Documents, but reading a mailbox and understanding a PO needs an external processor that creates documents through web services.
Is it safe to auto-create orders?
Create drafts, not released orders, until you have measured accuracy for a few weeks. Auto-release only for known customers with exact matches and totals that agree with the PO.
What if each customer uses a different PO format?
A language model handles layout variety better than templates, but you still need cross-references and validation. Add per-customer rules where the format is stable and keep the model for the rest.
Does it work with NAV 2009?
Possibly, through SOAP web services in the RoleTailored client era, but old versions are harder to support. Check that you can publish codeunits and that your security team accepts the age of the platform.
Can the model run on-prem?
Yes. Open-weight models served locally can extract fields from POs and RFQs. Plan GPU capacity for peak mailbox volume and keep a rules fallback for simple senders.
Want Email automation working on your Microsoft Dynamics NAV?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment