Central Question
When something happens to a Quickbase record, what exactly does a Notification evaluate before deciding that the event qualifies?
The controls inside a Notification editor can look like one long configuration form. Our experiments show that they actually represent several different questions.
The student should finish this lesson able to separate what happened, which fields participated, what values existed before, what values exist afterward, and which resulting-state conditions must hold.
Part 1
Begin With the Lesson 2 Laboratory
We do not create another artificial example. The same Tasks table and diagnostic Notification now become more sophisticated laboratory instruments.
Working fields
- Task Name
- Status
- Due Date
- Assigned To
Diagnostic message
The before/after email from Lesson 2 is no longer merely a demonstration. It is how we inspect the state transition that Quickbase exposed.
TASK NAME
Before: [old.Task Name]
After: [Task Name]
STATUS
Before: [old.Status]
After: [Status]
DUE DATE
Before: [old.Due Date]
After: [Due Date]
ASSIGNED TO
Before: [old.Assigned To]
After: [Assigned To]Remember This
The instrumentation has evolved
In Lesson 2, the message taught us that old and current values could be shown. In Lesson 3A, those values become evidence for understanding what Quickbase evaluated.
Part 2
Previous State and Current State
Quickbase exposes a previous value through old. field references and a current/resulting value through the ordinary field reference.
Previous value
[old.Status]Current / resulting value
[Status]Lab Discovery
A previous value can exist even when the field did not change
STATUS
Before: Open
After: OpenThe existence of [old.Status] does not prove that Status changed. It only asks Quickbase for the previous value of Status.
Mental Model
Conceptual record-state transition
Previous State
Task Name: August Report
Status: Open
Due Date: 09/01
Assigned To: Darian
Resulting State
Task Name: September Report
Status: Open
Due Date: 09/01
Assigned To: Darian
Remember This
Do not invent undocumented internals
We should not claim that Quickbase literally “copies the entire form” or creates an internal object named old. What we can safely teach is that Quickbase exposes previous and current field values that allow us to reason about state transitions.
Part 3
Empty Is Not Nonexistent
An Add experiment exposed a subtle distinction that becomes important whenever we reason about previous state.
Lab Discovery
Blank previous value and missing previous record are different circumstances
Existing record, blank field
Before: emptyBrand-new record
Before: nonexistentTASK NAME
Before: nonexistent
After: Collecting Monthly Dues
DUE DATE
Before: nonexistent
After: emptyempty
The record state exists, but that field has no value.
nonexistent
There was no previous record state from which that field could have a previous value.
Mental Model
Modify vs. Add
Modify existing record
The record exists. A field may contain a value or may be empty.
Add new record
The previous record does not exist, so the previous field state is nonexistent.
Parts 4–8
Record Events Define Eligibility
The first Notification gate asks what happened to the record. Quickbase exposes record-event choices built from Added, Modified, and Deleted.
Modified
The record already existed and persisted data changed.
Added
A new record came into existence.
Deleted
An existing record was removed.
Experiment
3A.1 — Modified
Observed
Modify existing Task → EMAIL. Add new Task → NO EMAIL.
Notification when:
a Task is modified
Modify existing Task → EMAIL
Add new Task → NO EMAILA Notification configured for modification does not treat record creation as modification.
Experiment
3A.2 — Added
Observed
Modify existing Task → NO EMAIL. Add new Task → EMAIL.
Notification when:
a Task is added
Modify existing Task → NO EMAIL
Add new Task → EMAILReversing exactly one configuration choice tested the distinction in both directions rather than assuming the events were different.
Experiment
3A.3 — Modified OR Added
Observed
MODIFY → EMAIL. ADD → EMAIL. DELETE → NO EMAIL.
a Task is modified or added
MODIFY → EMAIL
ADD → EMAIL
DELETE → NO EMAILMental Model
Event eligibility
Modify
Passes when modification is selected.
Add
Passes when addition is selected.
Delete
Fails when delete is not selected.
Remember This
Event criterion answers only one question
The record-event choice tells us what happened to the record. It does not tell us which field changed, what Status is now, or what Due Date used to be.
Parts 9–14
Field-Change Criteria Ask What Participated
Once the event is a modification, Quickbase lets us choose whether any changed field is acceptable or whether the modification must involve one of a selected set of fields.
Any field changes
The modification is not restricted to a particular selected field. Task Name, Status, Due Date, or another changed field can potentially qualify.
Any of the following fields change
Quickbase exposes individual field checkboxes and the modification must involve at least one of the selected fields.
Fields selected in the laboratory
Experiment
3A.4 — Selected Fields
Observed
Only modifications containing at least one selected changed field qualified.
| Modification | Observed |
|---|---|
| Task Name only | NO EMAIL |
| Status only | |
| Due Date only | |
| Status + Due Date | |
| Task Name + Due Date |
Notification watches:
StatusChanged OR DueDateChanged
TaskNameChanged = TRUE
DueDateChanged = TRUE
FALSE OR TRUE
↓
TRUEAn unselected field changing does not disqualify the modification. In the Task Name + Due Date test, Task Name was irrelevant to this particular criterion; Due Date was sufficient.
Lab Discovery
One Save with multiple changed fields produced one Notification
RECORD MODIFICATION
↓
Inspect relevant changed fields
↓
Does modification satisfy criteria?
↓
ONE qualifying Notification eventThis reinforces the Lesson 2 model: the saved record modification is the event, and several changed fields can participate in that single event.
Lab Discovery
Restricted-field mode with zero selected fields is not the same as Any field changes
SELECTED-FIELD MODE
↓
Selected fields = none
↓
No selected changed field
can satisfy the criterion
↓
NO QUALIFYING NOTIFICATIONThis accidental edge case became a valuable experiment. Selecting the restricted-field mode but checking no fields produced no qualifying Notification.
Parts 15–17
Field Changed Is Not the Same as Field Has a Value
This is the central distinction of Lesson 3A. A field-change criterion and a resulting-state condition answer different questions.
Did Status change?
This asks whether Status participated in the modification.
Is Status Complete now?
This asks whether the resulting record state satisfies a value condition.
Quickbase wording worth preserving
AND when the following conditions are true after the change
That wording tells us this section is describing the resulting state, not merely which fields changed.
Experiment
The experiment that proved it
Observed
The Notification could qualify with Status = Complete even when Status itself did not change.
STATUS
Before: Complete
After: Complete
DUE DATE
Before: 09-30-2026
After: 11-10-2026Did Status change?
FALSE
Is Status Complete now?
TRUE
A condition such as Status = Complete does not inherently mean Status changed to Complete. Those statements can overlap, but they are not equivalent.
Part 18
Three Questions the Notification UI Is Really Asking
At this point the configuration editor stops looking like one miscellaneous form and starts looking like a logical evaluation system.
1. What happened?
Record event
Added / Modified / Deleted
2. What participated?
Field-change criterion
Any field or selected fields
3. What is true afterward?
Resulting-state conditions
Status = Complete, Due Date ≥ boundary, etc.
Part 19
The Three-Layer Conceptual Model
This is the centerpiece of Lesson 3A and the model we will carry into Lesson 3B.
Mental Model
Notification qualification funnel
Record Event
Did the configured kind of event happen?
Field-Change Criterion
Did a relevant field participate in the modification?
After-Change Conditions
Does the resulting record state satisfy the required conditions?
Qualifies
The configured Notification criteria are satisfied.
Remember This
This is a reasoning model, not an undocumented execution algorithm
The funnel helps us decompose Notification qualification. It is not a claim about Quickbase's private internal implementation or exact execution order.
Part 20
Single-Record and Multiple-Record Behavior Are Not Identical
During testing we unexpectedly encountered a multiple-record message rather than the custom single-record diagnostic format.
Lab Discovery
Quickbase exposed a separate multiple-record presentation
Records modified
Multiple records in Automation: Tasks were modified.That observation is important enough to record, but not important enough to derail this lesson into a bulk-operation investigation.
Remember This
Observe here; investigate later
We deliberately do not generalize single-record findings to Grid Edit, imports, or other bulk operations. They deserve dedicated experiments.
Part 21
Audit Concepts Reinforce the State-Transition Model
Additional Quickbase Help material about auditing uses the same broad concepts of previous and current values for updated data.
Mental Model
A recurring Quickbase concept
Previous State
Record Event
Current State
This does not prove that Notifications and audit logs share an identical internal implementation. It does show that Quickbase repeatedly exposes state-transition concepts across different features.
Part 22
A Breadcrumb Toward Pipelines
The syntax will change later, but the conceptual question will survive.
Notifications today
[old.Status]
[Status]Pipelines later
Previous-value and current-value concepts return again, even though Pipelines use different syntax and tooling.
Remember This
Syntax changes. The question survives.
What was true before, and what is true now? That question is foundational enough to survive the transition from Notifications into later automation tools.
Final Principle
What a Notification Can Distinguish
A Notification does not merely react to “something changed.” It can distinguish the kind of record event, which fields participated in a modification, and conditions that describe the resulting record state.
FIELD CHANGED
≠
FIELD VALUE AFTER CHANGE
Curriculum Discipline
What We Deliberately Do Not Teach Yet
Lesson 3A stays focused on mechanics of qualification. We do not allow every discovery to become a new rabbit hole.
Sophisticated email formatting
Custom Email
Recipients and permission architecture
Bulk-operation internals
Pipelines
Jinja syntax
$prev implementation details
Complex date formulas
Every Notification option
Student Outcome
What You Should Understand Before Moving to 3B
Previous value does not mean the field changed.
empty and nonexistent describe different previous-state situations.
Added, Modified, and Deleted are separate record events.
Event criteria define which kinds of activity are eligible.
Selected-field mode behaves like a logical OR across selected changed fields.
An unselected field can change without disqualifying an otherwise qualifying modification.
Zero selected fields is not equivalent to Any field changes.
A field-change test and a resulting-state test are different questions.
Single-record and multiple-record email behavior should not be casually conflated.
The Notification funnel is a conceptual model, not an undocumented internal algorithm.
Next: Lesson 3B
Notification Logic: Conditions, Boolean Evaluation & Grouping
Lesson 3A answered what Quickbase can evaluate. Lesson 3B asks how those facts combine into logical expressions.
We will move from record events, field participation, and resulting state into AND, OR, ALL, ANY, truth tables, and eventually grouped criteria—without pretending untested grouping behavior is already proven.