When a Magento email carries the wrong store name, a new logo in the design file may not solve the problem. The final notification can combine a body template with a header, footer, variables, and configuration chosen for a particular store view.
Start in Migma by reviewing what the customer should recognize: brand identity, language, support destination, and message purpose. Then have the Adobe Commerce owner trace how those elements are assembled in the actual storefront notification. This connects creative review to the configuration that determines the received email.
This guide is published by Migma. It presents an editorial troubleshooting workflow, not a native Magento integration or a deployment procedure. Adobe’s template guidance was checked on October 20, 2026.
Identify the exact storefront and message
Begin with one affected example. Record the store view, notification type, expected identity, observed mismatch, and the time it was generated. Use a redacted sample rather than circulating unnecessary customer details.
A fictional retailer might run an English equipment store and a separate local-language outlet. The outlet’s welcome email could contain the right body copy but send readers to the equipment store when they click the header. That is a different fault from a missing logo or an untranslated product description.
Describe the failure from the reader’s perspective. “The header opens the other storefront” gives the implementation owner a reproducible check. “Branding looks wrong” leaves too many possible causes open.
Review the complete message composition
Adobe’s custom-email-template documentation explains that system messages combine a body template with header and footer templates. It also documents customization at website, store, or store-view scope and the need to configure the correct custom template.
This means a body-only preview cannot establish the whole message’s identity. Ask the implementation owner which header and footer are selected and which configuration chooses the body for the affected notification. Preserve the relevant template references in the review record.
For a creative review, examine these elements together:
| Element | Customer-facing question | Evidence to request |
|---|---|---|
| Header | Which brand is speaking, and where does its link go? | The populated header and actual destination |
| Body | Is the purpose and language right for this storefront? | The selected message template and approved sample facts |
| Footer | Can the reader reach the right team? | Working support and store-information links |
| Variables | Do store-specific values match the message? | A populated example from the affected store view |
These are acceptance questions rather than instructions to change production settings. The Commerce owner should use the current official procedure for your installation.
Build the intended identity in Migma
Review the correct Migma brand context before drafting. Check the logo, palette, type, voice, saved references, and approved company details. A design that starts from another brand’s context can introduce a second error while the first one is being investigated.
Give the draft a specific storefront brief. For the fictional outlet, name the approved language, support destination, and homepage. State which message elements the implementation owner will supply and which wording must remain exact. Do not paste live customer data into a generic design prompt.
Create a complete visual reference that makes the intended header, body, and footer relationship clear. If the final Commerce implementation assembles those parts separately, document that handoff. This workflow does not assume that downloading one HTML file automatically configures every template part in Magento.
Protect platform variables during implementation
Adobe warns against overwriting code enclosed in double braces when editing template content. That is an important boundary between the reviewed copy and the platform’s dynamic values.
Have the implementer identify the variables and directives that belong to the notification. A designer’s request to change the surrounding sentence should not silently alter the order number, store URL, or other dynamic expression. Use approved sample values to check grammar around the populated fields.
If a variable is absent or resolves unexpectedly, leave the question with the implementation owner. Do not invent replacement syntax from an unrelated platform. A visually plausible placeholder is not evidence that the live notification can populate it correctly.
Compare the configured result with the reference
Use Migma’s export guidance for the supported creative handoff route, then review the result in the destination. The owner needs to verify the selected custom templates and scope; a saved template is not proof that the affected store view uses it.
For the fictional outlet, repeat the same welcome-message scenario using approved test data. Confirm that the header opens the outlet, the body uses the intended language, and the footer reaches the right support route. Then check a comparison storefront so the review can detect an unintended shared change.
This is especially useful when a correction appears to work in one preview but the received message still looks different. Trace the actual configuration and generated message before redesigning the creative again.
Finish with inbox and ownership checks
Run Email Preflight on the Migma reference and resolve important warnings. Check the final platform-generated message in relevant inboxes, including narrow layouts and dark mode where your team can test them. Rendering can differ across clients; do not promise identical output.
Keep the affected store view, template references, approved Migma version, sample scenario, final destinations, and reviewer together. Include any unresolved limitation. The result should explain both what the customer sees and which implementation owns it.
Brevo’s Magento automation guide provides broader discovery context for multi-store email operations. This narrower workflow stays with one problem: making the final notification unmistakably belong to the right storefront. Begin with one reviewed Migma reference and verify the complete assembled message before expanding the change.
Frequently Asked Questions
Why can the body be correct while the store identity is wrong?
Adobe documents a message made from body, header, and footer templates, with configuration at different store scopes. Review the assembled result and selected configuration rather than the body alone.
Does saving a custom template make the store view use it?
Do not assume so. Adobe’s guidance includes updating configuration to choose the custom template. Have the Commerce owner verify the actual assignment for the affected notification and scope.
Can a Migma export configure all Magento email parts?
This workflow does not claim that. Use Migma for the approved creative reference and supported HTML handoff, while the Commerce implementer maps the platform’s header, body, footer, variables, and configuration.
What should a storefront identity acceptance record include?
Record the store view, notification type, selected template references, approved Migma version, populated test scenario, working destinations, and reviewer. Include unresolved limitations and check a comparison storefront when shared settings could be affected.