Define your data model

You have met the four ideas: objects are the tables, attributes the columns, records the rows, lists the working sets. This article puts them together. Rather than abstract advice, we will set up a workspace for a concrete business — an event venue — and narrate every decision.

Start from the questions, not the data

The wrong way to design a data model is to list everything you could store. The right way is to list the questions you ask every week, and work backwards to the structure that answers them. Our venue asks three:

1. Which event inquiries are live, and what stage is each at?
2. Which corporate clients keep coming back — and who is our contact there?
3. Whose deposit is overdue?

Each question points at one piece of structure: a pipeline of events, company records with people attached, and a working list for deposits. That is the whole model — three decisions.

Worked example: an event venue

Step 1 — let People and Companies do their jobs. No custom work needed here. When Anna from Northfield Consulting emails about a summer party, she becomes a person record, Northfield becomes a company record, and the two are linked. Next year, when someone else from Northfield inquires, the company record already shows last year's event, what was quoted, and how it went. Question two — which clients keep coming back? — is answered by structure the venue never had to build.

Step 2 — run inquiries through the Events object. Each inquiry becomes an event record: date, headcount, the person and company behind it. Viewed as a kanban grouped by stage — Inquiry → Site visit → Proposal sent → Confirmed — the Events object becomes the venue's pipeline, and question one is answered at a glance. Two attributes earn their place as AI attributes: headcount and preferred date come up naturally in email conversations, so Winston fills them in from the timeline instead of someone re-reading threads to copy numbers into cells.

Step 3 — make deposits a list. A deposit is not a new kind of thing, so it does not get an object; it is a job attached to confirmed events, so it gets a list. Deposits to collect holds every confirmed event, with two list attributes — deposit due date and paid? — that belong to the chasing work, not to the event itself. Filter the list to due date passed, not paid, save that as a view, and question three has a permanent answer: Overdue deposits is one click, every morning, forever.

Rules of thumb

• New kind of thing → object. Its own columns, its own lifecycle, other records pointing at it. (Events: yes. Deposits: no.)
• Fact about every such thing → attribute. And if the fact shows up in conversations — headcount, budget, dates — make it an AI attribute and let Winston keep it filled.
• Job to work through → list. With list attributes for anything that belongs to the job rather than the record.
• When in doubt, wait. Start with the standard objects and one list. Add structure when a real weekly question demands it — a model that grew from questions stays clean; one designed up front on day one rarely survives contact with reality.

If you want to see custom objects and relationships built end to end, the lesson below walks through one on screen. And if this section was your first pass through the data model, understanding the data model is worth a re-read now — it is a different article once you have seen the pieces used.