Part 2
Research Rules for This Lesson
Several assumptions were close but incomplete. We separate what is documented, predicted, observed, and inferred.
DOCUMENTED
What Quickbase tells us
Platform/UI statements we can directly attribute to Quickbase.
PREDICTED
What we expect
Our expectation before changing the Designer.
OBSERVED
What actually happened
Behavior directly seen during research.
INFERRED
What evidence suggests
A reasoned model not yet directly demonstrated as fact.
Remember This
The Designer outranks our assumptions
If Quickbase behaves differently than our mental model, update the model. Do not force the observation to fit the theory.
Parts 3–5
Start With Add a Step
Quickbase first presents Channels and Logic. Why ask for capability before operation?
Observed Add a Step screen
Handle Errors was the visible Logic option.
PREDICTED
Lesson 8 prediction
Channels supply system-specific capabilities, so selecting Quickbase should reveal operations that know how to work with Quickbase.
Exercise 9.1
Choose the Capability Before the Operation
Why this exercise matters
This turns the Channel idea from architecture into something visible in the Designer.
Student task
- 1. Open Add a step.
- 2. Select Quickbase.
- 3. Pause before choosing an operation.
- 4. Inspect what changed.
Observed categories
5
Trigger
17
Action
3
Query
Trigger examples
Record Created, Record Updated, Record Deleted, On New Event, On New Bulk Event.
Action examples
Create Record, Update Record, Delete Record, Make Request, Generate Document, bulk-oriented operations.
Query examples
Search Records, Search Automations, Get Migrations.
OBSERVED
Selecting a Channel determines the system-specific operations available for the step
Pipeline orchestrates. Channel supplies capabilities. Step uses a capability for its job.
Remember This
A new step does not inherit the previous Channel
Each Add a step returned to Channel/Logic selection. The Pipeline owns the journey. Each step chooses the tool it needs for its own job.
Part 6
Our Three Specimens
Simple memory hooks first; real anatomy follows.
Choose each hook for more detailsInitiation / event context
TRIGGER
Our specimen is Quickbase → Record Updated. It starts an execution when its configured event rules qualify and can expose useful runtime context.
Parts 7–10
Specimen One — Trigger: When Record Updated
Our first Quickbase Trigger gave us a real specimen to dissect.
Observed identity
Connection
Details
Filters
Channel
What system/service capabilities are available?
Account / Connection
What authenticated connection is this step using?
Observed: Realm Default Account / Quickbase account.
Remember This
Lesson 8 this was architecture. Today we can point at it.
The step visibly contains its Quickbase connection/account configuration.
Exercise 9.2
What Must Record Updated Know?
Why this exercise matters
The Trigger name alone cannot identify what Quickbase should monitor.
PREDICTED
Before configuring
Connection, App, Table, and possibly fields.
OBSERVED
What the Designer asked for
Quickbase Account → App → Table → Trigger Fields → Fields for subsequent steps → Number of records changed → Filters.
Our prediction was broadly correct—but incomplete. Prediction makes the observation meaningful; it does not prove we knew the answer.
Resource scope
Automation App
Tasks
The Pipeline is realm-level, while an individual Quickbase step can target specific app/table resources.
Parts 11–14
Three Different Field Questions
The word field appears repeatedly, but the controls answer different questions.
Trigger Fields
Which field changes matter for initiation?
Our Trigger used Status.
Fields for subsequent steps
What useful business data should later steps be able to use?
Assigned To, later Task Name.
Fields to update
Which target fields should the Action actually change?
Triggering Field ≠ Downstream Field ≠ Target Field
Travel Folder Analogy
Triggering record contains
Task Name, Status, Due Date, Assigned To, and many other fields.
Travel folder sent forward
Assigned To and Task Name were explicitly selected. Quickbase also supplied certain built-in/system/runtime information automatically.
Remember This
Do not teach ‘only selected fields exist downstream’
Selected business fields can be explicitly exposed downstream, while Quickbase also supplies certain built-in/system/runtime information automatically.
Exercise 9.3
Change the Travel Folder
Why this exercise matters
This was one of our strongest one-variable experiments.
Starting state
Fields for subsequent steps: Assigned To.
Prediction
Add Task Name upstream → Task Name should become available downstream.
Change ONE variable
Add Task Name.
Observe
Return to Update Record. Task Name is now available.
Prediction Confirmed
Earlier-step output/data availability influences later-step input possibilities.
| Field | Before | After | Role |
|---|---|---|---|
| Status | Open | Complete | Caused Trigger relevance |
| Assigned To | Darian | Darian | Useful downstream data |
| Task Name | Prepare Reports | Prepare Reports | Useful downstream data |
Remember This
A field can be useful later without being the field that caused the Trigger
Status made the event matter. Assigned To and Task Name did not need to change to be useful downstream.
Parts 15–16
Filters Adapt to the Data Being Evaluated
OBSERVED
Assigned To — User field
Presence-oriented operators such as has value / does not have value appeared.
OBSERVED
created_at — date/time field
is on a date appeared with date and timezone configuration.
Remember This
Available Simple Filter operators vary with field/data type
We did not build a complete operator matrix, so we do not claim exact universal operator sets.
Number of records changed
Quickbase exposed Any or Set a maximum. Choosing maximum revealed an integer input.
NOT YET
Bulk-event semantics
Grid edit, imports, APIs, bulk operations, and other mutation paths remain future tests.
Remember This
10 is not a universal recommendation
Quickbase AI suggested 10 during research, but threshold choice is a workflow engineering decision—not a course rule.
Parts 17–19
Step Position vs. Ref ID
They sit together in the Designer, but our move experiment separated their jobs.
Step Position
WHERE
Where the step currently appears.
Ref ID
WHICH STEP
Stable identity used to identify/reference that step.
Classroom Desk Analogy
Before
Desk #1 → Alex
After move
Desk #3 → Alex
Before
Position 2 → ab
After move
Position 3 → ab
Remember This
Position tells me WHERE. Ref ID tells Quickbase WHICH STEP.
Moving the Action changed visible position while observed Ref ID remained ab.
INFERRED
Where did ac go?
A deleted/earlier-created step may have consumed ac. That would fit persistent identifier allocation behavior.
NOT YET
Why it stays inferred
We did not preserve the exact creation/deletion event that explains the missing ac. Therefore the explanation is not OBSERVED fact.
Parts 20–25
Specimen Two — Action: Update Record
The Trigger asks what event matters. The Action asks what target to act on and what to write.
Target
Which record should this Action operate against?
Field
Which target field should change?
Value
What value should be written?
Remember This
Available data is information—not an instruction
Making Task Name available from aa does not automatically update it. The Action separately chooses field and value.
Exercise 9.4
Where Does This Value Come From?
Why this exercise matters
The source of an Action value changes the meaning of the workflow.
Literal
Pipeline Changed This
Same configured value each execution.
Runtime Reference
Task Name from aa
Can vary by execution.
Jinja / Expression
Can reference and/or transform runtime data.
Lesson boundary
Lesson 9 explains why Jinja has a job. It does not teach Jinja syntax.
Why aa matters when referencing data
Multiple earlier steps might expose Task Name. A later step needs an origin: Task Name from which step?
aa
Trigger output
Task Name
ab
Action context
Task Name
ad
Search output
Task Name
Remember This
Ref IDs give runtime data an origin
That is where Ref IDs stop looking decorative and become part of the data-flow architecture.
Parts 26–33
Specimen Three — Query: Search Records
Search Records changes the shape of the workflow because it can return a collection.
DOCUMENTED
The Designer told us: This step generates a list
The UI also described loop, batch action, and Jinja as ways to work with items from that list.
Connection
App
Table
Fields for subsequent steps
Date/time comparison behavior
Limit
Filters
Trigger
What happened?
Query
What can I find?
Action
What should I do?
Data shape
This is a collection, not one record.
Remember This
The shape of a step's output affects what the workflow can do next
A collection introduces a different processing problem than a single record.
Delightful Observation
Quickbase Automatically Introduced a Loop
Search Records
Loop
For each item in Search Records — refer to each item as ad
DO
End of Loop
Stack-of-Papers Analogy
The Query returns #101, #102, #103—the stack. The Loop gives us one current item at a time.
Iteration 1
#101
Iteration 2
#102
Iteration 3
#103
Remember This
Query gives us the stack. Loop gives us one item from the stack at a time.
Collection and current loop item are not the same data shape.
Exercise 9.5
Move an Action Into the Loop
Why this exercise matters
This proves workflow structure can change while step identity remains stable.
Move
Drag Update Record — Ref ID ab into Loop → Do.
Observe
Visible position changes. Ref ID remains ab.
STOP here
Do not configure the Action against the current loop item yet. That belongs later.
Loop
Individual processing.
Bulk / Batch
Set-oriented processing where appropriate.
Staging / Helper Table
Persist intermediate work for later processing.
NOT YET
Preview only
Detailed loops, batch processing, bulk upsert, staging architecture, and performance comparison are future lessons.
Parts 34–37
Put the Three Specimens Side by Side
| Comparison | Trigger | Query | Action |
|---|---|---|---|
| Our specimen | Record Updated | Search Records | Update Record |
| Observed Ref ID | aa | ad | ab |
| Memory hook | Something happened | Go find something | Do something |
| Primary role | Initiation/event | Retrieval | Operation |
| Resource configuration | Yes | Yes | Yes/context dependent |
| Can expose runtime data | Yes | Yes | Yes depending on operation |
| Can return collection | Not our focus here | Yes | Not our example |
| Starts workflow | Yes | No | No |
| Uses Channel capability | Yes | Yes | Yes |
Execution Flow — order of work
aa Trigger
ab Action
ad Query
Loop
Data Flow — movement of information
aa Runtime Output
Available Downstream
ab Input / Reference
ad Search Results
Loop Current Item
Remember This
A Pipeline has both an order of work and a movement of information
Execution flow asks what happens next. Data flow asks what information later work can use.
Complete Step Anatomy Vocabulary
Identity
Step Position, Ref ID
Classification
Trigger, Query, Action
Capability
Channel / Logic
Authentication
Connection / Account
Resource
App, Table, Record, external resource
Configuration
Fields, Filters, Limits, operation settings
Inputs
Literal, references, expressions/Jinja
Outputs
Runtime result/context downstream
Control Context
Normal sequence, Loop, later conditions/error handling
This is anatomy vocabulary—not a mandatory checklist for every step.
Step Number ≠ Ref ID
Where vs which step.
Channel ≠ Account
Capability vs authenticated connection.
Trigger Field ≠ Downstream Field
Event relevance vs available data.
Available Field ≠ Update Instruction
Information vs operation.
Literal ≠ Runtime Reference
Fixed definition value vs execution-specific value.
Query Collection ≠ Current Loop Item
Stack vs one item.
Pipeline Definition ≠ Runtime Execution
Instructions vs one occurrence.
Part 38
Research Findings Board
Months from now, this is where we can see what we proved versus what we only suspected.
OBSERVED
Directly observed
- Add Step presents Channels and Logic.
- Selecting Quickbase exposes Quickbase operations.
- New steps independently select Channels.
- Quickbase step contains connection/account configuration.
- Record Updated uses App/Table/field/filter configuration.
- Trigger fields and downstream fields are separate.
- Filter operators varied with selected field type.
- Trigger supports a maximum records-changed threshold.
- Adding Task Name upstream made it available downstream.
- Update Record requires target fields and values.
- Values can be literal/reference/Jinja.
- References expose earlier-step context plus system/meta information.
- Search Records generates a list.
- Search Records automatically introduced a Loop.
- Moving ab changed position but preserved Ref ID.
INFERRED
Inferred / not fully tested
- Missing ac likely reflects prior identifier allocation/deletion behavior.
- Exact maximum-record threshold behavior across every mutation source remains untested.
- Complete filter-operator behavior across all Quickbase field types remains untested.
- Complete contents/semantics of all system/meta reference values remain untested.
Part 39 — Interactive Knowledge Check
Dissect the Pipeline
This quiz mixes scenario selection and True/False. After grading, every item explains the architecture behind the answer.
A step displays ‘3 — Ref ID ab.’ What does the 3 primarily describe?
A Trigger should react when Status changes, but later steps need Assigned To. Where do those ideas belong?
Adding Task Name to Fields for subsequent steps automatically tells a later Action to update Task Name.
A downstream Task Name should always become the exact text ‘Pipeline Processed.’ What input style best matches that requirement?
A downstream Task Name should reuse Task Name from the triggering record. What input style fits best?
If Search Records finds 12 Tasks, the Query produced one Task.
What job does the Loop introduce after Search Records returns a collection?
Once the first step selects Quickbase, every later step automatically uses the Quickbase Channel.
Moving a step necessarily changes its Ref ID.
Which statement best describes a Channel?
Which memory-hook set best matches our three Lesson 9 specimens?
A Query returns three records and an Action must process each individually. What new design problem appeared?
Ready to grade the dissection?
Answer all 12 questions first. The explanations are part of the lesson.
Part 40
Final Exercise — Explain the Machine Without Quickbase Vocabulary
If you can rebuild the Quickbase vocabulary from behavior, you understand it rather than memorized it.
A change occurs in Tasks. The workflow receives information about the changed record. It searches for related records. Three records are found. Each is processed individually and an operation is performed.
Part 41
What We Deliberately Did NOT Learn
Lesson 9 brushes against many future topics. This boundary keeps the lesson approachable.
Lesson 10
Executing the Pipeline
Lesson 11
Activity Log analysis
Lesson 12
Detailed runtime data passing
Lesson 13
Conditions / branching / stopping
Lesson 14
Query engineering
Lesson 15
Collections / loops
Lesson 16
Jinja references
Lesson 17
Jinja transformations
Lesson 18
Dates / scheduling
Lesson 19
Record mutation engineering
Lesson 20
Secondary events / loops
Remember This
You were not supposed to understand Jinja yet
You were supposed to understand why something like Jinja will eventually be needed.
Part 42
Lesson 9 Exit Model
A Pipeline contains Steps.
Each Step has a particular job.
A Step may use a Channel.
The Channel gives it system/service capabilities.
A Channel may need an Account.
The Account provides an authenticated connection.
A Trigger starts the workflow.
It can also bring runtime information with it.
A Query finds information.
Our Search Records specimen explicitly generated a list.
An Action does something.
It needs a target and values.
Earlier steps can provide data to later steps.
Later steps can reference that runtime information.
Ref IDs identify steps.
Step positions tell us where they currently appear.
Collections create processing decisions.
Loops are one strategy; bulk/batch and staging are later considerations.
A Pipeline is not merely a row of instructions.
It is an ordered workflow in which steps perform different jobs and runtime information flows from one part of the execution into another.
Part 43 — Transition to Lesson 10
We've Opened the Machine.
Identified the machine
Opened the machine
Identified its major parts
Followed some data paths
One thing we have not done:
RUN IT.
Lesson 10 — Our First Pipeline Execution
One tiny Pipeline. One known record. One controlled mutation. One prediction. One execution. One observed result.
Did the machine actually behave the way our model predicts?