Introduction

Every real app needs three layers: a place to store data, rules that decide what happens when that data changes, and a way to react. In a traditional codebase you would write SQL migrations, ORMs, controllers, and cron jobs. The no-code approach replaces those with visual building blocks that produce the same outcome. In this lesson you will pick a database tool, model two related tables, and wire up a workflow that runs whenever a row is created. We will use Airtable as the primary example because its grid view makes relationships easy to inspect, but the same patterns apply to Supabase, Baserow, or Xano.

Setting up your first base

A base is the top-level container that holds your tables. Inside a base, each table is a spreadsheet-like grid where every column is a typed field. Think of a field type as the question you ask a row: a Single Line Text field asks for a short string, a Number field enforces digits, a Date field stores a calendar value, and a Linked Record field points to a row in another table. Choosing the right field type up front prevents bad data from entering the system.

Open Airtable, create a base called "Bookings", and add two tables: "Customers" and "Appointments". Inside Customers add these fields:

Customers
- Full Name      (Single line text)
- Email          (Email)
- Loyalty Points (Number, integer)

Now switch to the Appointments table and add:

Appointments
- Date           (Date)
- Service        (Single select: Haircut, Color, Trim)
- Price          (Currency, USD)
- Customer       (Linked record → Customers)

Notice how the Customer field is not a plain text field that copies the name. It is a link, which means deleting the customer row warns you, filtering the view by customer is instant, and rollup fields can pull the loyalty points across.

Defining data relationships

There are three relationship shapes you will reuse in every project. One-to-many means one parent row owns many children — one customer can have many appointments. Many-to-many requires a junction table — one stylist can serve many services, and one service can be performed by many stylists. One-to-one is rare and usually signals two fields that should live in the same table.

In Airtable a Linked Record field is one-to-many by default. To make it behave many-to-many, allow linking to multiple records on both sides, and Airtable creates the junction automatically. The schema for a Stylist-Service bridge would look like this:

Stylists
- Name        (Single line text)
- Services    (Linked record → Services, allow multiple)

Services
- Name        (Single line text)
- Duration    (Number, minutes)
- Stylists    (Linked record → Stylists, allow multiple)

The symmetric field on each side is what makes the relationship traversable in both directions. If only one side has the link, queries from the other side will silently return nothing — a common source of "my workflow isn't firing" bugs.

Building visual workflows

A workflow is a sequence of triggers and actions that runs without you writing code. The most common trigger is "When a record is created" in a specific table. The most common actions are "Send email", "Create record in another table", and "Update record". A practical workflow for our booking app is: when a new Appointment row is created, automatically update the matching Customer's Loyalty Points by adding the appointment Price.

In Airtable Automations the configuration looks like this:

Trigger:   When record created  →  Table: Appointments
Action 1:  Find records         →  Table: Customers, where Email = {Appointment.Customer.Email}
Action 2:  Update record        →  Table: Customers (the record from Action 1)
                                  Loyalty Points = {Current Loyalty Points} + {Appointment.Price}

The curly-brace tokens are how you pass field values between steps. They evaluate at runtime, so if you later rename a field you must re-select it in the token picker or the workflow will break. Always test with a sample row before turning the automation on for the whole table — automation that fires on every historical row is the equivalent of a runaway script.

Common mistakes and quick checks

Three patterns account for most failures in no-code backends. First, using a Single Line Text field where you needed a Linked Record — you lose referential integrity and rollups stop working. Second, building logic that depends on a field being non-empty without adding a conditional branch, which causes silent errors when the trigger row is incomplete. Third, chaining more than four actions in one workflow without testing each step in isolation; if step three fails, you cannot tell whether steps one and two did their job.

A reliable debugging habit is to add a final "Send yourself an email" action that summarizes every variable the workflow saw. That single line catches 80 percent of mismatched-field bugs because the email body shows the literal token values that were substituted.

Summary

You set up a base with two tables, modeled a one-to-many link between Customers and Appointments, and created an automation that updates loyalty points whenever an appointment is logged. The mental model to keep is: tables store facts, linked fields encode relationships, and automations encode reactions. Tomorrow's lesson will expose this same data to a front-end builder so users can interact with it through a real UI.