Every account comes with four standard objects. They cannot be deleted, because the rest of the product is built around them. You can add fields, change views, and create record types on top of them. You should almost never replace them with a homemade version of the same idea.

People are the individuals you talk to. A person has a name, email, phone, role, and a link to a company. Frontline treats email as the main identity, so the same person does not get created twice just because they showed up in another channel. People also pick up activity automatically. When email or WhatsApp is connected, conversations attach to the person. Meetings can do the same. Over time, the record holds more than contact details. It holds a timeline, a short AI summary, and the facts Max has learned, like a preference or a risk.

Companies are the organizations those people belong to. A company has a name, a website, firmographic details, and a logo Frontline can fetch for you. The important relationship is the one with People. If you create Sofia Alvarez with the email sofia@mercadolibre.com, Frontline can find Mercado Libre by that domain, or create the company and link her to it. You do not need to build that link by hand in the common case. The company timeline also inherits communication from the people attached to it, so you can see the account’s story in one place.

Deals are the opportunities you are trying to win. Each deal has a name, a stage, a value, and owners. Deals default to a kanban board grouped by stage, which is why they feel like a pipeline the first time you open them. A deal belongs to one company and can link to several people. That is how you keep the economic buyer, the champion, and the legal contact on the same opportunity without cloning the deal.

Tickets are requests that need a status. A billing question, an implementation blocker, a product bug that a customer is waiting on. Tickets default to a board grouped by status, with stages like New, On You, On Customer, On Hold, and Closed. Like deals, a ticket belongs to one company and can link to several people. That is what lets support and sales look at the same account without keeping two versions of the truth.

The standard objects are already related. A person belongs to one company. A deal belongs to one company and can include many people. A ticket works the same way. From a company record, you can see the people, the open deals, and the open tickets. From a person, you can see their company and the deals or tickets they are part of.

That graph is the reason you should not create a second “Accounts” object or a custom “Contacts” table. The connections, the activity, and the AI profiles already live on People and Companies. A parallel object splits the story. Max will update one side and miss the other.

Here is a full pass through a real week. Visa is a Company. Kate Chen is a Person there. There is a Deal for a new seat expansion, sitting in In Progress. After a demo, Kate goes quiet. Max can see that the last interaction is aging and that messages are unanswered, then surface the risk on the account. If Kate later writes in about a provisioning issue, that becomes a Ticket linked to the same company and the same person. Nobody copies data between tools. The objects already share the record.

Every object, standard or custom, can hold more than a row of fields. You can save views so a pipeline, a table, or a filtered list is one click away. You can log notes, calls, and meetings. You can attach files and assign to-dos. You can relate a record to records on other objects. And you can split the object into record types when one object needs to serve more than one process. The next lesson covers record types. The point for now is that an object is a living entity, not a spreadsheet tab.

Standard objects also do work in the background that custom objects will not copy for you. People deduplicate on email and phone. Companies enrich from their domain. Last interaction stays current. Connection strength on a company is computed, not typed in. If you find yourself creating a field named “Last emailed” or “Account health,” pause. Frontline may already be keeping that for you.

Create a custom object when the thing you are tracking is a first-class part of the business and it is not a person, a company, a deal, or a ticket. A real estate team might add Properties. A logistics team might add Shipments. A services firm might add Engagements. Those records need owners, fields, views, and a timeline of their own. They should also link back to People and Companies so the account picture stays whole.

Do not create a custom object for a status, a tag, or a report. Those are fields. Do not create one for emails or conversations. Those are activities. Do not create one because two teams want a different layout of the same contact. That is a record type, or a view, on People.

If the data is a flat reference list with no real lifecycle, a table is usually the better fit. We will cover tables later. A good test is this: would you assign an owner, write a note, and come back to the record next month? If yes, it is an object. If you only look it up to fill in another record, it is probably a table.

The teams that get the most from Frontline can name their objects in one breath. People, Companies, Deals, Tickets, and maybe one or two custom objects that are unique to the business. That small set is what Max learns, what new hires learn, and what your automations run on.

If you are unsure where a new idea belongs, start with a field on an existing object. Promote it to a custom object only when it has enough of its own data to deserve a home. It is much easier to grow a clean model than to merge two objects later.

Next, we will look at record types: how one object can support more than one kind of record without breaking the model you just built.