Quickbase Explained

Central Question

What does Quickbase actually mean when a record is modified, and how can an automation determine which changes matter?

Lesson 1 established the automation landscape. Lesson 2 is the first true laboratory lesson.

Instead of beginning with a Notification configuration screen, we begin with the record itself. We observe what Quickbase does before Save, after Save, and when an automation is finally added as another observational instrument.

Part 1

Begin With a Record, Not an Automation

Our experimental object is an existing record in the Tasks table. Automation will eventually react to something happening to this record, but first we need to understand the record event itself.

Experimental Record

Task #17

Task Name: Prepare Monthly Report
Due Date: blank
Status: Open
Assigned To: You

Mental Model

Table → Record → Fields

Tasks Table

The collection of Task records.

Task #17

One persisted record.

Task Name

Due Date

Status

Assigned To

Part 2

Introduce the Record Lifecycle

At the conceptual level, a record has three elementary lifecycle events. We acknowledge all three, but Lesson 2 concentrates on Modify because modification gives us the richest foundation for later automation.

Add

A record did not exist.

Then it did.

Modify

A record already existed and its persisted data changed.

This is today's laboratory focus.

Delete

An existing record was removed.

We deliberately defer this event for another lesson.

Parts 3–6

Observe the Record Before Saving

Open Task #17 in the normal Quickbase record interface, enter Edit mode, and establish the persisted baseline before touching automation.

Baseline

Persisted Status = Open

The screenshot at this point should orient the student to View and Edit controls without turning the course into a click-by-click Quickbase user manual.

Experiment

Change one field before Save

Question

Can Quickbase recognize a proposed field difference before the record has been persisted?

Observed

Changing Status from Open to On Hold caused Quickbase to show a Reset control for Status before Save.

PERSISTED VALUE
Status = Open

CURRENT EDIT VALUE
Status = On Hold

Experiment

Change two fields before Save

Question

Does Quickbase merely know that the whole form changed, or can it identify individual changed fields?

Observed

After Due Date changed from blank to 08-30-2026, separate Reset controls appeared for Due Date and Status, but not for untouched fields.

Task Name      unchanged
Due Date       changed
Status         changed
Assigned To    unchanged

Remember This

An unsaved form change is not the same thing as a saved record modification

Quickbase can recognize that the current edit value differs from the persisted value before Save. That observation alone does not prove that the persisted record has been modified.

Experiment

Reset one changed field

Question

Is Reset a form-wide undo, or is it specific to the field whose value differs?

Observed

Resetting Due Date returned that field to its persisted value while the unsaved Status change remained.

Evidence

Due Date

08-30-2026 → blank

Evidence

Status

On Hold remains the unsaved edit value.

This confirms that Quickbase tracks unsaved differences independently at the field level and that Reset is field-specific.

Parts 7–8

Save the Record and Use System Fields as Instruments

Restore the Due Date experimental value, leave Status changed, and Save once. Then expose Quickbase-created system fields on the form. These fields become our first laboratory instruments.

Saved Changes

Due Date

blank → 08-30-2026

Status

On Hold → Open

System Fields Observed

Record ID#: 17
Date Created: 08-24-2026 11:18 AM
Date Modified: 08-24-2026 11:59 AM
Record Owner: Ross, Darian
Last Modified By: Ross, Darian

Record ID#

Record #17 remained Record #17 before and after modification. The existing record persisted through the change.

Created vs. Modified

Date Created and Date Modified expose different points in the record lifecycle. Creation and modification are not the same event.

Owner vs. Modifier

Record Owner answers who owns the record. Last Modified By answers who most recently changed it. Identical values do not make the meanings identical.

Part 9

Run a Control Experiment: Save Without Changing Anything

Establish a clean Date Modified baseline, enter Edit mode, change nothing, and click Save.

Experiment

No-change Save

Question

Does merely entering Edit mode and pressing Save create a record modification?

Prediction

If Save itself is the modification event, Date Modified should advance even when no persisted data changes.

Observed

Date Modified remained unchanged.

Mental Model

What the control experiment established

EDIT MODE

≠

MODIFICATION

SAVE BUTTON

≠

AUTOMATICALLY A MODIFICATION

Remember This

State the finding at the level actually tested

