Build the message in Migma around the action the reader should complete. Then ask the Next.js owner to verify the actual destination supplied by the sending path. An email can look finished while its main button still leads to a temporary preview deployment or the wrong account journey.
This matters when an app has local, preview, and production environments. A working page in one environment does not prove that the email intended for customers uses the right origin, route, or authentication state. Treat destination review as part of the release acceptance for each email type.
Loops’ Next.js transactional email guide describes server-side email setup and passing a reset URL as template data. This article focuses on reviewing the resulting message and destination. It does not provide a new integration implementation or assume a native Migma-to-Loops export connection.
Define the action independently of its URL
Write what the button promises before reviewing the address. “Review your receipt,” “Confirm your email,” and “Open your invitation” are different actions, even when the pages share a visual design.
Ask the app owner which system creates that action and which state it requires. A receipt might belong to a particular account. An invitation may have expired or already been accepted. A confirmation link may require a specific token. Those facts should come from the application, not from generated copy or a designer’s guess.
Give Migma approved wording and safe example destinations for review. Keep real credentials and live action tokens out of shared screenshots, design references, and reusable brand instructions. An example should show the shape of the journey without exposing access.
Make a destination matrix for the email type
Start with the environments your team actually uses. The labels below are illustrative; replace them with your own approved names and destinations.
| Sending context | Expected destination | Review question |
|---|---|---|
| Local development | An approved local or test destination | Can the tester reach the page from their device? |
| Preview review | The intended review environment | Is access limited to the right reviewers? |
| Production | The approved customer-facing destination | Does the real user reach the promised action? |
| Expired action | A supported recovery path | Can the reader request the next valid step? |
A link can pass a reachability check while failing this matrix. A preview page returning a normal response is still the wrong destination for a production customer. Keep the expected environment beside the test evidence.
Inspect one populated message from each path
Have the sending owner produce an authorized test using the real template and application path. Do not stop at a preview with a URL typed manually into an editor. Inspect what the app actually supplies for the selected email type.
Check the visible button, any secondary text link, logo link, support link, and plain-text alternative if your sending path supplies one. They can be configured in different places. A corrected main button does not establish that every other destination is correct.
For an original example, imagine a team invitation whose button opens production but whose help paragraph still links to a preview help page. The email can create a confusing journey even though the invitation itself works. Record both destinations and give the owning team a specific correction.
Check state as well as environment
Review the destination as a new recipient, rather than only as an already signed-in developer. Verify what happens when the reader uses a different device, is signed out, or has already completed the action. Follow the product’s approved behavior instead of inventing an email-specific workaround.
If the action expires, make the recovery wording match the application. Do not promise that the same link always works or that opening an older email restores access. Ask the product owner to approve the current explanation and the route for requesting another action.
Avoid changing token lifetimes or security settings merely to make a test pass. A failing state should lead to an investigation by the app owner. Creative can explain a valid flow, but cannot establish whether the underlying authorization is correct.
Keep Migma’s role clear in the handoff
Use Migma for the branded message, editable layout, and reviewed action language. Run Email Preflight and resolve meaningful link, layout, or writing issues. That check helps inspect the email; it is not a substitute for the app-specific state tests above.
Use the supported HTML or app handoff your team has verified. In a Loops workflow, the responsible owner still maps template data and confirms the published destination version. Do not assume that a placeholder shown in Migma automatically becomes the right production value.
If a coding agent prepares configuration, review its proposed changes and evidence before approving a live send. Keep the email’s approved content separate from the environment configuration so reviewers can identify which part changed.
Save evidence that survives a deployment
Record the email type, template version, sending environment, expected destination, actual destination, relevant recipient state, and reviewer. Use sanitized evidence rather than storing active tokens in a general project note.
Repeat the relevant checks when the application origin, route, template data mapping, or authentication flow changes. A previous successful test belongs to the version it examined. Before releasing the next email change, compare the final Migma message with one populated test from the intended environment and follow its most important action to completion.
Frequently asked questions
Does a working link prove it is the right production link?
No. It may reach a valid preview or unrelated page. Compare its environment, route, and required user state with the approved action.
Can Migma validate an application’s reset token?
Migma can help review the message and links. The application owner must verify token validity, authorization, expiry, and recovery behavior.
Should I put real action links in a shared design brief?
Use safe examples or sanitized evidence. Keep live tokens, credentials, and unnecessary personal information out of reusable references and shared screenshots.
What changes require another destination review?
Recheck when origins, routes, template data mapping, authentication behavior, or the approved action changes. Previous evidence applies to the version tested.