Purpose
This application will become the laboratory used throughout the course.
We will intentionally begin with very little and allow the schema and automation architecture to grow only when an experiment gives us a reason to add something.
You do not need to complete the Quickbase Code Pages Developer Lab first.
This course begins with its own application and its own data.
What You Need
Use a Quickbase account where you are permitted to create and modify applications.
Builder Access
The tutorials assume that you can access the Quickbase builder features required by the lessons.
A Safe Training App
Do not perform these experiments inside an important production application.
Remember This
This is a laboratory
We are deliberately going to modify records, change configuration, create automation, test recipients, create relationships, and eventually allow Pipelines to perform operations against our data.
Give the experiments their own application.
Step 1
Create the Tutorial App
Create a new Quickbase application.
Suggested Application Name
Quickbase Automation Lab
The exact application name is not technically important, but using the tutorial name will make screenshots and instructions easier to follow.
At this point, do not create a large business application. We want the smallest useful schema possible.
Step 2
Create the Tasks Table
Our first working table will simply be called Tasks.
Tasks
Four developer-created fields
| Field | Type | Purpose |
|---|---|---|
| Task Name | Text | Identifies the task |
| Status | Text - Multiple Choice | Gives us a simple changing state |
| Due Date | Date | Gives us something time-relative to automate |
| Assigned To | User | Gives automation a dynamic recipient |
Status — Multiple Choice Values
These fields are intentionally uncomplicated. Together, however, they give us four fundamentally different kinds of information.
Our First Data Model
Four Fields, Four Concepts
Each field gives the laboratory a different kind of information that automation can eventually observe or use.
Task Name
Identity / Description
Tells us what the record represents.
Status
State
Tells us the current condition of the task.
Due Date
Time
Gives the task a meaningful point on the calendar.
Assigned To
Person
Connects the task to a Quickbase user.
Remember This
Four simple fields can produce a surprising amount of automation behavior
Identity, state, time, and person are enough to begin exploring events, conditions, recipients, reminders, scheduling, and workflow.
Step 3
Don't Add Everything Yet
This is important.
We could immediately add fields such as:
But we won't.
Remember This
Add complexity when the experiment creates a reason for it
If a later lesson requires Priority, we'll add Priority.
If we discover that a relationship solves a problem, we'll build the relationship then.
If Pipelines eventually need a Task Change History table, we'll create it when we reach that problem.
This way, students understand why the schema evolved instead of receiving twenty mysterious fields on Day One.
Step 4
Record the Actual Quickbase Schema
Once Quickbase creates the fields, record their actual Field IDs.
Remember This
Do not assume your FIDs will match someone else's application
Field IDs are assigned inside the table where the fields are created. The visible field label and Quickbase's internal Field ID are related, but they are not the same thing.
Record Your Field IDs
Use the values from your own Tasks table
| Field | Your FID |
|---|---|
| Task Name | ? |
| Status | ? |
| Due Date | ? |
| Assigned To | ? |
Quickbase Adds Fields Too
Your Tasks table will also contain fields Quickbase creates automatically. That is expected.
Why Record FIDs Now?
Later lessons involving queries, APIs, Jinja, or Pipelines may make these identifiers important. For now, simply record them.
Step 5
Create Sample Records
Create a few Tasks manually. We want variation, not volume.
Starting Dataset
Three records are plenty for now
| Task Name | Status | Due Date | Assigned To |
|---|---|---|---|
| Prepare Monthly Report | Open | Future date | You |
| Review Application | On Hold | Future date | You |
| Update Training Notes | Complete | Recent/current date | You |
Why assign the records to yourself?
Using yourself initially makes the experiments easier because later lessons will send actual automatic emails.
Additional users and more complicated recipient scenarios can be introduced when an experiment requires them.
Step 6
Stop
Seriously. 😆
Stop Point
Do Not Continue Building
Our application should initially be boring.
That's desirable. We want to know exactly which behavior came from each thing we add.
What the Laboratory Should Look Like
At the end of Getting Started, the application should be almost embarrassingly simple.
Application
Quickbase Automation Lab
Table
Tasks
Laboratory Ready
That's Enough.
We now have identity, state, time, a person, and a handful of records.
Every automation mechanism we add from this point forward can be observed against a known starting point.
Later Laboratory Upgrade
Getting Ready for Lesson 10
Lessons 1–9 deliberately used our original Tasks table. Lesson 10 is the first time our Pipeline experiments give us a reason to expand the laboratory.
Do this preparation after Lesson 9 and before opening Lesson 10.
Remember This
The original rule still stands
We did not build Projects earlier because we did not need Projects earlier.
Lesson 10 finally gives us a reason.
Upgrade 1
Add Pipeline Results to Tasks
| Field | Type | Purpose |
|---|---|---|
| Pipeline Results | Text | Gives our first Pipeline a harmless, dedicated field where it can visibly prove that an Action executed. |
Leave Pipeline Results blank before Lesson 10.
Lesson 10 uses that blank field as controlled evidence. If text suddenly appears there after the first execution, we know exactly what produced it.
Upgrade 2
Create the Projects Table
| Field | Type | Purpose |
|---|---|---|
| Project Name | Text | Identifies the parent Project |
| Project Status | Text - Multiple Choice | Gives us parent state to expose through a relationship |
| Project Manager | User | Identifies the person responsible for the Project |
| Target Date | Date | Gives the parent record a time-oriented value |
Project Status choices
Upgrade 3
Create the Projects → Tasks Relationship
Parent
Projects
Child
Tasks
Do not turn this into a relationships lesson yet. We only need enough relationship structure for Lesson 10 to compare a real child-record mutation with a parent change that affects a relationship-derived lookup.
Child-side fields
Expect relationship fields such as Related Project, the Project name reference/proxy field produced in your app, and a Project Status lookup.
Parent-side helpers
Quickbase also creates relationship helpers on Projects, such as related Task report, count, and add/link fields. Their exact labels can vary.
Use the field names Quickbase actually creates in your app.
In our laboratory, the child side included Related Project, Project Name / Project Name2, and Project Status. Lesson 10 records those observed names instead of pretending every app will label a reference proxy identically.
Populate the Projects Table
These are the four Project records used in our Lesson 10 laboratory. Using the same values makes the relationship experiments easier to reproduce.
| Project Name | Status | Manager | Target Date |
|---|---|---|---|
| November Reporting Cycle | Active | You | 11/15/2026 |
| Application Review Project | Active | You | 11/30/2026 |
| Training Documentation Refresh | On Hold | You | 12/15/2026 |
| Monthly Administrative Work | Active | You | 12/31/2026 |
Add More Tasks for Pipeline Research
The original three Tasks were enough for the early communication lessons. Pipeline work benefits from a larger set of records spread across several Projects.
| Task Name | Due Date | Status | Related Project | Pipeline Results |
|---|---|---|---|---|
| Draft November Reporting Checklist | 11/04/2026 | Open | November Reporting Cycle | blank |
| Validate November Report Data | 11/08/2026 | Open | November Reporting Cycle | blank |
| Finalize November Reporting Package | 11/12/2026 | Open | Training Documentation Refresh | blank |
| Review Pending Applications | 11/10/2026 | Open | Application Review Project | blank |
| Send Application Follow-Up Notices | 11/18/2026 | On Hold | Application Review Project | blank |
| Review Pipeline Training Notes | 11/14/2026 | Open | Training Documentation Refresh | blank |
| Publish Updated Training Guide | 12/01/2026 | On Hold | Training Documentation Refresh | blank |
| Reconcile Monthly Administrative Records | 11/20/2026 | Open | Monthly Administrative Work | blank |
About the research CSV
Our finished research data contains later edits, changed statuses, and one Pipeline Results value created during Lesson 10. The table above intentionally shows the pre-experiment setup state: use the records and relationships, but leave Pipeline Results blank so Lesson 10 can generate the evidence itself.
Laboratory Upgraded
Now We Have a Reason for Relationships.
The laboratory now contains multiple Projects, Tasks belonging to different Projects, relationship-derived values, and a blank Pipeline Results field ready to capture our first deliberate Pipeline Action.
Laboratory upgraded. Return to Lesson 10.
Next
Lesson 1 — The Automation Landscape
The application is ready. Before we automate anything, we will establish the vocabulary needed to distinguish Quickbase communication tools from workflow automation.