Based specifically on the manual form-edit behavior we tested, clicking Save without changing persisted field data did not produce an observed record modification.

Part 10

Reach an Observational Limit

We changed Status and Due Date during one Edit session and clicked Save once. The finished record gives us one Date Modified timestamp—but it cannot tell us how Quickbase conceptualized the event internally.

Unknown

Did Quickbase process two modifications, or one record modification containing two changed fields?

The current instrument cannot answer the question. That is not a failure. It tells us exactly what kind of additional observation we need.

Remember This

Do not convert reasonable assumptions into facts

If the current experiment cannot demonstrate something, mark it unknown and build a better experiment.

Parts 11–13

Use a Notification as an Observer

In the Tasks table settings, the current Quickbase email surface presents four mechanisms. For this experiment, Notification is useful because we are studying record-change events.

Custom email

Notification

Subscription

Reminder

Read the UI as evidence

Evidence

What happened?

a Task is modified

Evidence

What participated?

Any field changes, or any of the following fields change

Evidence

What is true afterward?

Conditions are true after the change

Mental Model

The event model exposed by Notification

Record Event

A Task is modified.

Which Fields Changed?

Any field, or only selected fields.

What Is True Afterward?

Evaluate resulting record conditions.

Laboratory Notification

LAB — Any Task Modification

Notify

When

a Task is modified

AND

Any field changes

Operations are limited to single Task records because this experiment is designed to observe one record modification at a time.

Part 14

Give the Observer Before-and-After Instrumentation

We intentionally borrow a little Quickbase message syntax early. The goal is not to memorize markers yet. The goal is to make the event visible in the inbox.

QUICKBASE AUTOMATION LAB

Record: %recLabel%
Record ID: %recID%

Modified By:
[Last Modified By]

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]

Open Record:
%recLink%

Remember This

Learn by doing before learning every marker

We are borrowing message syntax because it improves our experiment. For now, observe what it produces. Email composition, marker families, and message-context rules deserve their own deliberate lessons later.

Parts 15–19

Test the Notification Against the Record Experiments

The Notification now becomes a second independent instrument. We can compare what the record metadata says with whether the observer sends an email.

Experiment

Notification control test

Question

If we enter Edit mode, change nothing, and Save, does a modification Notification fire?

Observed

No email was sent.

Mental Model

Two instruments agree

No Field Change

Evidence

Date Modified

Unchanged

Evidence

Notification

Not sent

Experiment

One changed field

Question

What happens when one field is changed and the record is saved once?

Observed

One saved record modification produced one Notification.

1 saved record modification
        ↓
1 Notification

The email now functions as an experimental report. A Status transition can appear as:

STATUS

Before: On Hold
After:  Open

Experiment

Two changed fields in one Save

Question

Does one Save containing two changed fields produce one record-level Notification or separate emails per field?

Observed

Two changed fields in one Edit session produced one saved Task modification and one Notification.

Mental Model

The record modification is the event

Task Modified

Evidence

Field participation

Status changed

Evidence

Field participation

Due Date changed

One Notification

At the level exposed by this single-record Notification test, the modification is the record event; individual changed fields participate in that event.

Experiment

Reset before Save

Question

What happens if a field differs temporarily, is Reset to its persisted value, and then the form is saved?

Observed

Zero persisted changes and zero Notifications.

UNSAVED FIELD DIFFERENCE
       │
       ├── Quickbase recognizes it
       ├── Reset is available
       │
       ▼
RESTORED BEFORE SAVE
       │
       ▼
NO PERSISTED MODIFICATION
       │
       ▼
NO NOTIFICATION

Diagnostic Email

Old and current references describe the same event from two sides

Evidence

Changed field

STATUS
Before: On Hold
After:  Open

Old and current values differ, so the field changed.

Evidence

Unchanged field

DUE DATE
Before: 08-28-2026
After:  08-28-2026

Old and current values are equal, so the field remained the same during that modification.

The [old.Field] form does not mean “show this only if the field changed.” It gives us the value from before the modification. The ordinary field reference gives us the resulting/current value.

Part 20

Make the Observer Selective

Change the Notification from Any field changes to Any of the following fields change, and select only Status. Do not add an after-change condition yet.

Experiment

Task Name changes

Observed

The record was modified and Date Modified advanced, but Status did not participate, so no email was sent.

