What fields can I match in a rule?

Any field in your event payload JSON. Common matches: event type, plan, locale, tenant ID, user role. You define the payload schema.

What happens when no rule matches?

The event is logged as unmatched. No email is sent. You can see all unmatched events in the dashboard and add rules to handle them.

Can one event trigger multiple rules?

Yes. If multiple rules match the same event, each matching rule fires its template. Useful for sending to multiple recipients or for audit trails.

Can rules route to different providers?

Yes. A rule can specify which provider to use. Useful for routing a specific tenant to their own SMTP server.

The else.events differentiator

Route emails by rules, not by code

Define conditions in the dashboard. else.events evaluates them against every incoming event and routes to the right template — no if/else in your codebase.

Build your first rule See event-driven email

Without a rule engine, routing logic ends up in your app

Conditional logic pollutes your services

If plan is Free send this template, else send that one — repeated across every email-sending function.

Locale routing requires custom middleware

Selecting the right language template from a user locale is custom code every team writes from scratch.

Multi-tenant routing is fragile

Sending different branded templates per tenant means per-tenant switch statements or dynamic template lookups.

Rules are invisible in code

Business logic like "send a Pro upgrade CTA only to Free users" is buried in application code, invisible to product managers.

A first-class rule engine — visible, manageable, no code required

Rules are a core concept in else.events, not an afterthought. Every event is evaluated against your rules before a template is selected.

Match on any payload field

Event type, plan tier, locale, tenant ID, user role — match on any JSON field in your event payload.

Multiple conditions per rule

Combine AND conditions. "Event = trial.ending_soon AND plan = Free AND locale = de" selects the German free-plan template.

Rules visible to product teams

Rules are configured in the dashboard. Non-developers can see and understand routing logic without reading code.

Provider routing via rules

Route to Postmark for transactional, to SMTP for a specific tenant, or fall back on delivery failure — all in rules.

// incoming event

Rules evaluate against your event payload

{
  "type": "trial.ending_soon",
  "locale": "de",
  "user": { "email": "user@example.com", "name": "Maria" },
  "data": {
    "plan": "Free",
    "days_remaining": 3,
    "upgrade_url": "https://app.example.com/upgrade"
  }
}

A rule matching type = trial.ending_soon AND plan = Free AND locale = de selects the German free-plan trial reminder template. No code change in your app.

Frequently asked questions

What fields can I match in a rule?: Any field in your event payload JSON. Common matches: event type, plan, locale, tenant ID, user role. You define the payload schema.
What happens when no rule matches?: The event is logged as unmatched. No email is sent. You can see all unmatched events in the dashboard and add rules to handle them.
Can one event trigger multiple rules?: Yes. If multiple rules match the same event, each matching rule fires its template. Useful for sending to multiple recipients or for audit trails.
Can rules route to different providers?: Yes. A rule can specify which provider to use. Useful for routing a specific tenant to their own SMTP server.

Routing logic out of your codebase

Define your first rule in the dashboard. No code change in your app required.

Free during public beta
Rules visible to the whole team
No if/else in your app