[{"data":1,"prerenderedAt":74},["ShallowReactive",2],{"help-article-tying-events-together":3},{"data":4},{"title":5,"excerpt":6,"content":7,"help_category":8,"seo":11},"Tying Events to Emails & Code","Wire the feature to event to email chain in m18t: link an analytics event to the controller that emits it and the transactional email it should trigger","\u003Cp>\u003Cstrong>What you'll learn\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>The two relations that connect an event to the rest of your spec: event ↔ controller and event ↔ email.\u003C\u002Fli>\n\u003Cli>The "feature → event → email" chain and why having it in one workspace matters.\u003C\u002Fli>\n\u003Cli>How to wire these links from either side, and the brand rule that constrains them.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Why an event isn't an island\u003C\u002Fh2>\n\u003Cp>A named \u003Ca href=\"\u002Fhelp\u002Fthe-analytics-event-registry\">analytics event\u003C\u002Fa> on its own is just a label. Its value comes from what it connects to:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Behind it\u003C\u002Fstrong> sits the code that emits it — in m18t's model, a \u003Ca href=\"\u002Fhelp\u002Fthe-product-development-concept\">Product Manager\u003C\u002Fa> \u003Cstrong>controller\u003C\u002Fstrong> on some feature.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>In front of it\u003C\u002Fstrong> sits the consequence — often a \u003Ca href=\"\u002Fhelp\u002Fthe-email-repository\">transactional email\u003C\u002Fa> that should fire when the event happens.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Read those together and you get a chain that's normally scattered across three tools and nobody's head:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>\u003Cstrong>Feature → Event → Email.\u003C\u002Fstrong>\nA \u003Cem>feature\u003C\u002Fem> has a \u003Cem>controller\u003C\u002Fem> that does something → that emits an \u003Cem>event\u003C\u002Fem> → that event triggers an \u003Cem>email\u003C\u002Fem>.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>For example: the \u003Cstrong>Authentication\u003C\u002Fstrong> feature has a \u003Ccode>register\u003C\u002Fcode> controller → it emits the \u003Ccode>auth.user.registered\u003C\u002Fcode> event → which triggers the \u003Ccode>auth.user.confirm\u003C\u002Fcode> email. In most stacks that chain lives in a GitHub issue, an analytics doc, and a sending tool, and the three drift apart. m18t keeps all three links in one workspace so the chain is legible and stays in sync.\u003C\u002Fp>\n\u003Ch2>The two relations\u003C\u002Fh2>\n\u003Ch3>Event ↔ Controller\u003C\u002Fh3>\n\u003Cp>An event records which Product Manager controllers trigger it. This answers "where in the code does this fire?" without grepping the codebase. The controllers you can link are the ones belonging to the \u003Cstrong>same brand\u003C\u002Fstrong> as the event — m18t filters the picker strictly, so you can't accidentally wire one brand's event to another brand's code.\u003C\u002Fp>\n\u003Ch3>Event ↔ Email\u003C\u002Fh3>\n\u003Cp>An event records which emails it should dispatch. This answers "what does the user receive when this happens?" The emails you can link are, again, \u003Cstrong>same-brand only\u003C\u002Fstrong>. The link is symmetric: the email shows its triggering events, and the event shows its linked emails. You can create it from whichever side you're working in.\u003C\u002Fp>\n\u003Ch2>How to wire it from the event\u003C\u002Fh2>\n\u003Col>\n\u003Cli>Open an event in the \u003Ca href=\"\u002Fhelp\u002Fthe-analytics-event-registry\">Events Manager\u003C\u002Fa> (\u003Ccode>\u002Fstudio\u002Fmartech\u002Fevents\u002F[id]\u003C\u002Fcode>).\u003C\u002Fli>\n\u003Cli>In the \u003Cstrong>Automation\u003C\u002Fstrong> section, use \u003Cstrong>Triggered by Controllers\u003C\u002Fstrong> to select the controllers that fire this event. The list is searchable and shows each controller's model and request method.\u003C\u002Fli>\n\u003Cli>In the \u003Cstrong>Notification Mapping\u003C\u002Fstrong> section, use \u003Cstrong>Linked Emails\u003C\u002Fstrong> to select the emails this event should dispatch.\u003C\u002Fli>\n\u003Cli>Save. The event now carries both sets of links.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>How to wire it from the email\u003C\u002Fh2>\n\u003Col>\n\u003Cli>Open an email in the \u003Ca href=\"\u002Fhelp\u002Fthe-email-repository\">Email Manager\u003C\u002Fa> (\u003Ccode>\u002Fstudio\u002Femail-manager\u002F[id]\u003C\u002Fcode>).\u003C\u002Fli>\n\u003Cli>In \u003Cstrong>Triggers & Channels\u003C\u002Fstrong>, use \u003Cstrong>Triggering Events\u003C\u002Fstrong> to select the events that should dispatch this email.\u003C\u002Fli>\n\u003Cli>Save. The email and each selected event are now linked — and the event's page will show this email under its linked emails.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>You only need to do one side; the relation is the same record either way.\u003C\u002Fp>\n\u003Ch2>Variations\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Linking an event to a product model.\u003C\u002Fstrong> Beyond controllers, an event can reference the \u003Ca href=\"\u002Fhelp\u002Fthe-product-development-concept\">Product Manager\u003C\u002Fa> \u003Cstrong>model\u003C\u002Fstrong> it concerns (e.g. the \u003Ccode>User\u003C\u002Fcode> model for \u003Ccode>auth.user.registered\u003C\u002Fcode>). That ties the event to the data entity, not just the handler.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Delivery channels on the email.\u003C\u002Fstrong> An email also links to delivery channels (the SMTP\u002Fprovider side). That's separate from the event relation — events say \u003Cem>when\u003C\u002Fem> to send; channels say \u003Cem>how\u003C\u002Fem> — but both live on the email record.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Reading the chain in the tables.\u003C\u002Fstrong> The Events Manager shows an Emails count per event; the Email Manager shows an Events count per email. Hover either to see the linked records without opening them.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>A note on what "trigger" means today\u003C\u002Fh2>\n\u003Cp>These links are a \u003Cstrong>specification\u003C\u002Fstrong> of intent: "this controller emits this event, which should send this email." They document and design the chain. m18t records the relationships; the actual emission of the event and dispatch of the email happen in your application code or sending provider, which you instrument to match this spec. Treat the registry as the contract your code implements, not a running event bus. Scheduled auto-dispatch from these links is not wired today.\u003C\u002Fp>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>If I link an email to an event, will m18t send that email when the event fires?\u003C\u002Fstrong>\nNot on its own. The link specifies the intent — what \u003Cem>should\u003C\u002Fem> happen. Your application code or provider does the actual sending, instrumented to match. The registry is the contract, not a live dispatcher.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Why can't I see another brand's controllers or emails in the picker?\u003C\u002Fstrong>\nBecause events are strictly brand-scoped. The controller and email pickers show only same-brand records, so you can't wire a cross-brand link by accident.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Do I wire the link on the event or the email?\u003C\u002Fstrong>\nEither. The relation is one record. Set "Linked Emails" on the event, or "Triggering Events" on the email — both produce the same connection.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>What's a controller in this context?\u003C\u002Fstrong>\nA handler on a Product Manager model (find, create, update, etc.). Linking it to an event documents which piece of your product's logic emits that event. See \u003Ca href=\"\u002Fhelp\u002Fthe-product-development-concept\">The Product Development Concept\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>What's the difference between a triggering event and a delivery channel on an email?\u003C\u002Fstrong>\nThe event is \u003Cem>when\u003C\u002Fem> (the thing that should cause the send). The channel is \u003Cem>how\u003C\u002Fem> (the SMTP\u002Fprovider path). Both are recorded on the email; they answer different questions.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>What's next\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca href=\"\u002Fhelp\u002Fthe-analytics-event-registry\">The Analytics Event Registry\u003C\u002Fa> — design the events you're linking.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fhelp\u002Fthe-email-repository\">The Email Repository\u003C\u002Fa> — author the emails events trigger.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fhelp\u002Fthe-product-development-concept\">The Product Development Concept\u003C\u002Fa> — the controllers and models on the other end of the chain.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fhelp\u002Fattaching-artifacts\">Attaching Artifacts to PD\u003C\u002Fa> — pin the thinking behind a chain to its spec.\u003C\u002Fli>\n\u003C\u002Ful>\n",{"slug":9,"title":10},"emails-and-events","Emails & Events",{"meta_title":12,"meta_description":6,"keywords":13,"canonical_url":14,"og_title":5,"og_description":6,"og_image":15,"robots":16,"json_ld":17},"Tying Events to Emails & Code | m18t Help","event to email, feature event email chain, event controller link, linked emails, triggering events, brand-scoped relations, event spec","https:\u002F\u002Fm18t.com\u002Fhelp\u002Ftying-events-together","https:\u002F\u002Fm18t.com\u002Fog-default.png","index, follow",{"@context":18,"@graph":19},"https:\u002F\u002Fschema.org",[20,33,58],{"@type":21,"headline":5,"description":6,"articleSection":10,"inLanguage":22,"datePublished":23,"dateModified":23,"image":15,"author":24,"publisher":28,"mainEntityOfPage":31},"Article","en","2026-06-25",{"@type":25,"name":26,"url":27},"Organization","m18t","https:\u002F\u002Fm18t.com",{"@type":25,"name":26,"url":27,"logo":29},{"@type":30,"url":15},"ImageObject",{"@type":32,"@id":14},"WebPage",{"@type":34,"mainEntity":35},"FAQPage",[36,42,46,50,54],{"@type":37,"name":38,"acceptedAnswer":39},"Question","If I link an email to an event, will m18t send that email when the event fires?",{"@type":40,"text":41},"Answer","Not on its own. The link specifies the intent — what should happen. Your application code or provider does the actual sending, instrumented to match. The registry is the contract, not a live dispatcher.",{"@type":37,"name":43,"acceptedAnswer":44},"Why can't I see another brand's controllers or emails in the picker?",{"@type":40,"text":45},"Because events are strictly brand-scoped. The controller and email pickers show only same-brand records, so you can't wire a cross-brand link by accident.",{"@type":37,"name":47,"acceptedAnswer":48},"Do I wire the link on the event or the email?",{"@type":40,"text":49},"Either. The relation is one record. Set \"Linked Emails\" on the event, or \"Triggering Events\" on the email — both produce the same connection.",{"@type":37,"name":51,"acceptedAnswer":52},"What's a controller in this context?",{"@type":40,"text":53},"A handler on a Product Manager model (find, create, update, etc.). Linking it to an event documents which piece of your product's logic emits that event. See The Product Development Concept.",{"@type":37,"name":55,"acceptedAnswer":56},"What's the difference between a triggering event and a delivery channel on an email?",{"@type":40,"text":57},"The event is when (the thing that should cause the send). The channel is how (the SMTP\u002Fprovider path). Both are recorded on the email; they answer different questions.",{"@type":59,"itemListElement":60},"BreadcrumbList",[61,65,69,72],{"@type":62,"position":63,"name":64,"item":27},"ListItem",1,"Home",{"@type":62,"position":66,"name":67,"item":68},2,"Help","https:\u002F\u002Fm18t.com\u002Fhelp",{"@type":62,"position":70,"name":10,"item":71},3,"https:\u002F\u002Fm18t.com\u002Fhelp\u002Fcategories\u002Femails-and-events",{"@type":62,"position":73,"name":5,"item":14},4,1786312172357]