A table has fields, the same family of types you just learned: text, numbers, dates, selects, relations, files. It can have saved views and aggregations. You can export it. You can relate a row to a person, a company, or another table. Flows and workflows can read and write it when you need a lookup or a simple update.

It does not have record types. There is no Lead versus Contact inside a table. It does not carry the CRM layer you get on objects: notes, to-dos, and assignment to Frontline users. If you catch yourself wanting to convert a row, log a call on it, or give it an owner, you wanted an object.

Permissions are a little looser, on purpose. An object’s schema is the shared CRM model, so only admins and owners reshape it. A table is owned by the person who created it. Admins, the creator, and anyone given full access can change columns. That makes tables a good place for a team to keep a working list without opening a ticket to change the company model.

Use a table when the row is supporting data. A wealth firm might keep a fee schedule, a list of model portfolios, or a set of custodian codes. A sales team might keep SKUs or campaign codes. Operations might keep a list of office locations that almost never need a meeting logged against them.

The test is the same one from the data model lesson. Would you assign an owner, write a note, and come back to the row next month because the relationship changed? If yes, it is an object. If you only look it up to fill in another record, it is a table.

Harrington Family Office makes this concrete. James is a Person. The family office is a Company. The mandate is a Deal. The beneficiary change is a Ticket. None of those belong in a table. The firm’s model portfolios do. Each portfolio has a name, a risk profile, a minimum, and a fee. Advisors relate James or the deal to “Balanced Tax-Aware,” instead of typing the fee into a text field on every contact. When the fee changes, you change one row in the table. Every linked record still points at the right portfolio.

A fee schedule can work the same way: share class, breakpoint, rate. A custodians list can too, if each custodian is just a code and a name. If a custodian becomes a real relationship, with people, tickets, and a thread of emails, promote that idea to a Company, or to a custom object. Do not stretch a table into a second CRM.

The useful move is a relation. A field on People, Deals, or a custom object can point at a table row. James can have a Model portfolio relation. The deal can have the same. You get a clean label, a place to click through, and one list to maintain.

Do not copy table values into text fields “so they show up on the contact.” That is how the fee on James drifts from the fee on the table. Relate, then show the relation on the view. If you need a number on the deal for a formula, pull it from the related row, or keep a single currency field you update on purpose. Two handwritten copies will diverge.

Tables are also a good input for automations. A workflow can look up a fee, write a row when a new share class appears, or keep a list in sync with an outside system. Because the table is flat, the automation stays simple. You are not converting record types or merging timelines. You are reading a list.

What you should not do is recreate People or Companies as a table. You lose deduplication, email sync, company auto-link, AI profiles, and the activity story. A “Contacts” table is the most expensive shortcut in the product. Use the People object.

Name the table for the list it is. “Model portfolios.” “Fee schedule.” “Custodian codes.” Give it the columns you look up, and stop. A table that grows a status, an owner, a close date, and a notes column is trying to become an object. Listen to that. Move the work before the team invents a process the table cannot support.

Views still help. A fee schedule can have a view per share class. A portfolio list can sort by risk. Aggregations can total minimums or count rows. That is plenty. The richness should stay on James, the family office, and the mandate, where activities and record types already do the job.

If the thing is a person, a company, a deal, a ticket, or another noun with a lifecycle, it is an object. If the thing is a list the objects should reference, it is a table. If you are unsure, start with a select field. Promote it to a table when the list needs extra columns. Promote it to an object when it needs a life of its own.

Get that right and the workspace stays readable. People, companies, deals, and tickets hold the relationships. Tables hold the reference data. Max, your workflows, and a new advisor can all find the fee the same way: on the portfolio row, not buried in a note on James.

Next in this course we will set up views, so the same objects and tables can show a pipeline, a working list, or a filtered board without changing the model underneath.