Part 1
Trigger, Query, and Action — Three Different Jobs
Before we add a Loop, separate the three jobs already present in Pipeline design.
Trigger
Something happened. Should this run begin?
Examples include Record Created, Record Updated, and Record Deleted.
Query
Go find the records we need.
This lesson focuses on Quickbase → Search Records.
Action
Now do something with what we found.
Our main action remains Quickbase → Update Record.
Parts 2–4
Why Filters Alone Stop Being Enough
Filters are familiar. The new problem is what happens when we intentionally need every returned record, but different records require different work.
Search Filter Question
Should this record be in my list?
Search Records
Filter: Status starts with OpenRecords that fail the filter do not become members of the returned list.
Loop Condition Question
This record is already in my list. What should happen to it?
Current item
Assigned To has value?
YES → Action A
NO → Action BBoth groups stay in the workflow because both groups need work—just different work.
Remember This
A Filter removes records from consideration. A Condition keeps the current record in the workflow and decides what should happen to it.
This is the reason Conditions become necessary. If the record still needs processing even when a test is false, filtering it away would solve the wrong problem.
Part 5
Create a Fresh Lesson 13 Pipeline
Preserve earlier Activity and isolate the new experiments in a separate definition.
Pipeline Name
Lesson 13 - Conditions and Loops
Unlike our earlier event-driven Pipelines, this one begins with a Query and can be started manually with Run. We observed Run, Schedule, Activity, and Statistics controls rather than the same event-trigger ON/OFF experience.
Activity still displayed Pipeline triggered even for our manual run. The runtime metadata showed remote event fields with no value. We record that wording without inventing internal meaning.
Parts 6–10
Search Records Gives Us a List — the Loop Gives Us the Current Item
Quickbase's own UI gives us the vocabulary we need: Search Records “generates a list,” and the Loop processes “each item.”
Search Records
Status starts with Open
LIST OF MATCHING RECORDS
The Search result
LOOP
For each item in: Search Records
CURRENT ITEM
One record for this iteration
Remember This
The Search gives us the pile. The Loop picks up one record at a time.
The Search creates the list. The Loop does not create another mysterious set—it gives us an individual-record context for each item already in that list.
Parts 7–9
Known-Good Search Records Configuration
Keep the first Query intentionally simple so every later result is easy to explain.
App
Automation
Table
Tasks
Filter
Status starts with Open
Limit
Unlimited
Fields for subsequent steps
Due Date · Assigned To · Task Name · Status · Pipeline Results
Pipeline Results was added later during research, but the final student setup should include it from the beginning.
Part 9
Quickbase Automatically Created the Loop in Our Experiment
When we added Search Records, Quickbase created a Loop with For each item in: Search Records.
Observed Loop language
For each item in: Search Records
Refer to each item as: aaWe keep this finding bounded to our Search Records experiment rather than claiming every Query always creates a Loop.
Part 11
Why Use a Loop Instead of Just Adding More Steps?
The value of a Loop is not simply that it repeats. It gives us a stable individual-item context for each record in the list.
Without Individual-Item Organization
aa — Search Records
↓
ab — Update Records
↓
ac — Update Records
↓
ad — Update RecordsWe can keep stacking operations against a result, but the business question “what does each record need?” stays muddy.
Loop-Oriented Design
aa — Search Records
↓
LOOP
↓
Current item
↓
decision
↓
action
↓
next itemNow the workflow can inspect one record, make one or more decisions, perform one or more actions, then move to the next item.
Parts 12–16
First Loop Experiment — Prove One Action Can Run Many Times
Before adding Conditions, prove the Loop itself with a literal update.
Inside Do
Quickbase → Update Record
Destination
Pipeline Results
Literal Test Value
Processed by Lesson 13 Loop
Runtime Proof
Found 5 Records of Tasks type
Activity reported five returned records, and Metadata reported batch.size: 5.
Loop Target Item
Updated Record
Loop Target Item
Updated Record
Loop Target Item
Updated Record
Loop Target Item
Updated Record
Loop Target Item
Updated RecordRemember This
One action inside a Loop can execute many times during a single Pipeline run.
There was one Update Record step in the definition, but Activity showed it execute once for each Loop Target Item.
Parts 15–17
Loop Target Item, Loop Metadata, and Ref IDs
Activity gives us runtime language that helps separate definition from execution.
Loop Target Item
The individual member currently being processed from the Search list.
Loop Metadata
batch.size: 5loop.index: 4 on the final item. That is consistent with zero-based indexing in this specimen.
Ref IDs
Deleted and recreated steps caused IDs such as ad, af, am, and an. Gaps are not evidence of missing runtime work.
Parts 18–19
Now Add a Condition Inside the Loop
A Condition evaluates the current item's available runtime information and sends that item down the appropriate branch.
Search Filter
Which records enter the list?
Example: Status starts with Open.
Loop Condition
For this current item, which path should it take?
Example: Assigned To has value.
Remember This
The Search filter decides who gets into the room. The Loop Condition decides what happens to each person once they are inside.
That analogy is the shortest way to remember the boundary.
Parts 20–22
The Reference Can Be Technically Available and Still Be the Wrong Teaching Choice
The first confusing design evaluated an Update Record output rather than the original Search Records current item.
Common First-Timer Confusion
Should the first Condition point to Search Records or Update Record?
What goes wrong
We built:
Search Records
↓
Loop
↓
Update Record
↓
Condition referencing Update RecordNow we had to ask whether we were testing the original searched record or the result of the update action.
Better model
For the foundational experiment, evaluate the current searched item directly:
Search Records
↓
Loop
↓
Condition: Search Records → Assigned To → has value
↙ ↘
YES NOReferencing Update Record was not inherently invalid. It was unnecessarily indirect for the business question we were trying to teach.
Remember This
Pipeline design is not only about whether Quickbase allows a reference.
The reference should represent the business question you are actually asking.
Parts 23–25
Clean Controlled Experiment — 13 Records, Two Branches
Remove the research chaos and create two obvious populations before pressing Run.
Before the Run
- Set every Task to Status = Open.
- Clear Pipeline Results for all records.
- Leave Assigned To populated on five records.
- Leave Assigned To blank on eight records.
Assigned To Has Value — 5
#17 · #18 · #19 · #21 · #22
Expected branch result: Loop condition met
Assigned To Blank — 8
#23 · #24 · #25 · #26 · #27 · #28 · #29 · #30
Expected branch result: Loop condition is not met
Remember This
Predict before you Run
Search = 13 · TRUE branch = 5 · FALSE branch = 8. If the evidence does not match those numbers, something in our configuration or mental model needs investigation.
Part 24
Final Branch Actions
Both branches update the current searched Task. Only the value written to Pipeline Results differs.
If condition is met
Update Record am
Target: Search Records — Tasks
Pipeline Results: Loop condition met
If condition is not met
Update Record an
Target: Search Records — Tasks
Pipeline Results: Loop condition is not met
Part 25
Final Result — One List, Thirteen Decisions, Two Paths
The clean CSV matched the prediction exactly.
13 Open Tasks
All entered the Search list
One Loop Definition
Processes each current item
13 Individual Evaluations
Assigned To has value?
5 → TRUE
Loop condition met
8 → FALSE
Loop condition is not met
Remember This
The branch belongs to the current item, not to the entire Search result.
The same Loop processed all 13 records, but each individual item followed the branch appropriate to its own data.
Parts 26–28
The Final Runtime Mental Model
Keep four responsibilities separate and the Loop stops looking mysterious.
SEARCH
Who gets into the list?
LIST
13 matching records
LOOP
Which item are we working with right now?
CONDITION
Which path should this current item take?
ACTION
What work should happen on that path?
SEARCH
Determines membership.
LOOP
Determines the current item.
CONDITION
Determines the path.
ACTION
Determines what happens.
Remember This
A Loop is not merely “repeat this action.”
It creates a controlled process for each item returned by the Query. One iteration can eventually contain an entire mini-workflow before the Loop advances to the next item.
Parts 29–31
Terminology, Overwrites, and Activity Evidence
Precise language and runtime evidence keep us from inventing what happened.
Use Quickbase's words
Prefer list, item, and Loop Target Item rather than inventing “static set” and “dynamic set.”
Later actions can overwrite earlier ones
We observed an earlier literal Pipeline Results value replaced by a later condition-branch value during the same iteration.
Remember This
The table tells us the final state. Activity tells us how the Pipeline got there.
As learned in Lesson 11, Activity can prove Search count, batch size, Loop Target Items, repeated action executions, record IDs, branch outcomes, loop index, and runtime duration.
Part 32
Common First-Timer Confusions
These are worth teaching because we ran into several of them ourselves.
Common First-Timer Confusion
Search returned several records. Why can't I think of them as one record?
What goes wrong
That erases the distinction between the whole list and the individual item currently being processed.
Better model
The Search result is a list. The Loop provides a current item from that list.
Common First-Timer Confusion
Does the Loop return a new set?
What goes wrong
That makes it sound like the Loop performs another Query.
Better model
The Search creates the list. The Loop processes each item already in that list.
Common First-Timer Confusion
Should my first Condition point to Search Records or Update Record?
What goes wrong
Pointing to Update Record introduced an unnecessary extra layer for our first experiment.
Better model
For this lesson, point directly to the original Search Records current item.
Common First-Timer Confusion
Does a Filter update records?
What goes wrong
A filter only determines what qualifies.
Better model
Actions perform updates. Filters and Conditions make qualification or path decisions.
Common First-Timer Confusion
Does one Update Record inside a Loop run only once?
What goes wrong
That confuses one step definition with one runtime execution.
Better model
One definition can execute once for every Loop Target Item.
Common First-Timer Confusion
Do I need to turn this Pipeline ON?
What goes wrong
Importing the event-trigger habit without looking at the current Pipeline type.
Better model
Our manually run Query-based Pipeline used Run. Check the controls actually presented by the Pipeline you built.
Part 33
Evidence Classification
Keep the research boundary visible.
- Search Records “generates a list.”
- Each item can be processed with a Loop, batch action, or Jinja.
- Loop uses “For each item in.”
- Search Records supports filtering and Fields for subsequent steps.
- System-generated fields are included automatically according to the UI/help encountered.
- Search Records automatically created a Loop in our experiment.
- The first clean run returned five records and batch.size = 5.
- Activity produced five Loop Target Items and one Update Record definition executed five times.
- A Condition could reference earlier-step fields.
- Search Records and Update Record exposed downstream data differently.
- Directly referencing Search Records made the foundational condition model clearer.
- All 13 Open records entered the list; five took TRUE and eight took FALSE.
- The manual Query Pipeline used Run instead of the earlier trigger toggle pattern.
Our teaching model: the Loop creates an individual-item processing context over the list returned by Search Records. This is strongly supported by “For each item in,” Loop Target Item, repeated actions, and branch-specific outcomes.
Do not invent internal memory/storage mechanics, internal loop-engine details, parallelism beyond what Activity proves, undocumented $prev behavior, or reasons for UI behavior we did not test.
Part 34
Lesson Boundary
Lesson 13 is intentionally enough.
Not yet:
Remember This
Lesson 13 is Search → List → Loop → Current Item → Condition → Branch → Action
That is enough foundation for later Pipeline work to make sense.
Part 35
Key Takeaways
Keep the responsibilities crisp.
Trigger, Query, and Action steps solve different problems.
Search Records is a Query that can return a list.
A Loop processes each item from that list.
Activity identifies the current item as a Loop Target Item.
One action inside a Loop can execute many times in one run.
A Search filter decides which records enter the list.
A Condition inside the Loop decides what path each current item takes.
Different items in the same list can take different branches.
The cleanest first-loop design evaluates the original Search Records current item directly.
Later actions can overwrite earlier changes during the same iteration.
Activity shows the execution story; the table usually shows the final state.
Lesson 13 Quiz
Search, Loop, Condition, or Action?
Test whether you can separate list membership, current-item context, branching, and work.
Progress
0/10
Search Records returns only one record at a time.
A Search Records filter determines which records become members of the returned list.
A Loop creates five different Update Record steps if five records are returned.
The Loop Target Item represents the item currently being processed.
A Search filter and a Condition inside a Loop perform the same job.
Every record returned by the Search must follow the same branch.
In our controlled experiment, five records followed the true branch and eight followed the false branch.
A later action in the same Loop iteration can overwrite a value written earlier in that iteration.
The exact Ref ID letters are guaranteed to remain perfectly sequential.
A manually run Query-based Pipeline necessarily has the same ON/OFF toggle behavior as an event-triggered Pipeline.
Ready to grade it?
Answer all ten questions first.
Lesson 13 Complete
Four Responsibilities. One Repeatable Pattern.
SEARCH
finds the list
LOOP
chooses the current item
CONDITION
chooses the path
ACTION
performs the work
What looked chaotic during experimentation becomes predictable once list membership, current-item context, branching, and actions stop being blended together.