PrestaShop order workflows: statuses, emails and editing

What we would do

We would map the workflow you already run before adding states: who confirms payment, releases picking, handles exceptions and confirms dispatch. The right route depends on your payment and carrier modules, ERP or warehouse integrations, theme and checkout, existing order data, markets, accounting requirements and team permissions. Keep native states for meaningful commercial events and use separate internal stages when the missing information is a responsible person or next task.

Rehearse changes on a staging copy with representative orders and the same modules, theme and integrations. Use sandbox payments and captured mail, and isolate warehouse exports and carrier actions from live systems. Save the current configuration and state mappings, test the normal path and exceptions below, then plan the live switch with a named owner, reversal steps and a route for orders already in progress.

If you want an existing module configured and its agreed journey checked, the PrestaShop Module Installation & Configuration Service covers that scoped setup; licences, additional modules and development are separate.

Organise daily order work

Open Orders > Orders and filter the work you need: unpaid orders needing review, paid orders awaiting fulfilment or orders with a delivery problem. Use the columns and filters your version exposes. Where your version preserves filters in the URL, test a bookmark for a recurring queue and check its date range when reopening it. Confirm the selected orders before a bulk action.

Modern order pages use Symfony controllers, grids and command handlers, following the order-page migration in PrestaShop 1.7.7. AdminOrders remains a useful legacy and permission identifier, but it is not the rendering controller for every version.

The native order-list bulk menu supports changing order status and opening orders in new tabs. A bulk transition can generate documents, update stock and send mail for each order. Test a small selection and review failures before processing a large batch.

Use Orders > Invoices and Orders > Delivery Slips for supported batch PDF generation, including date-based selections. Do not expect a consolidated invoice-printing action in every order-list bulk menu. Review numbering, document text, tax information and print matching before handing a batch to the warehouse.

Keep private notes for calls, packing instructions, review decisions and corrections. Check the private/public setting before sending an order message. Record enough context that another employee can continue the work: the decision, person responsible, next action and review point. Keep sensitive customer details out of notes that do not need them.

A growing queue awaiting stock may need better replenishment or out-of-stock policy rather than another status. Review inventory, supplier lead times and pre-order terms alongside order processing. The inventory guide covers the stock decisions that feed this queue.

Understand order states and their flags

Configure modern order states under Shop Parameters > Order Settings > Statuses. PrestaShop 1.6 used Orders > Statuses. A name such as Preparation or Under review does not define its behaviour; inspect its flags.

With the example ps_ prefix, ps_order_state stores flags, ps_order_state_lang stores translated names and email-template names, ps_orders.current_state stores the current state, and ps_order_history records normal transitions. Use your installation's actual prefix.

Change states through supported order administration or core APIs. Updating current_state directly bypasses the usual history, document, email and stock behaviour. Updating a state definition is different again: it changes the definition used by future transitions.

For a conceptual workflow, see the order lifecycle documentation. Document which team applies each state and which system is authoritative for payment and dispatch.

Check the default lifecycle before customising it

Existing shops and payment modules can alter defaults. The established installation defaults provide this starting point; compare them with your own settings.

These established defaults are listed in the installation state definitions. Payment failures that never create an order have no order history to notify from; gateway behaviour is separate.

A possible ordinary flow is awaiting payment, confirmed payment, preparation, dispatch and delivery. It is not an automatically enforced universal sequence. A paid flag is an accounting/workflow decision, so do not use it as a convenient way to move an unpaid order into the warehouse queue.

Create custom states only for useful decisions: awaiting supplier, ready for pickup, under review, awaiting customer response, return requested or return received. Give each a clear name and consistent colour, then choose its flags independently. A truly internal-only label should not send mail merely because another similarly named state does.

For B2B credit terms, track fulfilment separately from collection. Quote approval, purchase orders and payment due dates need a defined process; adding a status does not create a quotation or credit-control system. Set invoice timing according to the transaction, payment terms and applicable rules, not an assumption that every invoice must follow payment. See the EU VAT invoicing guidance and your national requirements.