Record modified        YES
Date Modified advances YES
Status changed         NO
Email                  NO

Experiment

Status changes

Observed

The record was modified, Status participated in the modification, and the Notification sent an email.

Record modified        YES
Status changed         YES
Email                  YES

Remember This

Automation relevance is not the same thing as event existence

A record can genuinely be modified without a particular automation considering that modification relevant. The automation's criteria determine whether the event matters to that automation.

Parts 21–22

Introduce Resulting State

Keep the requirement that Status must change, then add a condition evaluated after the change:

After-change condition

Status is equal to the value Complete

Mental Model

Field participation + resulting state

Task Modified

Did Status Change?

After the Change, Is Status Complete?

Email

Experiment

On Hold → Open

Observed

No email

Status changed?       YES
Status = Complete?    NO

EMAIL: NO

Experiment

Open / On Hold → Complete

Observed

Email sent

Status changed?       YES
Status = Complete?    YES

EMAIL: YES

Experiment

Task Name changes

Observed

No email

Task modified?        YES
Status changed?       NO

EMAIL: NO

Even if Status already happens to be Complete, the field-change requirement still matters.

Part 23

The Puzzle Pieces Lock Together

These statements may sound similar in casual conversation, but Quickbase gives us mechanisms for distinguishing them.

A Task was modified.

Status changed.

Status is Complete.

Status changed and is now Complete.

Mental Model

The Lesson 2 event model

Record

Modification

Which Fields Changed?

Did Status Participate?

What Is True After?

Status = Complete?

Action: Email

Evidence

What was true before?

[old.Status]

Evidence

What is true after?

[Status]

Part 24

What We Deliberately Do Not Teach Yet

The experiment exposed more Quickbase syntax than this lesson needs. We use only what helps us observe the behavior and defer the wider marker system for later.

Markers encountered

%appName%
%appLink%
%dbName%
%dbid%
%recLabel%
%recID%
%recLink%
%recData%
%summaryView%
%RepeatOn%
%RepeatOff%

Field references used now

[Field Name]

[old.Field Name]

We use these immediately because they make the experiment observable. Broader capabilities and message-context rules are deferred.

Remember This

Unknown syntax is an invitation to investigate

When a Quickbase feature exposes syntax you do not recognize, consult Quickbase Help, experiment in the lab, observe the output, and refine your understanding. That is developer behavior.

Part 25

Deliberately Deferred Questions

Today's experiments opened several doors. We leave them open on purpose rather than cramming unrelated complexity into Lesson 2.

What happens when records are added?

What happens when records are deleted?

How do multiple-record operations differ?

What happens with Grid Edit?

What happens with imports?

How are Recipient and Open notifications different?

How do permissions affect what recipients see?

How does Assigned To become a dynamic recipient?

What exactly are all the %markers%?

How does Custom Email differ from Notification?

What happens when automation modifies another record?

Can automation cause another automation?

How do Pipelines represent previous/current values?

We also deliberately avoid generalizing today's single-record form-edit findings to bulk operations. Multiple-record notifications can behave differently and deserve their own experiments.

Student Outcome

What You Should Understand Before Moving On

A Quickbase record modification is more than clicking Edit or Save.

During editing, Quickbase can recognize individual fields whose proposed values differ from their persisted values. If those differences are removed before Save, our experiments produced no persisted modification and no modification Notification.

When changed data is saved, the existing record persists under the same Record ID while Quickbase updates its modification metadata. A single saved modification can contain changes to multiple fields.

Automation can then evaluate that event at several levels: Did the record change? Which fields changed? What conditions are true after the change?

Finally, the resulting email can expose values from before and after the modification, allowing us to observe the event itself.

Mental Model

Compact Lesson 2 model

Record

Event

Changed Fields

Resulting State

Automation Decision

Action

Evidence

Before Value

[old.Status]

Evidence

After Value

[Status]

Lesson 2 Complete

We Now Have an Event Model

We began with a record, observed unsaved differences, established what persisted modification looks like, and then used a Notification as a second instrument to distinguish the record event from the fields participating in that event and the state that exists afterward.

The next lesson should begin only after the next laboratory question has been investigated. We do not manufacture future theory in advance.

← Review Lesson 1 View All Lessons