Before redesigning a SaaS email program, find out which messages exist and who can change them. A welcome email may live in a lifecycle platform while a similar introduction ships from application code. The brand folder can contain a third version that nobody sends.
Start in Migma with a reviewed creative reference, then connect each email to its actual sending owner and current product purpose. You can improve the design without pretending that a folder of attractive templates is a complete program inventory.
This guide is published by Migma. The inventory below is our editorial worksheet, not a compliance certification or a platform benchmark. Current product documentation was checked on October 16, 2026.
Inventory messages rather than software accounts
A list of subscriptions tells you which tools you pay for. It does not tell you what a new user receives after inviting a teammate, changing a plan, or failing to finish setup. Make the message the unit of review.
Give each active message a plain name based on its job: confirm the invitation, explain the next setup action, announce a feature, or recover a failed payment. Keep internal template identifiers in your working record when they help locate it, but do not use those identifiers as reader-facing copy.
Loops' SaaS email program audit brings together data, lifecycle coverage, safety, and measurement. Use that broader guide for program assessment. This article addresses the narrower preparation task: reconciling creative references with real sending locations and owners.
Build one row for each message job
You can use a spreadsheet, document, or existing project board. The record should be easy for a designer and an engineer to read together.
| Field | Useful entry |
|---|---|
| Message job | Confirm a teammate invitation |
| Reader state | Invited user who has not accepted |
| Current creative | Link to the reviewed Migma reference |
| Sending location | Actual template or workflow used today |
| Product owner | Person who verifies the invitation state |
| Creative owner | Person who approves wording and design |
| Sending owner | Person who can safely change the live implementation |
| Evidence | Recent redacted example or controlled test |
| Next decision | Keep, investigate, redesign, or retire through an approved change |
These entries are illustrative. Adapt them to your program instead of filling every row with the same generic owner. One person can hold several roles, but each decision still needs a clear home.
Record unknowns honestly. “Probably sent by the app” is a question to investigate, not a confirmed sending location. Keep the current inventory separate from desired future messages so planned work does not look live.
Reconcile three versions of the truth
Ask your team to bring three things: the design reference, the sending configuration, and an actual rendered example. They answer different questions.
The Migma reference shows the intended creative. The sending configuration shows which template and conditions are configured. The received example shows what the final system produced for particular data. None replaces the others.
For the invitation example, compare the organization name, inviter name, button destination, expiry explanation, and support route across all three. If the application adds a wrapper or inserts a different fallback, the email can diverge from the approved reference even when the central content is correct.
Use redacted examples in shared review. Keep credentials, real sign-in links, and unnecessary personal data out of the creative packet. Ask the system owner to provide safe representative data when the original message contains sensitive values.
Choose the first redesign by the reader's problem
Do not begin with the oldest-looking email simply because it is easy to spot. Look for a concrete failure: an invitation that names the wrong workspace, a setup message with no clear next step, or a feature announcement that links to an unavailable screen.
Have the product and sending owners confirm whether the problem belongs to content, data, or delivery. A design edit will not repair a missing event. A transport change will not explain an unclear action. Mark unresolved causes as investigation work before requesting a new template.
For a confirmed creative problem, give Migma the reviewed facts, current reference, desired reader action, and constraints. Migma's brand setup supports reviewed identity, instructions, and references. Verify those inputs before reusing them across the program.
Close the row with a tested handoff
Once the new creative is approved, run Email Preflight, resolve relevant layout, link, and writing findings, and inspect a test. Then use Migma's send or export workflow for your chosen destination. A downloaded file or exported template is not evidence that a live message changed.
Have the sending owner test the final implementation with representative data and the relevant product state. For a Loops workflow, that means reviewing the actual message and workflow configuration in Loops; it does not imply that Migma automatically imports or owns that workflow.
Update the inventory only after the intended change is confirmed. Keep the approved reference, final implementation location, test date, and owner together. If a message is being retired, use your organization's authorized change process rather than deleting it during a creative cleanup.
At the next product release, revisit the affected rows. A renamed feature or changed setup path can invalidate good creative without anyone opening the design file. Use the inventory to bring those specific changes into your next Migma brief, with the right owner already identified.
Frequently Asked Questions
What belongs in a SaaS email inventory?
Record each message job, reader state, approved creative, actual sending location, responsible owners, and evidence. A software subscription list alone cannot show which version reaches the reader.
Should I redesign an email with an unknown sending owner?
First locate the owner and implementation. You can prepare a proposed creative, but do not treat it as a live replacement until the final sending path and representative data have been tested.
Can the Migma preview prove a workflow is live?
No. A preview establishes the intended creative. Check the sending configuration and a controlled final-platform test separately before updating the inventory as implemented.
How should a team handle obsolete templates?
Mark the investigation and proposed retirement in the inventory. Let the responsible owner follow the authorized change process after checking callers and active workflows. Do not delete templates as an incidental design cleanup.