Work through a paid order with an address hold

A customer pays for an in-stock item, then asks support to check the delivery address before packing. Use this staging scenario to prove that a paid order can wait for a task without being treated as unpaid or dispatched.

Do not implement the hold by cycling through Canceled or Payment error: those states have stock effects. Decide who can release a hold and how a dispatch batch excludes it; an internal label alone is not proof that the warehouse respects the stop.

Keep stock and money consistent

Available stock is normally reduced during order creation through the payment/order-validation flow when stock management applies. Moving an ordinary awaiting-payment order to Payment accepted does not deduct those units a second time.

Transitions involving Canceled or Payment error can restore or deduct available stock again. Moving between shipped and unshipped states also has stock-movement effects. Packs, returned quantities and product settings matter. Test the actual transition rather than treating every state as only a label.

• Cancellation: can affect stock through the state transition, but does not automatically refund a captured payment or erase an invoice.
• Direct quantity reduction or line deletion: uses its own stock-delta handling. It is not the same process as selecting a refund's restock option.
• Refund: use the appropriate standard or partial-refund workflow, decide whether to generate a credit slip and whether goods should return to sellable stock.
• Reinstatement after cancellation/error: confirm availability and payment before moving back to a valid state. Stock can be deducted again.

Reconcile gateway transactions and recorded payments. Changing an order amount or setting a paid state does not capture extra money, and applying Refunded does not prove that the gateway returned it. Record the actual collection or refund, its reference and any outstanding amount.

Keep test orders in staging with sandbox payments and mail capture. Do not delete real accounting records to tidy a production order list. For deliberate removal of pre-launch tests, use the Delete Orders help page and preserve required records.

Send useful status emails and tracking

Choose customer notifications for meaningful events, such as confirmed payment, a material delay, ready for pickup or dispatch. A shipped message should contain the correct tracking details; a pickup message should state the location, opening hours and required identification.

1. Enable notification for the intended state and select its template for the customer's language.
2. Check the configured mail type. Paired HTML and TXT files support dual-format delivery; requirements depend on the mail configuration.
3. Check template resolution through the active mail/theme and any module override. Root mails/ files are not the only possible template location.
4. Use variables supplied by that notification path. Test rendered customer name, order reference, links, tracking and attachments rather than assuming every placeholder is available.
5. Place a staging order, apply the transition and inspect captured mail and application/mail-server logs. A sent event does not prove inbox delivery.

Design > Email Theme manages the email design workflow in supported modern versions. Keep translations and generated templates consistent when customising it.

Enter the tracking number and correct carrier URL before sending a dispatch notification. Saving tracking and moving an order to Shipped are separate actions in core, and an integration may send its own tracking email. Check for duplicate messages. Printing a label does not prove that the parcel has left the warehouse.

The core order-history resend action resends a status email. It is separate from the original order_conf confirmation with its order summary. For that dedicated resend workflow, use the Resend Order Confirmation help page.

Automate only events you can verify

Define the event and its authority before automating it. A payment-provider callback should be authenticated and matched to the right order and amount. A bank transfer needs an actual reconciliation result. A carrier delivery event is different from label creation or tracking-number entry.

Possible custom requirements include checking stock after payment, holding high-value orders for review, marking a fully packed order ready for handoff or cancelling an unpaid order after a defined window. These need a suitable integration and explicit tests; adding a workflow extension does not automatically implement every condition.

For links from native state changes or tracking-number updates to internal workflow statuses, use the Advanced Order Fulfilment help page; internal statuses are separate from native order states and do not provide arbitrary payment, amount, stock or unpaid-age conditions. Its teams, permitted transitions, role permissions and reminders organise internal responsibility; agree which queue each team works from before enabling automation.

