When a customer completes a WooCommerce checkout with custom fields — engraving text for a piece of jewellery, dietary requirements for an event ticket, delivery window preference for a furniture order, ring size, gift message, or any of the dozens of other custom data points that well-configured stores collect — that data is stored as order metadata. It is in the WooCommerce database, linked to the order, accessible in the admin panel. The question most store owners do not think to ask until a problem arises is: does that data also appear in the order confirmation email?
For most stores using a quality checkout field plugin, the answer is yes — automatically, without any additional configuration. Custom field values stored as order metadata are included in the WooCommerce order confirmation email by default when the plugin stores them correctly. But “by default” hides some important nuance: how the data is labeled in the email, which emails include it, whether per-product field data is included, and what happens when the email is customised by a third-party template plugin can all vary. Understanding these details is the difference between custom field data that reliably reaches production teams and customers, and data that exists in the database but never makes it to the people who need it.
This guide covers how custom checkout field data flows from the WooCommerce checkout to order confirmation emails — for both the admin notification email and the customer-facing confirmation — what to check if your data is not appearing, how to control which fields appear in emails, and the specific considerations for per-product field data and conditional field data. All examples use the NEXU Advanced Checkout Field Editor for WooCommerce order email integration.
How WooCommerce order emails work — and where custom field data fits
WooCommerce sends several email notifications across the lifecycle of an order. Understanding which emails exist and how they are structured is the foundation for understanding where custom field data appears and why.
Sent to the store admin email address when a new order is placed. This is the email your production team, warehouse, or fulfilment coordinator receives and acts on. Custom checkout field data absolutely must appear here — this is where your team reads engraving specifications, dietary requirements, delivery instructions, ring sizes, and any other order-specific data that informs how the order is fulfilled. This is typically the highest-priority email for custom field data.
Sent to the customer immediately after order placement. This email confirms what the customer ordered and what specifications they provided. For customised or personalised products, showing the customer’s own specifications back to them in the confirmation email serves two purposes: it confirms to the customer that their specifications were received correctly, and it gives them an opportunity to identify and report any errors before production begins. An engraving customer who sees the wrong text in their confirmation email can correct it before the item is made.
WooCommerce sends additional emails when order statuses change — Processing (payment confirmed, fulfillment starting), Completed (order shipped or ready), Refunded, and others. Custom field data typically appears in the order details section of these emails too, although it is most operationally relevant in the New Order and Confirmation emails. For stores that send detailed status update emails, having custom field data visible throughout the email lifecycle is useful for customer service queries about specific orders.
The structure of a WooCommerce order email contains several sections. The order details table lists the products purchased with quantities and prices. Below or beside the order table, the billing and shipping address sections show the customer’s address. The order metadata section — sometimes labeled “Additional Information” or simply presented as a list below the order table — is where custom checkout field data appears.
WooCommerce displays order metadata in emails using a specific mechanism: it reads order meta values that are registered as displayable. A checkout field plugin that correctly saves field values using
wc_add_order_item_meta() or saves to order post meta with a display label registers the field so WooCommerce knows to include it in email output. Fields saved with underscore-prefixed keys (like _field_name) are treated as internal/hidden and do not appear in emails. The NEXU Advanced Checkout Field Editor saves fields without underscore prefixes by default, ensuring they appear in order emails automatically.Why custom field data appears automatically in NEXU-configured checkouts
When you configure a custom checkout field in the NEXU Advanced Checkout Field Editor and a customer fills it in at checkout, the field value is saved to the WooCommerce order as a named order meta entry. This happens through WooCommerce’s standard order meta system, and the key used to store the value is the field’s label or a display-ready version of it.
Because the field is stored with a display-friendly key rather than an underscore-prefixed internal key, WooCommerce’s email generation system reads it as displayable order information and includes it in the order meta section of all relevant email templates. This is the “automatic” part that the article title refers to — no additional configuration is required after setting up the checkout field. The field appears in the New Order admin notification email, the Order Confirmation customer email, and other WooCommerce order status emails, all automatically.
The practical result is that a jewellery store configuring engraving text, ring size, and metal choice fields at checkout will have all three values appear in the New Order email received by the workshop team the moment an order is placed. The team can start production immediately with all specifications confirmed — no follow-up email, no checking the admin panel separately, no risk of specifications being missed because they were in a separate system.
The admin email vs. the customer email: different purposes, same data
The New Order admin notification and the Order Confirmation customer email both contain the same custom field data, but they serve different purposes and their audiences have different needs. Understanding this distinction helps you think clearly about what a well-configured email flow looks like for different store types.
The New Order admin notification email is read by the person or team responsible for fulfilling the order — your workshop, warehouse, or production coordinator. For them, the custom field data is operational: it tells them exactly what to make and how to make it. For a personalised product store, the admin email is effectively a production order that arrives by email. Every piece of custom field data needs to be present, clearly labeled, and unambiguous. A field labeled “Engraving Text:” followed by “Forever Yours” is actionable. A cryptic field key like eng_txt followed by the same value is not.
The Order Confirmation customer email is read by the person who placed the order. For personalised or customised products, the custom field data in the confirmation email functions as a specification receipt — a record of exactly what the customer told you. This allows the customer to review their specifications and catch any errors before production. A customer who specified “Forever Yours” but meant “Forever Yours 2024” will catch this discrepancy in the confirmation email if the field value is displayed there. Without it in the email, the error is not caught until the item arrives wrong.
How to verify your custom fields appear in order emails
Do not assume your custom fields are appearing in order emails — verify it explicitly. This is a test that takes five minutes and gives you certainty rather than assumption about a critical part of your operational workflow.
In an incognito browser, add the relevant product(s) to your cart and proceed to checkout. Fill in every custom field with a distinctive test value — something clearly recognisable like “TEST ENGRAVING TEXT 123” or “TEST DIETARY: VEGAN TEST.” Use your admin email address as the customer email so you receive both the admin notification and the customer confirmation. Complete a real test order using a test payment gateway or WooCommerce’s built-in BACS (bank transfer) option to avoid actual charges.
Open the New Order notification in your inbox. Scroll through the email looking for the custom field values you entered. They should appear as a labeled list below or after the order details table. Verify that: (a) all custom fields you configured are present, (b) the values match exactly what you entered at checkout, (c) the field labels are human-readable and correctly describe the field, and (d) the values are formatted correctly — dropdown selections showing the option label rather than the option value key.
Open the Order Confirmation in the same inbox. Verify the same information is present in the customer-facing email. Note that some WooCommerce email template customisations may show different amounts of metadata in admin vs. customer emails — confirm both show the custom field data. If you use an email template plugin or custom email templates, these may handle metadata display differently from the default WooCommerce template.
Open the test order in WooCommerce admin (WooCommerce > Orders, find the test order). In the order details panel, the custom field values should appear as named metadata entries. This confirms the data was saved correctly to the database — which is the prerequisite for it appearing in emails. If the data is visible in the admin but not in emails, the issue is in email template rendering rather than data storage. If it is missing from both, the issue is in how the field data is being saved.
Troubleshooting: when custom field data does not appear in emails
If your verification test reveals that custom field data is not appearing in order confirmation emails, here are the most common causes and their solutions.
WooCommerce treats order meta keys that begin with an underscore (_field_name) as internal data and does not include them in order email output. If a checkout field plugin or custom code saves field values with underscore-prefixed keys, those values will be in the database but invisible in emails. Check the order meta in the admin — if you see field keys starting with underscores in the admin meta panel, the field is being saved as internal data.
Email template customization plugins — such as Email Customizer for WooCommerce, WooCommerce Email Template Customizer, or similar — sometimes create custom email templates that replace the default WooCommerce email template. If the custom template does not include the order metadata section from the default template, custom field data will not appear even if it is correctly saved in the database.
Some plugins hook into WooCommerce’s woocommerce_order_item_get_formatted_meta_data filter to remove or modify order meta before it is displayed in emails. A plugin that is removing spam meta entries, cleaning up internal meta keys, or customizing the metadata display for other purposes may inadvertently filter out custom field data.
Per-product checkout fields — configured on individual products rather than in the global checkout — are typically stored as order item meta rather than order post meta. The distinction matters for email display: WooCommerce displays order item meta (data associated with a specific line item) in the order details section, often appearing next to or below the product line item in the email. If per-product field data is not appearing in emails, the issue may be in how the item meta is being stored or labeled.
As covered in the Classic vs Blocks checkout guide, the Blocks checkout uses the Store API to process orders rather than traditional PHP form submission. Field data submitted through the Blocks checkout flows through the Store API extension schema rather than standard PHP hook-based order processing. A field plugin that is not fully Blocks-compatible may save field data incorrectly in the Blocks environment, resulting in data that is present in a non-display-friendly format or stored with the wrong meta key.
Controlling how custom fields appear in emails: labels, ordering, and formatting
Once you have verified that custom field data is appearing in your order emails, the next level of control is ensuring it appears with the right labels, in the right order, and formatted correctly for each audience. The default behavior is to display fields in the order they were created, using the field label as the display name. For most stores this default is adequate, but there are situations where you want more control.
The label you assign to a field in the checkout form is the same label used in the order email. Use plain, descriptive language that your production team and your customers will immediately understand. “Engraving text” is better than “Text for personalisation.” “Ring size (UK)” is better than “Size.” “Preferred collection time” is better than “Time preference.” Labels that are precise and explicit reduce misinterpretation errors when production teams read order emails and when customers verify their specifications in confirmation emails.
Custom fields typically appear in the email metadata section in the order they were created in the field editor. For production-focused admin emails, it is worth ordering fields in the sequence that your production team naturally works through them — for a personalised ring, this might be: Ring size → Metal choice → Engraving text → Font style. For customer confirmation emails, the most important fields (the specifications the customer is most likely to want to verify) should appear early in the metadata list.
For dropdown and radio button fields, the value that appears in the email is the option label rather than an option key or value ID. Make sure your option labels are clear in their email context — “Dark Roast” is clear, “DR” is not. For multi-select checkbox fields, all selected options typically appear as a comma-separated list. Verify this formatting works correctly in your test order and that the list is readable for your team.
File upload fields cannot include the uploaded file itself in an email (email attachments from order fields would require specific implementation and email size limits make this impractical). Instead, the email typically shows a link to the uploaded file or the file name. Ensure your team knows to click this link to access the uploaded file rather than expecting it as an email attachment. For production workflows that require the file itself, accessing it through the WooCommerce order admin (where it is stored as a downloadable order meta attachment) is the standard approach.
The operational impact: from order to production without manual intervention
When custom checkout field data flows correctly from the checkout form through the order record to both the admin and customer confirmation emails, the operational result is a fully self-contained order communication that requires no manual intervention between purchase and production start.
For a jewellery business, this means: customer places order with ring size, metal choice, engraving text, and font preference. Admin email arrives in the workshop inbox with all four specifications clearly labeled. Workshop begins production immediately. Customer confirmation email contains the same four specifications. Customer reviews and confirms or contacts the store within the first hour if there is an error. Production proceeds with certainty. This workflow — from order placement to production start — involves zero manual data handling steps, zero opportunity for specifications to be lost in email threads, and zero dependency on anyone manually checking the WooCommerce admin before production can begin.
The same principle applies to every store type that collects custom checkout fields. A food subscription store’s dietary requirement fields appear in the fulfillment team’s email and in the subscriber’s confirmation. A furniture store’s floor level and elevator access fields appear in the delivery coordinator’s New Order notification and in the customer’s confirmation. An event ticketing store’s attendee name and dietary fields appear in the event manager’s email and in the buyer’s confirmation.
This is the full-circle value of a well-configured checkout field setup. The NEXU Advanced WooCommerce checkout field editor for order email integration closes the loop between customer input at checkout, operational data in the order record, and communication to both the team fulfilling the order and the customer who placed it — automatically, from the first order to the thousandth.
Custom checkout field data in every order email — automatically, from day one
NEXU Advanced Checkout Field Editor saves all custom checkout field values as properly registered order metadata, ensuring they appear automatically in WooCommerce admin notifications, customer confirmations, and all order status emails — no extra configuration required.
Finally got the custom engraving text to show in emails!
Picked this up for a client's jewelry site where engravings are a huge part of their orders. the way it automatically pulls custom fields into emails is so smooth no extra setup or fuss, which saved me a ton of time I'd normally spend tweaking things manually. The one little thing?
This guide saved me so many hours of frustration with my WooCommerce store! i run a small jewelry shop where customers add engraving text at checkout, and I used to manually copy all those details into emails total pain. after following the steps here, the custom fields now auto populate in both customer and admin order emails. the only snag was figuring out my plugin's metadata settings (thankfully, the troubleshooting section pointed me in the right direction)