The Schema Explorer from Lesson 9 taught us how to discover the application's structure instead of hard-coding it. The Code Page could discover the current App DBID, retrieve the application's tables, inspect fields, find Field IDs, and inspect child-side relationship metadata.

We do not begin by throwing POST requests at Quickbase. First, define the structure that the requests must eventually create.

Departments
├── Department Name
└── Location
        │
        ▼
People
├── Name
├── Age
└── Favorite Color
        │
        ▼
Tasks
├── Task Name
├── Due Date
└── Status

The important question in this lesson is not merely what a parent or child table is. The important question is what Quickbase physically creates when JavaScript asks Quickbase to construct those relationships.

Creating a Quickbase table is a higher-level schema operation. Quickbase automatically supplies its normal system fields before our code creates a single custom field.

Relationships add a third provenance category. A relationship operation can cause Quickbase to add a reference field and lookup fields even though our JavaScript never sends separatePOST /fieldsrequests for them.

{
  parentTableId: departmentsTableDbid,

  foreignKeyField: {
    label: "Related Department"
  },

  lookupFieldIds: [
    departmentNameFieldId,
    departmentLocationFieldId
  ]
}

A relationship cannot be constructed before the identifiers it depends on exist. Dynamic schema creation therefore becomes a dependency chain between API requests and API responses.

Create Departments
        ↓
Capture Departments Table DBID
        ↓
Create Department Name
        ↓
Capture Field ID
        ↓
Create Location
        ↓
Capture Field ID
        ↓
Discover People Table DBID
        ↓
Create Departments → People

Create Tasks
        ↓
Capture Tasks Table DBID
        ↓
Create Task Name
        ↓
Create Due Date
        ↓
Create Status
        ↓
Capture all Field IDs
        ↓
Discover People Name Field ID
        ↓
Create People → Tasks

During testing, a newly created table reported anextFieldIdvalue that let us predict what the next custom FIDs might be. The prediction happened to be correct.

That is useful for understanding Quickbase behavior. It is not how the application should obtain an identifier.

// Do not do this.
lessonState.departmentNameFieldId = 6;

const data = await response.json();

lessonState.departmentNameFieldId = data.id;

One of the most useful discoveries in the finished schema was that different tables can legitimately contain the same Field ID.

There is no collision because a Field ID is meaningful in the context of its table. That is why the Code Page retains both Table DBIDs and Field IDs.

Departments / FID 6
People      / FID 6
Tasks       / FID 6

// Three different fields.

The Code Page keeps the identifiers it discovers and creates in a JavaScript object. This is more than convenient storage: it represents the dependencies between schema operations.

const lessonState = {
  departmentsTableDbid: null,
  peopleTableDbid: null,
  tasksTableDbid: null,

  departmentNameFieldId: null,
  departmentLocationFieldId: null,
  personNameFieldId: null,

  taskNameFieldId: null,
  taskDueDateFieldId: null,
  taskStatusFieldId: null,

  departmentsPeopleRelationshipId: null,
  peopleTasksRelationshipId: null,
};

JavaScript memory disappears when the page reloads. The finished Code Page therefore does not assume that its in-memorylessonStateis authoritative.

PAGE LOAD
    ↓
Discover App DBID
    ↓
GET tables
    ↓
Find People / Departments / Tasks
    ↓
GET fields
    ↓
GET relationships
    ↓
Reconstruct lessonState
    ↓
Determine completed steps
    ↓
Enable the next valid action

If a student closes the browser after completing four steps and returns tomorrow, every JavaScript value begins asnullagain. The page re-reads Quickbase, discovers what actually exists, and reconstructs its progress.

The finished Code Page contains six schema-changing actions, but not every action is available at the same time.

A disabled button means either the action has already been completed or a prerequisite has not yet been satisfied.

{
  name: "Departments",
  description: "Departments used in Lesson 10",
  singleRecordName: "Department",
  pluralRecordName: "Departments"
}

The most consequential value returned is the new table'sid:

lessonState.departmentsTableDbid = data.id;

Do not reduce the response to a Boolean success flag. Quickbase returns metadata describing the table it just constructed, including properties such as its alias, key field, default sorting, nextFieldId, nextRecordId, storage information, and timestamps.

Immediately after Departments is created, Quickbase already has its system fields even though our code has not yet created Department Name or Location.

{
  label: "Department Name",
  fieldType: "text",
  appearsByDefault: true,
  addToForms: true
}

{
  label: "Location",
  fieldType: "text",
  appearsByDefault: true,
  addToForms: true
}

The lesson intentionally creates the two fields with separate requests so each Quickbase response can be inspected independently and each assigned Field ID can be captured.

The relationship now consumes identifiers produced by the preceding steps. Departments is the parent. People is the child.

{
  parentTableId: lessonState.departmentsTableDbid,

  foreignKeyField: {
    label: "Related Department"
  },

  lookupFieldIds: [
    lessonState.departmentNameFieldId,
    lessonState.departmentLocationFieldId
  ]
}

During development, inspecting Departments returned no relationship, even though Departments clearly participated in Departments → People. Inspecting People exposed the relationship.

Departments
    │
    │ parent
    ▼
People
    │
    └── Related Department
        reference / foreign-key field

Quickbase's relationship endpoint is oriented around the child table containing the reference field. Therefore People exposes the Departments → People relationship.

This does not mean Departments is unrelated to People. It means the API representation is centered on the child-side field that physically stores the reference.

After Departments → People is verified, the same construction pattern is reused to create Tasks.

{
  name: "Tasks",
  description: "Tasks used in Lesson 10",
  singleRecordName: "Task",
  pluralRecordName: "Tasks"
}

properties: {
  choices: [
    "Not Started",
    "In Progress",
    "Complete"
  ],
  allowNewChoices: false
}

The second relationship reverses People's role. People was the child of Departments; now People becomes the parent of Tasks.

{
  parentTableId: lessonState.peopleTableDbid,

  foreignKeyField: {
    label: "Related Person"
  },

  lookupFieldIds: [
    lessonState.personNameFieldId
  ]
}

The Code Page discovers the People Name Field ID rather than assuming it is FID 6. Quickbase then creates the relationship support fields in Tasks.

The JSON output area in the Code Page is not merely debugging output. It deliberately separates what JavaScript requested, what Quickbase returned, and what identifiers JavaScript retained.

{
  request: {
    method,
    endpoint,
    payload
  },

  quickbaseResponse: {
    ...
  },

  capturedLessonState: {
    ...
  }
}

{
  whatOurCodeExplicitlyRequested: {
    ...
  },

  whatQuickbaseCreatedForTheRelationship: {
    ...
  },

  quickbaseResponse: {
    ...
  },

  capturedLessonState: {
    ...
  }
}

The completed schema contains fields from several different origins. Understanding that provenance is one of the central objectives of this lesson.

The last POST returning HTTP 200 is not enough. The Code Page re-inspects Quickbase and declares the lesson complete only when the resulting schema can actually be discovered.

Departments
     ↓
People
     ↓
Tasks

Finish by returning to the Schema Explorer. Lesson 9 and Lesson 10 now form a closed loop: inspect, construct, then inspect again.