Quickbase Automation Developer Lab · Lesson 20
Lesson 19 used an existing identity to find a record. Lesson 20 creates a related Task, deliberately maps several field types, and captures an identity that did not exist until Quickbase completed the Create Record action.
What this lesson adds
The pipeline begins with an existing Project and constructs a new Task field by field. The Project keeps its identity. Quickbase assigns a separate Record ID to the Task after creation.
Lesson 19
Which existing record?
Lesson 20
What new record?
Central mental model
Predict → Build → Run → Inspect → Explain
Trigger configuration
| Trigger output | Later purpose |
|---|---|
| Project Name | Build the Task Name |
| Project Status | Evaluate the condition |
| Project Manager | Assign the Task |
| Target Date | Set the Task Due Date |
| Record ID | Establish the relationship |
Project Status is equal to Active
The trigger proves that status changed. The condition decides whether the current value qualifies for creation. On Hold → Active, Active → On Hold, and Active → Complete are all status changes, but only the first qualifies.
If condition is met:
Quickbase → Records → Create Record
The false branch remains empty and finishes normally.
Complete field map
| Task field | Value | Mapping type |
|---|---|---|
| Task Name | Project kickoff — + Project Name | Literal plus reference |
| Due Date | Target Date | Date reference |
| Status | Open | Literal |
| Assigned To | Project Manager → ID | Structured user reference |
| Related Project | Project Record ID | Numeric relationship reference |
Task Name combines fixed text with the runtime Project Name.
Project kickoff — Application Review Project
Target Date maps directly into Due Date, preserving its date meaning.
Open does not come from the Project. It enforces the intended initial Task state.
When Project Manager was Text, it exposed text-like data. After changing it to a User field, the reference picker exposed ID, first name, last name, email, and screen name.
Map Project Manager → ID into Assigned To.
Match the meaning and structure of the source to the destination, not merely what the displayed value resembles.
Map Project Record ID into Task → Related Project. The child stores the parent key; Quickbase then resolves Project Name, Project Status, and Project Target Date through the relationship.
Pipeline responsibility
Establish Related Project.
Quickbase responsibility
Maintain the relationship lookup values.
Controlled tests
Intentionally doing nothing is valid behavior.
| Record ID | 46 |
| Task Name | Project kickoff — Application Review Project |
| Due Date | November 30, 2026 |
| Status | Open |
| Assigned To | User ID 3 |
| Related Project | Project Record ID 2 |
Verify the business result first.
Confirm the Task and its relationship in the Tasks table. The Activity Log supports that verification; it does not replace it.
Capture the new identity
Task 46 did not exist before the action ran. The trigger supplied the source Project identity; Create Record supplied the new Task identity.
Source Project
Record ID from trigger
Stored in the Task’s Related Project field
New Task
Record ID from Create Record
Available to every later step
Multi-record UI save experiment
Two Projects were changed to Active and saved together. The Record Updated trigger remained record-oriented; it did not deliver one combined collection to the pipeline.
| Source Project | Created Task ID | Related Project |
|---|---|---|
| Training Documentation Refresh | 47 | 3 |
| November Reporting Cycle | 48 | 1 |
Boundary for a later lesson
These were two record-triggered executions, not one bulk event. On New Bulk Event will receive its own controlled investigation.
Two concise Activity reviews
Review 1
| Test | Condition | Create Record |
|---|---|---|
| On Hold | False | Did not run |
| Active | True | Ran |
Review 2
Input
Task Name, Due Date, Status, Assigned To, Related Project
Output
New Record ID, saved values, created and updated timestamps
Queue behavior, webhook transport, and deeper lifecycle semantics remain outside this lesson unless an unexplained result requires an addendum.
Create Record does not inherently ask whether a matching Task already exists. If the qualifying path executes again, another Task can be created unless the workflow has a duplicate-prevention rule.
These safeguards are architectural signposts, not additional Lesson 20 experiments.
Evidence ledger
| Classification | Finding |
|---|---|
| DOCUMENTED | Create Record inserts a record into the selected Quickbase table. |
| DOCUMENTED | Selected fields determine which values the action writes. |
| DOCUMENTED | Prior-step references can supply runtime values. |
| DOCUMENTED | The action exposes output from the newly created record. |
| OBSERVED | A Project changing to On Hold followed the false branch. |
| OBSERVED | A Project changing to Active created a related Task. |
| OBSERVED | Create Record returned the new Task identity: Record ID 46. |
| OBSERVED | A User field exposed structured identity properties. |
| OBSERVED | Project Manager ID successfully populated Assigned To. |
| OBSERVED | Project Record ID successfully populated Related Project. |
| OBSERVED | Two Projects changed in one UI save produced separate runs. |
| OBSERVED | Those runs created Tasks 47 and 48 with the correct source context. |
| INFERRED | A repeated qualifying event may create another Task unless duplicate prevention is added. |
| INFERRED | The returned Task ID can become input to later actions, although this lesson stops after observing it. |
“Create Record copies the source record.”
No. It constructs a new destination record from explicitly mapped values.
“Project Name establishes the relationship.”
No. Related Project receives the parent Project Record ID.
“Assigned To should receive the displayed manager name.”
Use the structured User ID when dependable identity is available.
“The pipeline must write every Project lookup field.”
Set Related Project and allow Quickbase to resolve its lookup fields.
“A false condition means the pipeline failed.”
The pipeline evaluated the rule and correctly skipped the action.
“Two changed Projects produce one Create Record action.”
Our test produced two independent record-oriented runs.
“The new Task uses the Project ID as its own ID.”
The Project ID becomes Related Project; Quickbase generates a new Task ID.
Final mental model
A trigger provides the source record and its existing identity. A condition decides whether creation is appropriate. Create Record constructs a new record from literals and references. Quickbase assigns the new record its own identity, while a mapped reference field connects it to the source record.
Answer each question before opening its explanation.
Tasks 46, 47, and 48 now give the next lab disposable records for studying Delete Record: target identity, controlled deletion, and verification of what no longer exists.