# Creating or editing custom order statuses on PrestaShop

> Creating a custom status, hiding an existing one, or making a status change automatically based on an event: order status management touches display, the associated email, and sometimes a 500 error when one of the two is misconfigured.

- Source canonique : [https://allaux.fr/en/prestashop/problemes/statuts-commande-personnalises](https://allaux.fr/en/prestashop/problemes/statuts-commande-personnalises)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Create or edit the status under Orders > Statuses: label, colour, email sending and the linked template are all set on that screen, each status being a row of ps_order_state. If moving an order to that status returns a 500, the matching email template is missing or malformed in mails/en/ — the message generation breaks, not the status change.

## What’s a back-office setting

Statuses are managed under Orders > Statuses, where each one can have its own label, colour, and above all an automatic email trigger to the customer, with its own template. Creating a new status, attaching or removing its email, changing its colour: all of that happens from this screen, no development needed.

What isn’t natively supported, though: hiding an existing status from certain back-office users, or pulling it out of the standard workflow while keeping it for history. A status can be disabled or deleted, it can’t be conditionally hidden without development.

## The 500 error on a status change

This is a common case and almost always traces back to the same cause: the email template tied to the new status is missing, malformed, or references a logo that can’t be found. A status change triggers the email being generated, and one undefined Smarty variable in that template is enough to break the whole process with a 500 error, even if the status-change logic itself is correct.

I always start by checking the email template for the status in question, inside the mails/ folder for the language used, before looking for a more complex cause.

## Automating a status change

Making a status change automatically — for example as soon as a carrier tracking number is entered on the order — isn’t natively available in PrestaShop. It requires hooking code onto an appropriate hook, for instance when the order is updated, to trigger the status change under the desired condition. That’s targeted development, not a setting.

## Back-office screen, or custom hook?

> Creating, editing or attaching an email to a status happens under Orders > Statuses. Conditionally hiding a status or automating its trigger based on an event needs development on a PrestaShop hook.

## Related pages

- **Invoice display or template issue** — Invoice generation depends directly on the status marked as paid: the two settings are linked. ([/prestashop/problemes/factures-affichage-modele](/prestashop/problemes/factures-affichage-modele))
- **Order confirmation emails not received** — Every status has its own email template: a full diagnosis for when these emails never arrive. ([/prestashop/problemes/emails-confirmation-commande-non-recus](/prestashop/problemes/emails-confirmation-commande-non-recus))
- **500 error or blank page on PrestaShop** — How to read the real error messages when a status change triggers a 500 error. ([/prestashop/erreur-500](/prestashop/erreur-500))
- **Custom module development** — Hook-based automation, conditional hiding: when a need goes beyond the standard configuration screen. ([/prestashop/module-sur-mesure](/prestashop/module-sur-mesure))

## FAQ

### Can a status be hidden without deleting it?

Not natively for conditional use: PrestaShop only offers enabling or disabling a status globally. Hiding it based on the back-office user’s profile needs development.

### Does a module exist that automatically changes an order’s status?

Modules exist for specific cases, such as payment or carrier, but for logic specific to a given site, I generally build a dedicated hook rather than adapting a generic module.

### Why does a 500 error only appear on certain statuses?

Because each status has its own email template: if only one of those templates is broken, only the change to that specific status triggers the error, the others keep working normally.

### Can an existing status be renamed without risk?

Yes, renaming the label has no technical impact. What needs more care is changing its behaviour — history colour, email sending, associated invoicing status — since other site settings can rely on it.