For bank transfers, Bank Transfer Revolution imports CAMT.053, MT940 or CSV statements and matches qualifying credits to eligible orders. Uncertain entries stay for review. Rehearse a partial receipt and an unmatched reference before allowing matched receipts to mark orders paid; accepting a shortfall is a separate decision from recording money received.

Developer transition hooks

• actionOrderStatusUpdate runs during the transition. Treat it as a notification hook, not a general veto contract.
• actionOrderStatusPostUpdate runs after core state updates inside changeIdOrderState(). It is not a transaction-commit guarantee.
• actionOrderHistoryAddAfter follows insertion of the history record. In the normal setCurrentState() flow, history is added after the state-update method.

Use supported order services or the relevant order API for your version instead of raw SQL. For external work, queue a durable task with an idempotency key and retry policy. Do not assume the post-update hook means every later operation or email succeeded. Handle duplicate callbacks, partial failures and out-of-order events.

Test that repeating a payment callback or delivery notification does not create duplicate fulfilment work, payments or messages. Alert on failures rather than letting an order silently remain between systems.

Handle shipments, documents and references

In the established order model, a Partially shipped label does not record which lines went into which parcel. For occasional split fulfilment, record the shipped items and tracking for each dispatch, explain what remains and mark completion only when appropriate. If an order contains an available mug and a backordered case, record the mug against its parcel and leave the case explicitly outstanding. If your installed shop has no per-parcel records, record each dispatch's items, quantities and tracking in private order notes or your warehouse system, and keep the first dispatch's details when the second parcel leaves; overwriting the original tracking field loses the distinction. Check that each parcel's packing document lists only its contents: an order-level delivery slip may include items still outstanding.

PrestaShop 9.1 introduced a shipment feature behind an experimental flag. Check your installed version, enabled features and carrier integration before assuming either the legacy limitations or full shipment support. Test per-parcel lines, tracking, documents and payment-module compatibility when adopting a different shipment workflow. See the 9.1 shipment changes.

Invoice numbers and customer-facing order references are different identifiers. Core provides sequential invoice numbering. The default order reference falls back to nine uppercase alphabetic characters, subject to reference-generation hooks or modules. A reference such as ORD-2026-00142 is a custom format, not the standard random generator.

Choose numbering and correction procedures with your accounting requirements. A formatting extension cannot guarantee compliance in every jurisdiction. For formatting options, use the Custom Invoice Numbering help page or the Custom Order Numbering help page.

When exporting orders or invoices, define the date basis, included states, tax amounts, refunds and encoding, then reconcile totals against the accounting period. See the accounting and invoices guide.

Correct a placed order deliberately

Open the individual order under Orders > Orders. Check employee permission, payment, fulfilment, refunds and documents first. There is no universal editable-state checkbox. Native line-price editing existed before 1.7.6, and the exact available operations and lifecycle checks vary by version.

For a size change from M to L, a combination is a distinct product variant with its own stock and reference. Where no in-place swap exists, remove the old line, add the correct combination and reconcile stock, prices and payments. Do not assume an editor extension provides a single swap operation.

Core editing can update existing invoice amounts and change a subsequently regenerated PDF. The existence of an invoice is not a universal technical editing block. Determine the lawful credit-note or correction procedure before changing an issued document, and retain the required original records. Delivered-order history can impose stricter native product-editing limits.

For supported order changes, use the Order Editor help page; review the operation's preview and its stock, tax, discount, payment and invoice effects before confirming. Enable only the operation types staff need, require a reason for corrections and retain the timeline showing original and changed values.

1. Record the customer's requested change and current order amounts.
2. For an eligible unshipped address or quantity correction, use the supported edit. For a substantially different basket, compare editing with cancellation and a new order, including stock, any refund and corrections to issued documents, and handle dispatched goods through the return or replacement route. Do not bypass delivered-state restrictions by relabelling the order.
3. Apply the supported operation and compare product quantities, available stock, tax records, discounts, shipping and invoice totals.
4. Collect or refund the difference through the appropriate payment route, then record the transaction.
5. Tell the customer exactly what changed, the new total and any payment or refund consequence. Provide appropriate corrected documents or confirmation.

