Lesson 10 · Understand the Machine
Build and Execute Our First Pipeline
We know what a Pipeline is. We know its working parts. Today we build one from a blank definition, turn it on, and make Quickbase do exactly what we predict.
Lesson 8
What is this machine?
Lesson 9
What are its working parts?
Lesson 10
Can we make it do exactly what we predict?
This lesson begins with a completely blank Pipeline.
Lesson 9 was our workbench. Lesson 10 is our first deliberate build. The implementation is intentionally simple because the cause-and-effect evidence matters more than complexity.
Research Method
We're Constructing a Causal Model
A green success indicator is not the goal. We want to know which mutation started the workflow, what information moved forward, which Action changed data, and what evidence supports each conclusion.
PREDICTED
What should happen?
OBSERVED
What actually happened?
CONCLUSION
What does it support?
Remember This
Change one variable whenever practical.
Build the Definition
Start Clean. Add Only What the Experiment Needs.
Create a new Pipeline named Lesson 10 - First Execution. Do not reuse the exploratory Pipeline from Lesson 9.
Exercise 10.1
Build Step 1 From Scratch
Add Quickbase → Record Updated.
Why Status?
We want an unmistakable initiating event: a Task's Status actually changed. Relationship complexity comes later, after we establish a single-table baseline.
First Execution Model
Human / User
changes Tasks.Status
Quickbase Task Mutation
aa — When Record Updated
Status is watched
We have defined the doorway into the Pipeline. We have not yet told the workflow to do anything after it enters.
Exercise 10.2
Add Update Record Before Passing Business Fields Downstream
Add Quickbase → Update Record. The new Action receives Ref ID ab. Inspect it before adding business fields under Fields for subsequent steps in aa.
Record Context
Which record are we working with?
Even without manually selected downstream business fields, Update Record already understands Record → Record Updated → Tasks.
Business Field Availability
Which selected values can later steps use?
This is a separate question. Knowing the record context does not mean every business field has been explicitly exposed downstream.
Exercise 10.2A
Controlled Data Availability Experiment
- 1. Return to aa.
- 2. Add Status under Fields for subsequent steps.
- 3. Inspect ab again.
OBSERVED
Downstream configuration changed
CONCLUSION
Availability has consequences
Trigger Fields
What changes matter for triggering?
Example: Status
Fields for subsequent steps
What business information should later steps be able to use?
Example: Status
Fields to update
What does this Action intend to change?
Example: Pipeline Results
Give the Action One Job
Make the Result Impossible to Misread
The Tasks table now contains a dedicated Text field named Pipeline Results. It begins blank so the Pipeline has a harmless place to leave visible evidence.
Exercise 10.3 Setup
Configure Our Real Output Field
ab — Update Record
- Record
- Record Updated → Tasks
- Field to update
- Pipeline Results
- Value
- The pipeline has entered this line.
Literal
Use this exact configured value.
No Jinja. No formula. No timestamp. No relationship value. No dynamic transformation. If this exact sentence appears in the Task, we know precisely where it came from.
Completed Definition
Task Status changes
aa — When Record Updated
Tasks · Watch: Status
ab — Update Record
Target: triggering Task · Field: Pipeline Results
Remember This
Configured does not mean active.
The Pipeline Designer has an Off / On toggle. A definition can be perfectly configured and still be unable to respond because it is Off.
The definition exists, but it is not currently eligible to respond to its trigger.
The Pipeline is active and eligible to respond when its triggering conditions occur.
Beginner troubleshooting check: before rebuilding anything, verify that the Pipeline is actually On.
First Execution
Predict It Before You Run It
Choose one known Task. Confirm that Pipeline Results is blank and record its current Status. Then stop editing the Pipeline and predict the complete causal chain.
Exercise 10.3
Predict the First Execution
User changes Status A → Status B
Task is actually modified
Status is a watched field
aa qualifies and execution begins
Runtime record context identifies this Task
ab targets that same Task
Pipeline Results receives the configured literal
Mutation #1
Human changes Status
This mutation initiates the Pipeline.
Mutation #2
Pipeline changes Pipeline Results
Automation produces a new Quickbase state change of its own.
Our Trigger watches Status, while our Action changes Pipeline Results. Prediction: the Pipeline's own output mutation should not qualify this particular Status-change Trigger again.
Exercise 10.4
Execute!
- 1. Turn the Pipeline On.
- 2. Open the selected Task.
- 3. Change only Status.
- 4. Save.
- 5. Inspect the Task itself before opening the Activity Log.
First Successful Execution
The machine just moved.
We caused a Quickbase record mutation, which initiated a Pipeline, which then performed a second Quickbase record mutation against the triggering record.
Pipeline Results → The pipeline has entered this line.
Actual Event Chain
User
changes Status
Tasks record mutation
Record Updated event
aa — Trigger
Pipeline execution
Record context / data available
ab — Update Record
Tasks record mutation
Pipeline Results changed
Exercise 10.5
Does Update Mean Append or Replace?
Manually place Text already exist here into Pipeline Results. Then cause another qualifying Status change.
OBSERVED
The existing value was replaced
CONCLUSION
Narrow claim
Exercise 10.6
Run a Negative Control
Change a Task field that is not being watched—such as Task Name or Due Date. Do not change Status.
PREDICTED
No execution
OBSERVED
It did not run
Status changed → execution. Non-watched Task field changed → no execution. The control gives us stronger causal evidence that the watched-field criterion mattered.
Laboratory Upgrade
Before We Add Relationships
Our first Pipeline experiments deliberately stayed inside the Tasks table. We now have a known-good single-table baseline, so we are ready to introduce one new variable: a relationship.
The Getting Started page now contains a separate Getting Ready for Lesson 10 section with the instructions for creating the Projects table, building the Projects → Tasks relationship, and adding the additional laboratory records used in the next experiments.
Complete that laboratory upgrade before continuing below.
We didn't build Projects earlier because we didn't need Projects earlier. Lesson 10 has finally given us a reason.
Known-Good Baseline
Stop Before Adding Relationships
We now have a simple Pipeline whose behavior we understand well enough to use as a baseline.
A Pipeline definition can exist while Off.
The Pipeline must be On to respond.
Status is our watched Task field.
A Status change initiated execution.
A non-watched Task-field change did not.
The Trigger carried enough record context for Update Record to target the same Task.
Fields for subsequent steps changed downstream business-field availability.
The Action wrote our configured literal.
Existing Pipeline Results text was overwritten.
The Pipeline Action created another Quickbase record mutation.
Relationship Extension
Does Pipeline Know Relationships Exist?
Our Tasks no longer live alone. The laboratory now includes a Projects → Tasks one-to-many relationship. We will extend the known-good model without turning Lesson 10 into a full relationships course.
Projects
one parent
Tasks
Related Project · Project Name/Name2 · Project Status
Exercise 10.7
Inspect Relationship Fields in the Trigger
Open the Tasks Record Updated Trigger and inspect both Fields and Fields for subsequent steps.
OBSERVED
Relationship-related fields are visible to Pipeline Designer
Selectable as a watched field does not tell us what kinds of underlying changes Quickbase considers a Task Record Updated event.
Exercise 10.8
Change the Child's Relationship Reference
Use a Task already belonging to a Project. Change only Related Project from one valid existing Project to another. Our controlled test moved a Task from a Project with Project Status = Active to one with Project Status = On Hold.
PREDICTED
Pipeline should execute
OBSERVED
The Tasks Pipeline ran
Event path
Task.Related Project actually changed → Task Record Updated event → Pipeline executed.
Relationship resolution
Quickbase then resolved the proxy/lookup values from the new parent.
Exercise 10.9
Change the Parent, Not the Child
Leave the Task untouched. Edit its parent Projects.Project Status, for example On Hold → Active. The child Task's Project Status lookup now displays Active.
PREDICTED
Probably no Tasks execution
Observed
The lookup changed. The Tasks Pipeline did not run.
A parent-record change altered the value displayed through a lookup on related child records without producing the child Record Updated event required by this Pipeline Trigger.
Remember This
Displayed value change ≠ record mutation.
A value looking different on a record does not necessarily mean that record itself was updated.
Parent
Project Status was actually changed.
Child
Project Status lookup displayed a different value because it derives from the parent.
Follow the mutation—not merely what changed visually on the form.
Path A — Child Reference Changed
Path B — Parent Value Changed
Same visible child value change. Different event path.
Research Boundary
What We Deliberately Did Not Investigate
A good laboratory knows when to stop. These questions belong to later troubleshooting, error, permissions, or relationship-integrity studies.
We know enough for Lesson 10: Pipelines acknowledge relationship fields, but event behavior still depends on which underlying record actually changed.
Definition vs. Runtime
Now the Distinction Has Real Evidence
Lessons 8 and 9 introduced definition and runtime conceptually. Our first execution gives us concrete examples.
Definition
Instructions we built
- Pipeline name
- Ref IDs aa and ab
- Automation app and Tasks table
- Status watched
- Pipeline Results target
- Configured literal text
Runtime
One actual occurrence
- The specific Task record
- Old and new Status during that occurrence
- The specific execution
- Action operating against that Task
- The actual Pipeline Results mutation
Brain-twister
“The pipeline has entered this line.” as configured text belongs to the definition. The actual writing of that literal into Task #X belongs to a runtime execution.
Evidence Board
Preserve What the Laboratory Actually Established
This is the notebook view: observed evidence stays separate from deeper mechanics we have not yet proved.
Observed
- New Pipeline began as a clean definition.
- Record Updated Trigger received Ref ID aa.
- Update Record received Ref ID ab.
- Trigger watched Status.
- Action had triggering-record context before every business field was selected.
- Adding Status downstream changed downstream availability/configuration.
- Pipeline Results became our dedicated output field.
- Action accepted a literal value.
- Pipeline required activation through the On/Off toggle.
- Status change triggered execution.
- Pipeline Results was written.
- Existing Pipeline Results text was overwritten.
- Non-watched Task field did not trigger.
- Relationship-related fields appeared in Trigger selectors.
- Changing Task.Related Project triggered.
- Quickbase resolved new proxy/lookup values.
- Changing parent Project Status changed the child lookup display.
- Parent change did not trigger the Tasks Record Updated Pipeline.
Inferred / Deferred
- Deeper internal mechanics of lookup resolution
- Relationship-integrity enforcement
- Failure behavior
- Permissions interactions
- Retries and error handling
- Precise internal event subsystem implementation
These stay outside the fact column until future evidence earns them a promotion.
Knowledge Check
Did the Pipeline Run?
These are event-path questions, not vocabulary trivia. Trace the mutation, the watched field, and the record that actually changed.
1. The Pipeline is completely configured, but its toggle says Off. Status changes. Should we expect it to respond?
2. The Pipeline is On, Status is watched, and Status changes. What should happen based on our experiment?
3. Only Due Date changes. Status is the only watched field. What should happen?
4. Pipeline Results contains “Hello.” Update Record supplies “The pipeline has entered this line.” What happened in our Text-field experiment?
5. Does adding Status under Fields for subsequent steps automatically tell Update Record to update Status?
6. Update Record could identify the triggering Task before every business field was exposed. What distinction does this demonstrate?
7. Task.Related Project changes, and Related Project is watched. What happened in our experiment?
8. The parent Project Status changes. The Task's Project Status lookup displays the new value. Did our Tasks Pipeline run?
9. True or False: If a value displayed on a Task changes, the Task must have experienced a Record Updated event.
10. When Projects.Project Status was edited, which record actually mutated?
11. At this stage, what is our strongest first evidence that the Pipeline performed work?
Final Mental Model
Follow the Mutation
Lesson 10 connects the definition we built to the runtime behavior we observed.
Definition
We build instructions.
Activation
Pipeline must be On.
Initiating Mutation
A watched field on the actual Tasks record changes.
aa — Trigger
Responds to the qualifying Task update.
Runtime Context
The specific Task becomes the record context.
ab — Action
Targets that Task.
Secondary Mutation
Pipeline Results changes.
Observable Result
Quickbase data contains evidence that automation performed work.
Relationships add another layer: a record may display relationship-derived data whose source mutation actually occurred somewhere else.
Follow the mutation—not merely what changed visually on the form.
Exit Challenge
Same Screen. Different Event Path.
Use the experiment—not intuition—to answer these two scenarios.
Scenario A
A Task belongs to Project A. Its Project Status lookup displays Active. Someone changes Project A to On Hold. The Task now displays On Hold. A Tasks Record Updated Pipeline is watching Project Status.
Should you automatically conclude that the Tasks Pipeline ran? Why or why not?
Reveal reasoning
No. Our experiment showed that a parent mutation can change a child lookup's displayed value without producing the child Record Updated event required by this Trigger.
Scenario B
Instead, someone changes the Task's Related Project to Project B.
What's different?
Reveal reasoning
The Task's own reference field was actually mutated. In our experiment, that produced the Tasks Record Updated event and Pipeline execution.
Next: Lesson 11
Reading the Activity Log
Don't delete the Pipeline. Don't redesign it. Don't clear away its history. We now have successful executions waiting for investigation.
We know the Pipeline worked because we watched the data change.
But what does Quickbase know about what happened inside the execution?
Lesson 10 turned the machine on. Lesson 11 opens the black box.