If you've ever spent time diagnosing a record-based notification that refuses to fire — no email, no outbox record, no error — and event-based notifications on the same instance work just fine, this one's for you. This is a walkthrough of a real diagnostic I went through recently. The root cause was non-obvious, logged nothing, and had a secondary trap hiding inside it that I'll cover at the end.

The Symptom

Record-based notifications (Insert / Update triggers) were not generating any records in sys_email. Event-based notifications on the same instance were working fine.  No outbound email records. No errors. Nothing.

The Diagnostic Path

Here's what I worked through before finding the root cause.

 

Step 1 — Check SMTP

First stop: glide.email.smtp.active. This controls whether emails are actually dispatched. If it's false, emails don't leave the instance — but they should still appear in sys_email as Ready records. So SMTP being off explains no delivery, but not the absence of outbox records entirely.

 

Step 2 — Check the Email Subsystem

glide.email.active controls the entire email pipeline including record generation. If this is false, nothing gets written to sys_email at all. In this case it was enabled.

 

Step 3 — Verify the Notification Itself

• Active flag — confirmed active
• Trigger type — set to Inserted or Updated
• Test Notification button — forced a test run

 

Step 4 — Look for Business Rules Suppressing It

Record-based notifications fire in-transaction. If something kills the transaction before notification processing runs, nothing gets generated. The key thing to look for:

current.setWorkflow(false); // This suppresses notification processing

Checked every BR on the table — nothing was killing the workflow.

 

Step 5 — Check the Conditions Field on the Notification

This is where the problem was.

The Root Cause — Null Condition

The notification had been cloned from another notification in a different scope, likely referencing a different table. When copied, the condition field didn't carry across a valid expression — it carried across a null value.

This is not the same as an empty condition.

An empty condition fires for all matching records. A null condition can't be evaluated — the platform treats it as a failure and silently suppresses the notification. No error is raised. Nothing is logged. No sys_email record is generated.

The fix was straightforward — clear the null from the condition field and either leave it blank or rebuild the correct condition for the table and context.

After clearing it, notifications started generating sys_email records immediately.

Why Event-Based Notifications Were Unaffected

Event-based notifications follow a different evaluation path. They're queued via the event system rather than firing in-transaction against the record. The null condition in the record-based trigger didn't affect them.

This is actually what made the pattern diagnosable — if everything had been broken, SMTP or glide.email.active would have been the obvious culprit. Event-based working while record-based silently failed pointed clearly at something in the trigger/condition evaluation pipeline.

The Hidden Trap — UI Hides It But Doesn't Clear It

When you change Send When on a notification from Insert/Update to Triggered or Event , the Conditions fields are hidden in the UI. That makes sense — conditions aren't relevant for those trigger types.

But the hide is UI only. The underlying field value is not cleared.

What this means in practice:

• Developer clones a notification, inherits a null condition
• Sets Send When to Event — conditions are hidden, null is invisible
• Later, they or someone else switches it back to Insert/Update
• The null reappears, notification silently fails, no obvious reason why

The trap resets itself silently.

Defensive Checklist When Cloning Notifications

• Always inspect the Conditions field directly — regardless of what Send When is set to
• If conditions are hidden by the UI, temporarily switch Send When to Insert/Update to make them visible, verify and clear if needed, then switch back
• After cloning from a different scope or table, treat the condition field as untrusted — rebuild it from scratch for the new context
• Verify in sys_email after any notification change — if a test trigger doesn't generate an outbox record, the problem is upstream of email

Summary

What to check

|

Why

|
|

glide.email.smtp.active

|

Controls SMTP dispatch — off means no delivery but outbox records should still exist

|
|

glide.email.active

|

Controls the whole pipeline — off means no sys_email records at all

|
|

Conditions field on the notification

|

Null condition = silent failure, no outbox record, no error

|
|

current.setWorkflow(false) in BRs

|

Kills in-transaction notification processing

|
|

Send When field hiding conditions

|

UI hide only — null value persists in DB even when field is hidden

|

 The platform gives you no signal when a null condition suppresses a notification. No log entry, no outbox record, no error. It just doesn't fire. Hopefully this saves someone the diagnostic time.