Bound routine customer address corrections

Order Address Change: Customer Self-Service lets signed-in customers select another address from their own address book within configured status, time and carrier restrictions. Products, payment, carrier, prices, taxes, shipping cost and totals stay unchanged. Issued invoices lock both recorded addresses; tracking or shipping progress closes delivery changes, and split orders or multiple shipments are outside this route.

Test the customer controls in the active theme. A change of destination that needs a different tax treatment, carrier or delivery price belongs with staff, who must assess those effects rather than treating self-service as a way to recalculate the sale.

Rehearse a correction before packing

A customer requests an extra matching accessory after paying, while the order is still eligible for editing. Pause picking, record the original quantities and total, add the correct product through the supported editor, then compare stock, discounts, tax and the revised total. Collect and record the balance through the payment route before releasing the order under your agreed terms. Confirm that the warehouse receives the revised contents and that the customer receives the appropriate update and documents.

For partly shipped orders, preserve what was dispatched and handle the remaining items or returns explicitly. Cancellation alone does not reverse money or paperwork. Better sizing information, address checks and a clear checkout review can reduce future correction requests.

Test and review the workflow

Create a short reference for staff: state meaning, responsible person, entry condition, notification and next action. Keep the list small enough to use consistently without prescribing a fixed number of states.

In staging, test each payment method, normal fulfilment, payment failure before and after order creation, cancellation, reinstatement, partial refund, restocking, address changes and line editing. Capture the status history, emails, payments, stock and documents before and after each operation.

Spot failures before processing the next batch

Plan the switch and staff handover

1. List every integration that reads or writes a state, including scheduled jobs. Record the actual state IDs and mappings, not just translated names.
2. Agree how orders already awaiting payment, held, partly shipped or under refund will finish their current route.
3. Keep a recoverable configuration record and a backup with a tested recovery procedure. Schedule the switch around warehouse activity and name the person who can stop processing.
4. Apply the rehearsed settings, check representative live orders and watch the next integration and dispatch runs. If you reverse a setting, reconcile effects already produced: sent mail, stock movements, issued documents and external tasks do not disappear.

What to ask your developer or agency

• Which exact shop, module versions, theme and integration mappings were tested, and where is the evidence?
• Which system owns each payment, hold, dispatch and delivery decision, and who handles exceptions?
• How do retries, partial failures and corrections reach the warehouse without duplicate work or stale data?
• Which operations can each employee perform, and where are reasons and before-and-after records kept?
• What happens to open orders at the switch, and which effects need reconciliation if we reverse it?

Use the results to update the staff reference before the new route becomes routine.

Use history timestamps to calculate time to dispatch, time waiting for stock and cancellations by stage. Define how repeated states and reopened orders count. A state distribution shows a queue; it does not by itself explain its cause.

Review failed transitions, missing tracking, document mismatches and customer questions regularly. Adjust the process and integration together so the order state remains a useful description of real work.

Questions owners ask

Should I rename a state or create a new one?

Rename it when the meaning and behaviour stay the same, checking every shop language and integration that matches names. If the meaning changes, first assess a separate state so historical entries do not become misleading. Keep a record of the original names and mappings.

Can I remove old states once the replacement is ready?

First check open orders, history, payment-module settings and integration mappings. Stop new use through the agreed process and let existing work finish before considering removal; a state absent from today's queue may still be referenced elsewhere.

Who should be allowed to correct orders?

Give staff individual accounts and permissions for their assigned work. Keep price changes, payment recording, refunds and routine address corrections within the agreed roles, and test that restricted users cannot perform those operations. A state name is not an access-control policy.