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

What you'll learn

  • The two relations that connect an event to the rest of your spec: event ↔ controller and event ↔ email.
  • The "feature → event → email" chain and why having it in one workspace matters.
  • How to wire these links from either side, and the brand rule that constrains them.

Why an event isn't an island

A named analytics event on its own is just a label. Its value comes from what it connects to:

  • Behind it sits the code that emits it — in m18t's model, a Product Manager controller on some feature.
  • In front of it sits the consequence — often a transactional email that should fire when the event happens.

Read those together and you get a chain that's normally scattered across three tools and nobody's head:

Feature → Event → Email. A feature has a controller that does something → that emits an event → that event triggers an email.

For example: the Authentication feature has a register controller → it emits the auth.user.registered event → which triggers the auth.user.confirm 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.

The two relations

Event ↔ Controller

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 same brand as the event — m18t filters the picker strictly, so you can't accidentally wire one brand's event to another brand's code.

Event ↔ Email

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, same-brand only. 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.

How to wire it from the event

  1. Open an event in the Events Manager (/studio/martech/events/[id]).
  2. In the Automation section, use Triggered by Controllers to select the controllers that fire this event. The list is searchable and shows each controller's model and request method.
  3. In the Notification Mapping section, use Linked Emails to select the emails this event should dispatch.
  4. Save. The event now carries both sets of links.

How to wire it from the email

  1. Open an email in the Email Manager (/studio/email-manager/[id]).
  2. In Triggers & Channels, use Triggering Events to select the events that should dispatch this email.
  3. Save. The email and each selected event are now linked — and the event's page will show this email under its linked emails.

You only need to do one side; the relation is the same record either way.

Variations

  • Linking an event to a product model. Beyond controllers, an event can reference the Product Manager model it concerns (e.g. the User model for auth.user.registered). That ties the event to the data entity, not just the handler.
  • Delivery channels on the email. An email also links to delivery channels (the SMTP/provider side). That's separate from the event relation — events say when to send; channels say how — but both live on the email record.
  • Reading the chain in the tables. 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.

A note on what "trigger" means today

These links are a specification 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.

FAQ

If I link an email to an event, will m18t send that email when the event fires? 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.

Why can't I see another brand's controllers or emails in the picker? 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.

Do I wire the link on the event or the email? Either. The relation is one record. Set "Linked Emails" on the event, or "Triggering Events" on the email — both produce the same connection.

What's a controller in this context? 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.

What's the difference between a triggering event and a delivery channel on an email? The event is when (the thing that should cause the send). The channel is how (the SMTP/provider path). Both are recorded on the email; they answer different questions.

What's next

Was this article helpful?