Email templater

Easy and intuitive to use The tool is designed to be simple and user-friendly, allowing you to quickly create and customize your email templates.

Accessing the email templater You can access the editor from Settings > General settings > Email template editor [Beta].

Template scopes

The platform manages two families of email templates, identified by their scope:

Storefront templates

Storefront templates are contextualized by store view and locale: each template can have a different content and enabled/disabled state per store view and per locale. See Email Localization for how the locale of an outgoing email is resolved.

Back Office templates

The Back Office templates are available in the same editor:

⚠️

Warning: Back Office templates are global to the platform. The template detail page hides the store view and locale selectors, and both the enabled/disabled state and the content edits apply globally — there is no per-store-view or per-locale segmentation for these templates.

Back Office user emails

Emails addressed to Back Office users — operators and suppliers — have their own templates, separate from the customer-facing ones sent to the storefront.

Both behave like any other template of the catalogue: they are enabled, disabled and customised from the email templater, at the platform level since they carry the BACK_OFFICE scope.

The corresponding storefront templates are unchanged: a customer user receiving their access or resetting their password still gets the customer-facing email, in the locale of their store view. Configuring the Back Office version has no effect on the storefront one, and the other way round.

📘

Note: The content of new-operator-user-creation is written for an operator and carries no activation link — an operator account does not go through the storefront activation flow.

flowchart LR
  %% Styles (Readme)
  classDef create   fill:#e8f1ff,stroke:#2f6feb,stroke-width:2px,color:#0b3d91;
  classDef read     fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#1e1b4b;
  classDef update   fill:#e0f7fa,stroke:#06b6d4,stroke-width:2px,color:#0c4a6e;
  classDef add      fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
  classDef remove   fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;
  classDef decision fill:#fff4e5,stroke:#f59e0b,stroke-width:2px,color:#7a3e00;
  classDef place    fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d;
  classDef sys      fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827;
  classDef stop     fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;

  A[📧 Account email<br>triggered] --> B{Recipient}
  B -->|Customer user| C[📘 Storefront template<br>per store view and locale]
  B -->|Operator| D[🧾 new-operator-user-creation<br>global]
  B -->|Operator or supplier resetting a password| E[🧾 reset-password-bo<br>global]
  C --> F[✅ Email sent]
  D --> F
  E --> F

  class A sys
  class B decision
  class C read
  class D read
  class E read
  class F place
  style A rx:8,ry:8
  style C rx:8,ry:8
  style D rx:8,ry:8
  style E rx:8,ry:8
  style F rx:8,ry:8

Logistic order confirmation

logistic-order-confirmation carries the STOREFRONT scope: the email is configured per store view and per locale, like the other emails addressed to customers. Its activation, its subject and its content are set for each store view, and the email is sent on the store view of the order.

⚠️

Warning: The global configuration of this template no longer exists. If your integration read or wrote its enabled state without a store view, target the store views concerned instead.

Default templates

Each store ships with default email templates built into the platform. When no custom template has been configured for an email, the default template is used as a fallback, so critical emails (order confirmations, account emails, etc.) are always sent.

📘

Note: Default templates are being rolled out progressively. Contact DJUST to confirm availability on your environment.

Job execution failure notification

new_job_execution_failed was the last template of the catalogue shipped without a default version. On a tenant that had not configured its own, the Back Office editor opened on a blank canvas and the failure notification could not be sent — a failed import execution went unnoticed.

A default template is now provided for this notification. Without a custom template, the email is sent with this default content, and the editor displays its design, ready to be adapted.

The email recapitulates:

• the name and the type of the import concerned,
• its start and end dates and times,
• the recipient,
• a direct link to the execution,
• the identifier of the failed execution.

Behaviour is unchanged for tenants that already have a custom template: the custom one still takes precedence.

✅

Tip: The jobExecutionId variable is available in this template. Keeping it in your own version gives the recipient the execution identifier to pass on to DJUST support, which speeds up diagnosis. The addition is backward compatible and does not modify any existing custom template.

See Job Configuration - Overview for how execution identifiers are exposed in the Back Office and through the API.

flowchart LR
  %% Styles (Readme)
  classDef create   fill:#e8f1ff,stroke:#2f6feb,stroke-width:2px,color:#0b3d91;
  classDef read     fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#1e1b4b;
  classDef update   fill:#e0f7fa,stroke:#06b6d4,stroke-width:2px,color:#0c4a6e;
  classDef add      fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
  classDef remove   fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;
  classDef decision fill:#fff4e5,stroke:#f59e0b,stroke-width:2px,color:#7a3e00;
  classDef place    fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d;
  classDef sys      fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827;
  classDef stop     fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;

  A[📧 Email event<br>triggered] --> B{Template<br>enabled}
  B -->|No| X[🚫 No email sent]
  B -->|Yes| C{Custom template<br>configured}
  C -->|Yes| D[🧾 Use custom<br>template]
  C -->|No| E[📘 Use default<br>template]
  D --> F[✅ Email sent]
  E --> F

  class A sys
  class B decision
  class C decision
  class D read
  class E read
  class F place
  class X stop
  style A rx:8,ry:8
  style D rx:8,ry:8
  style E rx:8,ry:8
  style F rx:8,ry:8
  style X rx:8,ry:8

Enabling and disabling templates

Each template can be enabled or disabled directly from the Back Office:

• Storefront templates — per template, per store view, and per locale.
• Back Office templates — per template, globally.

A disabled template stops the corresponding email from being sent.

✅

Tip: Scope changes are backward compatible. On an existing platform, the enabled state and the custom content already configured are carried over to the template in its new scope — no email starts or stops being sent because of the change.

Email template categories All templates start as blank drafts. They are organized into four categories:

• All
• Account
• Order
• Quote

Page structure The email template editor is divided into five main sections:

1. Settings
   • Navigate between different emails
2. Subject
   • Enter the subject line of the email
3. Additional recipients
   • Manage CC and BCC recipients
4. Variables
   • Insert any of the available variables into the email you are creating
5. Template editor
   • On the left: the main preview area
   • On the right: design options (heading, button, image, color, size, typography, etc.)
   • Works with a drag-and-drop interface for easy customization

Managing templates via the API

Email templates can also be managed through the Admin API:

The template context returned by these endpoints carries a scope field (STOREFRONT or BACK_OFFICE).

{
  "id": "product-export-download",
  "name": "Product export download",
  "enabled": true,
  "scope": "BACK_OFFICE",
  "locales": [
    "en_US",
    "fr_FR"
  ],
  "mailTemplates": [
    {
      "locale": "en_US",
      "templateId": "product-export-download"
    }
  ]
}

✅

Tip: The scope field is additive and backward compatible: existing integrations that ignore it keep working, and templates without a scope behave as storefront templates.