Frontline organizes work around a few building blocks. Objects hold the main things you care about, like people and companies. Record types let you specialize those objects without splitting your data. Fields are the details on each record. Tables are simpler lists for supporting data. Activities, notes, files, and to-dos sit on top of records so history stays attached to the work, not buried in someone’s inbox.

You do not start from a blank page. Every Frontline workspace ships with four standard objects: People, Companies, Deals, and Tickets. Those four cover the core of most B2B teams. You can extend them with your own fields, and you can add custom objects when your business has something those four cannot represent. You can also add tables when you need a straightforward list that does not need a full CRM treatment.

Think of it this way. Objects are the nouns of your business. Fields are the details that describe them. Record types are the flavors of the same noun. Relations are the sentences that connect them. Once you see the model that way, setup stops feeling abstract.

In a traditional CRM, a messy data model mostly hurt reporting. In Frontline it also shapes the AI that works alongside your team. Max reads your objects, your fields, and the activity on each record. If a client lives in three different places, or if a new mandate is stored as a note on a person instead of a Deal, Max cannot give you a clean picture of risk. The data model is what makes the assistant useful.

It also keeps the team aligned. Advisors, operations, and client service can open the same Company and see the same people, the same open opportunities, and the same service requests. Nobody has to ask which spreadsheet is current.

Imagine a wealth management firm bringing on a new household. Harrington Family Office is a Company. James Harrington is a Person there, with his work email and role on the record. There is an open Deal for a $12 million discretionary mandate, linked to both James and the family office. Last week James emailed about a beneficiary change, which opened a Ticket. All of that lives in one connected picture.

Frontline already does a lot of this stitching for you. When you add a person with a work email, Frontline can find or create the matching Company from the email domain. Emails and conversations attach to the person, and the company timeline picks up that activity. Last interaction dates stay current without a custom field. You should not rebuild those pieces. The model is designed so you extend it, not recreate it.

Most teams should live in the four standard objects for as long as they can. People are individuals. Companies are organizations. Deals are opportunities moving through a pipeline. Tickets are requests that need a status. Those objects already know how to talk to each other. A person belongs to a company. A deal and a ticket can each belong to a company and link to several people.

Create a custom object when you have a first-class thing in the business that is not a person, company, deal, or ticket. A wealth firm might add Households or Trusts. A property manager might add Buildings. A clinic might add Locations. Custom objects get the same treatment as the standard ones: fields, record types, views, notes, and relations.

Use a table when the data is supporting material. A list of model portfolios, a fee schedule, a set of custodian codes. Tables are closer to a spreadsheet. They do not have record types, and they do not carry the same activity history. We will go deeper on tables later in this course. The decision to remember now is simple. If the thing has a lifecycle, owners, and a story, it is an object. If it is a reference list, it is a table.

Before you add fields or extra objects, write down the nouns your team already uses. If people say “account” or “family office,” that is probably a Company. If they say “opportunity” or “mandate,” that is a Deal. If they say “prospect,” that is usually still a Person, just at an earlier moment in the relationship. That last point matters. In Frontline, a prospect and a client are often the same person in different record types, not two separate databases. Converting a prospect means changing the type, not copying the record.

Resist the urge to model every report as its own object. If you need “last emailed” or “relationship strength,” check whether Frontline already computes it. People and Companies keep last interaction current. Companies also carry connection strength. Building a parallel field creates two sources of truth, and the AI will not know which one to trust.

A healthy Frontline data model feels small on purpose. You can explain it in a minute. People work at companies. Deals and tickets attach to both. Custom objects appear only when the business truly needs them. Fields are named the way the team talks. Record types split a process without splitting the data.

When that is in place, everything else in this course gets easier. Objects will make more sense. Record types will feel like a design choice instead of a workaround. Views, user groups, and the work you later do with Max all sit on this foundation.

Next, we will look at objects in detail: what they are, how the four standard ones behave, and when to add your own.