Lesson 11
Reading the Activity Log
Lesson 10 turned the machine on. Now we open one Pipeline run and learn how to read the runtime evidence Quickbase preserved about what happened inside it.
Lesson 10 Asked
Can we make a Pipeline execute and observe what it does?
Lesson 11 Asks
Once it executes, what can View run activity tell us about that execution?
Central Idea
The Activity Log is runtime evidence of a Pipeline execution.
Scope First
The Activity Menu Has More Than One Door
The three-dot menu beside a Pipeline Activity entry gives us several different ways to investigate. We need to recognize all four before we choose the one this lesson actually studies.
Definition
Open pipeline
Returns you to the configured Pipeline so you can inspect the automation that produced the run.
Introduced here; not taught in depth.
Snapshot
Open YAML snapshot
Opens a YAML representation associated with the Pipeline/run. This can become useful in later investigation and recovery work.
Deferred to a later lesson.
One execution
View run activity
Opens the detailed runtime evidence for one particular Pipeline run. This is the investigation surface taught in Lesson 11.
Lesson 11 focus.
Broader history
View pipeline activity
Returns to the broader Activity history for the Pipeline so multiple runs can be reviewed.
Introduced here; deeper use comes later.
Remember This
Lesson 11 teaches only View run activity
We are intentionally not turning this lesson into YAML analysis, Pipeline history management, or a troubleshooting course.
Those other menu options are real investigation surfaces, but they deserve their own experiments and their own lesson.
Start With Something We Understand
Known-Good Pipeline, New Question
We are not building another Pipeline. We are inspecting the one whose behavior we already proved in Lesson 10.
Pipeline Definition
Lesson 10 - First Execution
Step 1
Record Updated
Ref ID aa
Step 2
Updated Record
Ref ID ab
Pipeline Definition
The configured automation: its name, Trigger, Action, Ref IDs, fields, values, and other design-time choices.
Pipeline Run
One particular runtime execution of that definition. The same Pipeline definition can execute many times.
Remember This
A Pipeline is not the same thing as a Pipeline run
One definition can produce many executions. Activity becomes much easier to understand once we stop treating those as the same object.
First Reading Habit
The Activity List Reads Newest to Oldest
Before we inspect any runtime details, we need to understand how the Pipeline Activity screen is arranged.
The Pipeline itself executes forward in time, but the Activity list we observed displays the most recent activity at the top. That makes a completed run appear visually backward.
What the Activity Screen Shows
Newest Activity at the Top
Pipeline finished in 1.45s
Runtime lifecycle activity
2 — Updated Record — ab
Configured Action step
1 — Record Updated — aa
Configured Trigger step
Pipeline triggered
Runtime lifecycle activity
If you start at the top and read downward, you are reading this completed run backward through time.
How the Run Actually Executed
Read Bottom to Top to Reconstruct Time
Pipeline triggered
The run begins.
1 — Record Updated — aa
The configured Trigger executes.
2 — Updated Record — ab
The configured Action executes.
Pipeline finished
The run completes.
Remember This
Display order is not execution order
The Activity page is showing us a history list with the newest activity first.
To reconstruct one completed Pipeline run chronologically, begin with Pipeline triggered at the bottom of that run and read upward through Step 1, Step 2, and finally Pipeline finished.
Lifecycle activity
Configured step activity
aa or ab.Where does one run end and the next begin?
The Activity page can contain many executions of the same Pipeline. In the screen we observed, one completed run stretches from its Pipeline triggered entry through its numbered steps to its corresponding Pipeline finished entry.
Then another Pipeline triggered entry below begins an older run.
Designer → Runtime
Ref IDs Become Investigative Anchors
Lesson 9 introduced Ref IDs as part of step identity. Lesson 11 shows why that identity matters after execution.
Design-Time
In the Pipeline designer, the Trigger was aa and the Update Record Action was ab.
Runtime
View run activity reported those same Ref IDs beside the activities generated by those configured steps.
Position
Ref ID
OBSERVED
The Big Reveal
Open the Summary for One Activity
View run activity gets us inside one Pipeline execution, but we still have one more step before we can inspect the runtime evidence.
Each line in the run represents one activity. Click the activity you want to investigate, and Quickbase opens its Summary.
Investigation Path
From Pipeline Activity to Runtime Evidence
1 — Open Pipeline Activity
Locate the Pipeline execution you want to investigate.
2 — Open the Three-Dot Menu
Use the menu beside that Activity entry.
3 — Choose View run activity
Quickbase opens the activities belonging to that particular Pipeline run.
4 — Click an Activity Line
Select Pipeline triggered, Record Updated, Updated Record, Pipeline finished, or another activity in the run.
5 — Read the Summary
Quickbase exposes the runtime information associated with the activity you selected.
Remember This
View run activity opens the run. Clicking a line opens that activity's Summary.
Those are two different levels of investigation.
View run activity shows the activities that occurred during one execution.
Clicking one of those activity lines lets us inspect the runtime evidence associated with that particular activity.
What Appears in the Summary?
The top of the Summary identifies the activity before we even expand its deeper evidence.
Type
Channel
Pipeline
Step
Reference ID
aa or ab.Run timestamp
Read the Activity in Context
Not Every Summary Has the Same Sections
The expandable areas depend on the kind of runtime activity we clicked. That makes sense because a Trigger, an Action, and a Pipeline lifecycle event are doing different jobs.
Record Updated — aa
Our Trigger Summary exposed expandable areas including Input, Output, and Metadata.
Updated Record — ab
Our Action Summary exposed Target step, Input, and Output.
Pipeline triggered
The lifecycle activity exposed its own runtime information, including timestamps, run identity, event identity, and execution metadata.
Expand the Evidence
Once the Summary is open, its expandable areas let us move from the identity of the activity into the details of what it received, knew, targeted, and returned.
Input
Output
Target step
Metadata
Previous
Struct
Timestamps
Identifiers
Remember This
The Summary is activity-specific runtime evidence
Clicking Updated Record does not show some universal summary for the entire Pipeline.
It shows evidence associated with the Updated Record activity. Clicking Record Updated gives us evidence associated with the Trigger instead.
Always ask: Which activity did I click?
Read Labels Locally
Input and Output Do Not Mean One Thing Globally
One of the easiest mistakes is to imagine one giant Pipeline-wide Input bucket and one giant Output bucket. Our run showed something more precise.
Trigger aa
The Trigger activity exposed trigger-related information and returned runtime record information received from Quickbase.
Its Input and Output must be read in the context of the Trigger job.
Action ab
The Update Record Action exposed a Target step, an Input describing what value it was asked to write, and an Output representing what the activity returned afterward.
Target
What am I acting upon?
Input
What am I asking this activity to do?
Activity Executes
Runtime work occurs
Output
What did this activity return?
OBSERVED
Runtime Data Has Layers
Data, Schema, and Context Answer Different Questions
Expanding View run activity exposed more than ordinary field values. We found three useful layers that should not be blended together.
Data
What record and values are we dealing with?
Examples included Record ID, Pipeline Results, relationship values, timestamps, record owner, and Last Modified By.
Schema
What Quickbase fields and types describe those values?
The observed struct information associated properties with values such as Quickbase field IDs and field types.
Context
Where and under whose runtime context did this occur?
Metadata/context exposed application, table, realm, user, and occurrence information in our specimen.
We do not need to memorize every property.
The important skill is recognizing which question a piece of runtime evidence helps answer: value, structure, context, or identity.
OBSERVED
Historical State
Our Record Updated Trigger Exposed Previous State
This is a powerful discovery, but one that requires careful evidence language.
current
previous
change
In this Quickbase Record Updated trigger, Activity exposed previous-state information as well as current/runtime state.
In our fresh Record #24 run, previous FID 2 showed 09-02-2026 11:34 AM, matching the known earlier Date Modified value.
What we are not claiming
We have not demonstrated that every Pipeline trigger always stores every before/after value. Our statement stays bounded to the Record Updated trigger and evidence we actually inspected.
Centerpiece Experiment
Follow Record #24 Through One Fresh Run
Instead of collecting unrelated examples, we used one controlled record and followed it through the execution.
Baseline
Record ID# 24
Pipeline Results: empty
Trigger output
id: 24Action target
id: 24Action output
id: 24Remember This
Follow identifiers across activities
Do not read every expanded box as an isolated blob. Stable identifiers can establish continuity between one activity and the next.
Trace Pipeline Results
Trigger output
pipeline_results: No value
Action target
pipeline_results: No value
Action input
pipeline_results: The pipeline has entered this line.
Action output
pipeline_results: The pipeline has entered this line.
Remember This
Activity can reconstruct the movement of a value
We are no longer limited to saying “the Action succeeded.” We can see the value before the Action, the value requested by the Action, and the value returned afterward.
Controlled Timeline
One User Save, Then a Later Pipeline Mutation
Lesson 10 taught us conceptually that the Pipeline Action creates a second Quickbase mutation. View run activity lets us inspect the chronology much more closely.
Mutation A
Original Quickbase Save
Trigger aa returned Record #24 with Pipeline Results still empty.
updated_at: 17:32:17.082
Mutation B
Pipeline Update Record Action
Action ab returned Record #24 with the configured literal now present.
updated_at: 17:32:20.339
Observed Difference
Approximately 3.257 seconds
separated those two returned updated_at values in this controlled specimen.
The event also moved through distinct lifecycle timestamps
Event received
17:32:17.502392
Prioritized
17:32:17.853222
Start requested
17:32:17.969378
Execution started
17:32:19.001537
We observed distinct timestamp fields. We have not established the undocumented internal implementation behind each scheduling/execution stage.
Practical Observation
Why the Browser Initially Looked Wrong
Immediately after the originating save, the record still appeared with Pipeline Results empty. After refreshing, the Pipeline value appeared.
Browser after original save
Pipeline Results still empty
Pipeline Action occurs
Second record mutation
Browser after refresh
The pipeline has entered this line.
Remember This
A successful save does not prove every downstream mutation is already visible
In our experiment, the originating Quickbase save became visible before the later Pipeline Update Record result appeared in that browser view.
That is an observation from this specimen, not a universal timing guarantee.
Historical Evidence
Current Record State Is Not Historical Runtime State
A later manual change to Record #24 accidentally gave us one of the strongest lessons in the entire Activity investigation.
Current Application State
What does the record contain now?
A later manual edit can replace or clear a value, so the current record may no longer resemble the state that existed during an older Pipeline run.
Historical Runtime Evidence
What did this particular run observe or return?
The older Activity entry still showed the Pipeline Results value from that execution even after the live record was later changed.
Remember This
Records keep changing; run evidence belongs to the run
An old Activity entry can preserve evidence from a state that no longer exists in the current Quickbase record.
OBSERVED
Time Has Layers Too
Different Surfaces Expose Different Temporal Precision
The ordinary Quickbase table and View run activity did not expose time at the same level of precision.
Ordinary Table Display
Date Modified displayed only to the minute in our table: 09-03-2026 10:32 AM.
Both mutations could therefore look identical at that display precision.
Activity Runtime Evidence
Activity exposed sub-second timestamps such as 17:32:17.082 and 17:32:20.339.
Do not casually compare every timestamp.
Our environment exposed wall-clock observations, Activity display times, UTC timestamps, Date Modified values, and occurred_at values that did not all present an immediately obvious common representation.
We know multiple time representations exist. We have not yet established why every representation differed in our environment. Timezone and timestamp semantics need to be understood before treating two surfaces as directly comparable.
Measure the Runtime
What Did "Finished in 1.45s" Actually Measure?
Instead of accepting the displayed duration as a mysterious number, we compared it with the detailed timestamps.
started_at
17:32:19.001537finished_at
17:32:20.456163seconds_elapsed
1.454626Observed in This Run
1.454626 seconds
matched the displayed 1.45s duration and corresponded to started_at → finished_at.
Remember This
Ask "measured from what to what?"
A duration becomes much more useful when we understand its boundaries. In this specimen, the displayed duration did not begin at remote_event_received_at.
Inspect the Bookends
Pipeline Triggered and Pipeline Finished Carry Evidence
The lifecycle entries surrounding our configured steps initially looked almost decorative. Expanding them proved otherwise.
Pipeline Triggered
Observed information included run identity, remote event identity, event-received time, triggered/prioritized/start-request/start timestamps, queue information, engine-service text, and mapping lane.
Pipeline Finished
Observed information included started/finished times, seconds_elapsed, aborted/stop-request information, runtime/queue information, and remote event identity.
Remember This
Lifecycle activities are evidence-bearing runtime objects
Do not inspect only the steps you configured. The Pipeline-level activities can answer questions about run identity, timing, and completion that the individual step entries do not answer alone.
Investigative Hierarchy
Identity Exists at Several Levels
A large Activity entry becomes less intimidating when we ask, “What kind of identity is this value giving me?”
Pipeline identity
Which configured automation?
Lesson 10 - First Execution
Run identity
Which execution of that automation?
pipeline_run_id
Remote event identity
Which incoming event is associated with this evidence?
remote_event_id
Step identity
Which configured activity?
aa / ab
Record identity
Which Quickbase record moved through the activities?
id: 24
Pipeline → Run → Step → Record / Value
with remote event identity available at the lifecycle level.
Quickbase Mastery Method
Activity Can Reveal Internals Without Explaining Them
Some runtime strings are fascinating precisely because they tempt us to tell a bigger story than our evidence supports.
| Evidence Level | What We Can Say |
|---|---|
| OBSERVED | Activity literally exposed strings such as prelude-service, engine-service, pipeline-blaze-inline-01d, and mapping_lane: fast. |
| INFERRED | Those labels appear associated with Pipeline scheduling or execution infrastructure. |
| SPECULATIVE | The exact internal service architecture, responsibilities, topology, communication mechanisms, or implementation behind those labels. |
Remember This
Read the evidence without inventing the architecture
Seeing a service label is not the same thing as understanding the undocumented system behind it. The disciplined answer can be: “We observed the label. We do not yet know exactly what it means internally.”
Documentation + Experiment
Why the Activity Log Exists
Quickbase documentation describes Activity logs as a place to inspect Pipeline step execution information, including errors and input/output values. Our experiment then attached those ideas to a record and Action whose behavior we already knew.
DOCUMENTED
Activity provides runtime step information, including input/output and error information. Documentation also describes visual type coloring for logged values.
OBSERVED
Our known-good Pipeline exposed those runtime concepts against Record #24, Trigger aa, and Action ab.
DOCUMENTED
Research Boundary
This Is Not Yet the Troubleshooting Lesson
View run activity clearly has troubleshooting value. That does not mean we should teach every failure mode the moment we discover the evidence surface.
Future Troubleshooting Lesson
No run occurred vs. a run occurred but failed or produced the wrong result
That distinction deserves controlled negative experiments of its own. Lesson 11 first teaches us how to read a run that we already understand.
Final Mental Model
Reconstruct the Execution
The student should now be able to move from configuration to runtime evidence to resulting application state without confusing those layers.
1
Pipeline Definition
Configured automation — steps, Ref IDs, fields, values.
2
Triggering Event
A qualifying Quickbase mutation occurs.
3
Pipeline Lifecycle
Event received → prioritized → start requested → execution started.
4
Trigger Activity — aa
Runtime input/output, record identity, values, previous-state information where exposed, schema, and context.
5
Action Activity — ab
Target state → action input → returned output.
6
Pipeline Completion
Finish time, elapsed execution time, and completion metadata.
7
Resulting Application State
What subsequently exists in Quickbase after the run.
Lesson 11 Payoff
Activity is runtime evidence that lets us reconstruct what a Pipeline execution knew, received, attempted, returned, and when those activities occurred.
And critically: the application can keep changing afterward. The historical Activity evidence belongs to that particular run.
Lesson Takeaways
What Should Now Feel Different?
The goal was not learning where to click. The goal was learning how to interpret what Quickbase recorded after the click.
One Pipeline definition can produce many separate runs.
View run activity focuses our investigation on one execution.
Ref IDs connect configured steps to runtime evidence.
Lifecycle entries surround the configured steps and carry evidence too.
Target, Input, and Output must be interpreted in the context of the activity being inspected.
Runtime evidence can contain data, schema information, context, and multiple forms of identity.
Record ID lets us trace continuity across Trigger and Action activities.
Our Record Updated specimen exposed previous-state information.
Historical Activity evidence can preserve a state that the current record no longer contains.
Different Quickbase surfaces can expose different timestamp precision and representations.
Observed internal-looking labels do not authorize speculative architecture diagrams.
The other Activity menu options remain intentionally deferred.
Knowledge Check
Read the Evidence, Not Just the Status
True or False: prove that you can distinguish definition, execution, step identity, record identity, timing, and evidence boundaries.
Lesson 11 Quiz
Can You Read Runtime Evidence?
These questions test the distinctions, not your ability to memorize internal field names.
If a Pipeline is named "Lesson 10 - First Execution," every Activity entry under that Pipeline name represents the same run.
Ref ID ab can help connect a runtime Activity entry to the configured Update Record step in the Pipeline designer.
Pipeline triggered and Pipeline finished are merely decorative headings and contain no useful runtime information.
Input and Output should be interpreted in the context of the particular activity you are inspecting.
If a field has a different value today, the current Quickbase record always proves what value existed during an older Pipeline run.
In our Record Updated specimen, Activity exposed previous-state information as well as current/runtime state.
The displayed 1.45-second Pipeline duration in our fresh run corresponded to started_at through finished_at.
Because Activity displayed a value named engine-service, we now know Quickbase's complete internal Pipelines architecture.
A successful Quickbase record save guarantees every downstream Pipeline mutation is already visible in that same browser view.
Record ID can help establish continuity as the same record appears in trigger output, action target, and action output.
Open YAML snapshot, View pipeline activity, and Open pipeline are fully taught in Lesson 11.
The strongest Lesson 11 mental model is that Activity is runtime evidence, not merely a success/failure list.
Research Boundary Reached
We Learned to Read One Run.
We have not yet fully investigated Open YAML snapshot, broader View pipeline activity behavior, or failure-driven troubleshooting. Those deserve another controlled lesson rather than being squeezed into this one.
Lesson 10 turned the machine on. Lesson 11 taught us how to read the evidence it left behind.