# Email and SMS notifications triggered by the store

> Adding the product brand to the confirmation email, texting a customer when the parcel leaves, alerting the workshop as soon as an order contains a particular item: these three requests look alike and aren’t handled the same way.

- Source canonique : [https://allaux.fr/en/modules/notifications-email-et-sms](https://allaux.fr/en/modules/notifications-email-et-sms)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Editing an existing email: the simplest, on one condition

A store’s transactional emails rest on templates that can be edited. Adding information available in the order — a reference, a notice, a tracking link — is short work, provided the data is already reachable when the email is built. When it isn’t, it must be made available, and that is where the effort changes scale.

One point deserves flagging: editing an email template shipped with the platform without precaution loses the change at the next update, exactly as with a module. On PrestaShop, email templates can be supplied by the theme; on WordPress and WooCommerce they are overridden from the child theme. Either way, the change must live outside the core.

## SMS and internal alerts: what they really involve

An SMS isn’t a shorter email. It goes through an outside operator, with a per-message cost, a regulated sender format and its own consent rules. Technically the work is to trigger sending at the right moment, handle failures, and above all not send the same message twice if the order status changes twice. That last precaution is what separates a correct integration from an expensive one.

The internal alert is the simplest case technically and the most useful operationally: notifying an address or a team channel when an order meets a particular condition. It depends on no customer consent and costs nothing per message.

In every case I ask the same question before writing anything: what should happen if sending fails. A notification silently lost is worse than no notification at all, because everyone keeps relying on it.

## An email that leaves isn’t an email that arrives

> Sending and deliverability are separate subjects. A store can correctly send messages that land in spam for want of sender domain authentication. It is a common cause, and it is often mistaken for a module fault.

## Related pages

- **Order confirmation emails not received** — When the problem isn’t the message content but its delivery. ([/prestashop/problemes/emails-confirmation-commande-non-recus](/prestashop/problemes/emails-confirmation-commande-non-recus))
- **WooCommerce order emails not received** — The same diagnosis on the WordPress and WooCommerce side. ([/wordpress-woocommerce/problemes/emails-commande-non-recus](/wordpress-woocommerce/problemes/emails-commande-non-recus))
- **Custom order statuses** — The most common trigger for a business notification. ([/prestashop/problemes/statuts-commande-personnalises](/prestashop/problemes/statuts-commande-personnalises))

## FAQ

### Can any information be added to an order email?

Any data tied to the order, yes. Data that isn’t attached to it must first be made reachable when the message is generated, which is separate work from editing the template.

### Is customer consent needed for an SMS?

A message strictly tied to fulfilling the order and a marketing message don’t fall under the same rules. The distinction matters, and it is a point to settle before building, not after.

### How do we avoid sending the same notification several times?

By recording what has already been sent for a given order, rather than relying on the status change alone. A status can be applied twice, manually or by an automated process.

### Can notifications be tested without writing to real customers?

Yes, and it is essential: on a test copy, sending must be redirected to an internal address or blocked entirely. That is the first thing to set up before any trial.