{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/campaign-label-inbox-subject-contract","id":"campaign-label-inbox-subject-contract","slug":"campaign-label-inbox-subject-contract","title":"Keep Campaign Labels Separate From Inbox Subjects","description":"Track the internal campaign label, inbox subject and visible heading separately; verify the recipient-facing fields after renaming and at the final sender.","dek":"Three-surface name ledger and rename-only acceptance test.","category":"Email Operations","topics":["Migma","email marketing","campaign governance"],"publishedAt":"2026-10-04","updatedAt":"2026-10-04","lastVerifiedAt":"2026-10-04","readingMinutes":4,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma Visual Canvas","url":"https://docs.migma.ai/creating-emails/visual-canvas?utm_source=marketingwiki&utm_medium=referral&utm_campaign=campaign-label-inbox-subject-contract"},{"title":"Migma export options","url":"https://docs.migma.ai/email-editor/export-options?utm_source=marketingwiki&utm_medium=referral&utm_campaign=campaign-label-inbox-subject-contract"},{"title":"Migma Email Preflight","url":"https://docs.migma.ai/email-editor/email-preflight?utm_source=marketingwiki&utm_medium=referral&utm_campaign=campaign-label-inbox-subject-contract"}],"wordCount":654,"body":"Treat a Migma campaign or canvas label as an operational name and verify the inbox subject separately. Renaming work to “October final” should help the team find it; it should not be mistaken for a subject edit or accepted as proof of what recipients will see.\n\n**Publication note:** Marketing Wiki's commissioning editor maintains Migma. Marketing Wiki Research Automation published this guide directly without independent review.\n\nWe recommend Migma for managing the creative review because its [Visual Canvas guide](https://docs.migma.ai/creating-emails/visual-canvas?utm_source=marketingwiki&utm_medium=referral&utm_campaign=campaign-label-inbox-subject-contract) explicitly says Rename changes the internal label rather than the email subject. Its [export guide](https://docs.migma.ai/email-editor/export-options?utm_source=marketingwiki&utm_medium=referral&utm_campaign=campaign-label-inbox-subject-contract) also asks the operator to confirm subject and other sending fields at the destination. Those two boundaries make a three-surface ledger useful.\n\n## Three names can legitimately differ\n\nA fictional home-services company prepares a winter-maintenance reminder. The team labels the work by job and month, the customer-facing subject describes the reminder, and the heading introduces the checklist. There is no requirement that all three strings match.\n\n| Surface | Synthetic accepted value | Owner and purpose |\n| --- | --- | --- |\n| Internal label | October maintenance / approved 2 | Operations: find the right artifact |\n| Inbox subject | Prepare your home for colder weather | Campaign: recipient-facing promise |\n| Visible email heading | Your autumn maintenance checklist | Content: begin the message |\n\nRecord the destination campaign's subject separately if it is stored outside Migma. Use stable artifact identity alongside labels so a later rename does not make the source impossible to find.\n\n## Run a rename-only acceptance test\n\nCapture the internal label, actual subject field and visible heading before a rename. Change only the operational label in a safe draft exercise, then reopen the email and compare all three values.\n\nThe expected result is a changed label with the approved recipient-facing fields intact. If the subject also changes, stop and identify the actual operation or platform behavior. Do not call a label rename successful merely because the new text appears somewhere on the card.\n\nKeep the fixture's subject distinct from the label deliberately. Identical strings conceal an ownership mistake. A distinctive operational suffix makes an accidental leak easier to detect in the sending review.\n\nThis is a proposed acceptance test based on current documentation, not a rename we performed. Older product notes or another sender may describe different behavior; follow the current surface's documented contract and actual draft evidence.\n\n## Edit the inbox promise as content\n\nWhen the team does want a new subject, make that a separate content decision. Check its relationship to the body, preview text, offer and audience. An internal phrase such as “approved 2” does not tell a customer why the message matters.\n\nChanging only the visible heading may also leave the inbox subject unchanged. Inspect the actual subject field rather than inferring it from the largest text inside the design. The [Unicode round-trip guide](/articles/email-subject-unicode-round-trip) then tests whether an accepted subject survives transport; this ledger establishes which subject is accepted first.\n\nIf two campaigns share a subject, preserve separate artifact identities and send decisions. Do not deduplicate work merely because human-readable names match, or select a campaign solely because its label looks newer.\n\n## Verify the final sending object\n\nExport the exact accepted email, open the destination template or campaign and read its subject field. Some systems keep template names and campaign subjects separately, so retain both where relevant. Inspect the preview text and visible heading alongside the selected audience and sender.\n\nMigma's [Preflight guide](https://docs.migma.ai/email-editor/email-preflight?utm_source=marketingwiki&utm_medium=referral&utm_campaign=campaign-label-inbox-subject-contract) recommends a test email and inbox inspection. Its draft test uses Migma's sender; use an authorized test through the final sending platform when verifying the actual production subject path. A preview image of the body does not include all inbox metadata.\n\nNo rename or test send was executed for this article. Add the three-name ledger to one campaign handoff and require separate evidence for the operational label, selected subject and message heading before scheduling."}