Central Question
If Notifications can already do all of this, what problem is Custom Email intended to solve?
We do not assume that newer automatically means better. We compare architecture, capabilities, recipients, permissions, content, and delivery behavior.
Part 1
Start With the Four Email Choices
By Lesson 4, Notification has already proven capable. Custom Email now has to justify its existence as something more than another button.
Custom Email
Modern, richer email construction and delivery.
Notification
Legacy event-driven automatic email.
Subscription
Scheduled report delivery.
Reminder
Date-relative automatic email.
Mental Model
Laboratory method
Observe the UI
Compare
Form a Model
Change One Variable
Test and Observe
Refine the Model
Part 2
Inspect the Custom Email Architecture
The editor exposes Basics, Send options, Settings, and Compose email. This immediately suggests a broader system than a simple legacy message editor.
Basics
Name and description identify the automation.
Send options
Start from a record event or a recurring schedule. Event mode also exposes record events, fields, conditions, and all/any logic.
Settings
Bulk-change behavior and recipient permissions/data access are explicit.
Compose email
From, To, Subject, rich content, Add Elements, and Source editing.
Review 3A–3B
Decision Framework
Why Choose Custom Email?
The important distinction is not merely that Custom Email looks newer. It consolidates use cases formerly split across legacy email types and extends them with richer composition, delivery, permission, and content capabilities.
Prefer Custom Email when...
- You are building a new automatic email.
- You need record-event or recurring scheduled delivery.
- You want richer composition, CC/BCC, forms, reports, charts, or attachments.
- You need dynamic recipients from User fields.
- You need explicit recipient-permission behavior.
- You need deliberate bulk-change delivery behavior.
- You want native Record Change elements or richer Quickbase elements.
Keep a legacy Notification when...
- An existing Notification already works correctly.
- The requirement is simple and event-driven.
- Rebuilding produces no meaningful benefit.
- Migration/testing cost exceeds the value of change.
Keep Reminder / Subscription when...
- An existing legacy automation already solves the need cleanly.
- The app depends on established behavior.
- You are maintaining a stable application rather than redesigning it.
Remember This
Modern default does not mean mandatory migration
For a new automatic-email requirement, Custom Email is usually the first mechanism worth evaluating. Existing Notifications, Reminders, and Subscriptions do not become defective simply because the newer system exists.
Ask which mechanism solves the requirement with the least unnecessary complexity while preserving the behavior the application actually needs.
Rule of Thumb
New build
Evaluate Custom Email first.
Existing simple automation
Keep it unless Custom Email solves a real limitation.
Richer communication requirement
Custom Email becomes the stronger candidate.
Parts 3–5
Dynamic Recipients Extend the Model
The Tasks table exposed static users, roles/audiences, and User-field recipients such as User in Assigned To.
Static Recipient
A specific known person.
Role / Audience
Users belonging to a selected Quickbase role or audience.
Record-Derived
A user stored in a User field on the qualifying record.
Mental Model
Assigned To becomes a recipient source
Assigned To
Field Type = User
User in Assigned To
Custom Email recipient option
Dynamic Recipient
Observed in Our Lab
Experiment 4.2 — the resulting assignee received the email
Old State
Assigned To = User A
Modify and Save
New State
Assigned To = User B
Resolve Recipient
User in Assigned To = User B
Email → User B
User B received the email. User A did not. In this reassignment experiment, the dynamic recipient was resolved from the resulting/current Assigned To value after Save.
Remember This
Current assignee and previous assignee are different requirements
“Notify the person assigned now” does not automatically mean “notify the person who was assigned before the modification.”
Parts 6–8
Custom Email Uses Its Own Source Elements
Typing legacy-style strings such as [Task Name] or [Status]into the modern Custom Email content did not automatically resolve them into record values during our experiment.
Quickbase field element
<qb-field field-id="12"></qb-field>
Native Record Change element
<qb-changes></qb-changes>
Lesson 4 Laboratory Source
<h1>Quickbase Automation Lab</h1>
<h2>Custom Email Observation</h2>
<p>
A Custom Email was generated because a qualifying Task record changed.
</p>
<hr>
<h2>Record Change</h2>
<p>
The section below is generated by Quickbase from the record-change event.
It identifies the changed record and shows the fields that were edited,
including their previous and new values.
</p>
<qb-changes></qb-changes>
<hr>
<h2>Recipient Experiment</h2>
<p>
<strong>Recipient source:</strong> User in Assigned To
</p>
<p>
This recipient is not permanently stored in the email definition as one
specific person. Quickbase determines the recipient from the User value
stored in the Task record when the Custom Email is evaluated.
</p>
<hr>
<h2>Automation Context</h2>
<table style="width:100%; border-collapse:collapse;">
<tbody>
<tr>
<td style="padding:6px;"><strong>Trigger</strong></td>
<td style="padding:6px;">Task record modified</td>
</tr>
<tr>
<td style="padding:6px;"><strong>Recipient source</strong></td>
<td style="padding:6px;">User in Assigned To</td>
</tr>
<tr>
<td style="padding:6px;"><strong>Permission mode</strong></td>
<td style="padding:6px;">Check recipient permissions</td>
</tr>
<tr>
<td style="padding:6px;"><strong>Bulk behavior</strong></td>
<td style="padding:6px;">Send a single email with all changes</td>
</tr>
</tbody>
</table>
<hr>
<h2>Open the Task</h2>
<p>
<qb-marker type="record-link"></qb-marker>
</p>
<hr>
<p>
<strong>Quickbase Automation Developer Lab</strong><br>
Lesson 4 — Custom Email
</p>Observed in Our Lab
<qb-changes> produced a structured previous/current presentation
| Field | Previous value | New value |
|---|---|---|
| Date Modified | previous timestamp | new timestamp |
| Record ID# | 17 | 17 |
| Task Name | previous value | current value |
| Assigned To | previous user | new user |
Lesson 3A taught us to reason about previous → current. Lesson 4 shows Custom Email presenting that transition through a native Record Change element.
Parts 9–14
Security Becomes Part of Email Design
Custom Email explicitly separates recipient selection from the permission policy governing delivery and data access.
Check recipient permissions
Quickbase considers recipient access when determining delivery/data visibility.
Ignore recipient permissions
Delivery can proceed even when the recipient lacks the access that otherwise blocked it.
Remember This
Selectable recipient ≠ authorized recipient
A person being selectable in a User field or recipient control does not necessarily mean Quickbase will deliver application data to that person under the current permission policy.
| Test | Recipient Configuration | Tasks Access | Observed Result |
|---|---|---|---|
| 1 | All users with access to this table | Participant yes / Viewer no | Participant received; Viewer did not |
| 2 | Viewer role | No Tasks access | No email |
| 3 | User in Assigned To | Assigned user lacked Tasks access | No email |
| 4 | Specific test user | User lacked Tasks access | No email |
Observed in Our Lab
Experiment 4.4 — changing only the permission mode changed the result
Check recipient permissions
User without Tasks access → NO EMAIL
Ignore recipient permissions
Same user, same missing Tasks access → EMAIL RECEIVED
Security Principle
Ignore recipient permissions is a data-governance decision
Recipient selection
Who should receive the message?
Permission policy
Whose Quickbase access governs what may be communicated?
Parts 15–16
Custom Email Is Broader Than a Prettier Notification
By this point, the opening question has an evidence-based answer: Custom Email brings trigger logic, recipient logic, permission policy, bulk behavior, composition, and delivery into one modern email definition.
Trigger Logic
Record event or schedule.
Recipient Logic
Static, role, audience, or record-derived.
Content Design
Rich content and native QB elements.
Permissions
Explicit recipient-data access policy.
Bulk Policy
How multi-record changes are handled.
Delivery
One system coordinates the final communication.
| Capability | Notification | Custom Email |
|---|---|---|
| Record events | ✓ | ✓ |
| Watched fields | ✓ | ✓ |
| After-change conditions | ✓ | ✓ |
| Boolean evaluation | ✓ | ✓ |
| Previous/current evidence | Manual techniques explored | Native Record Change element |
| Dynamic User-field recipient | Available concepts differ | ✓ tested |
| Explicit recipient permission policy | Different / legacy model | ✓ |
| Ignore recipient permissions | Different configuration model | ✓ tested |
| Bulk delivery strategy | Operation scope | ✓ |
| Recurring schedule | Separate legacy concepts | Exposed directly |
| Modern rich composer | Legacy editor | ✓ |
| Source-mode QB elements | Different formatting model | ✓ |
| Charts / rich embedded content | Legacy limitations | Stronger modern candidate |
| File attachments | Legacy limitations | Richer attachment scenarios |
Part 17
The Lesson 4 Mental Model
Lessons 3A–3B built the upper half. Lesson 4 extends the funnel into recipient resolution, permission policy, bulk delivery, and content generation.
Mental Model
Custom Email evaluation and delivery
Record / Schedule
Send Option
Event
Field Criteria
Boolean Conditions
Recipient Resolution
Permission Policy
Bulk Delivery Policy
Content Generation
Part 18
What We Actually Established
Custom Email shares substantial event and Boolean logic with Notifications.
Custom Email also exposes a recurring-schedule send model.
User fields such as Assigned To can dynamically determine recipients.
The reassignment experiment resolved the recipient from the resulting/current Assigned To value.
The previous assignee did not receive the email merely because they were the previous User-field value.
Custom Email Source mode uses Quickbase-specific elements rather than automatically resolving typed legacy-style field strings.
<qb-changes> produced a native structured previous/current change presentation.
A user can be a valid User-field value while lacking the access required to receive the email under permission checking.
Roles and specifically selected users did not circumvent recipient permission checking in our tests.
Ignore recipient permissions materially changed delivery for a user without Tasks access.
Recipient selection and permission policy are separate layers of Custom Email design.
Lesson 4 Final Principle
Custom Email Is a Communication System, Not Merely a Better-Looking Notification
It reuses familiar trigger and condition logic, but extends automation into richer recipient resolution, explicit permission policy, bulk behavior, modern composition, recurring schedules, and richer content.
For new automatic-email designs, Custom Email is generally the first mechanism worth evaluating. Existing legacy emails should be rebuilt only when doing so solves an actual limitation or produces a meaningful design benefit.