The four standard objects ship with fields you should not recreate. People already has name, email, phone, role, company, and last interaction. Companies already have website, industry, and connection strength. Deals already have stage, value, and last status change. Tickets already have status and last status change.

Some of those fields are maintained for you. A person’s name is built from first and last. Last interaction moves when activity lands. A company’s logo and social links can fill in from the domain. If you add “Last emailed” or “Account health,” you now have two sources of truth. Check the object first. Add a field only when the business has a fact Frontline does not already store.

Every field has a type. The type is not decoration. It is what makes the value searchable, usable in views, and readable to Max and your workflows.

Text is for words. A short line is right for a source, a nickname, or a role. Turn on a longer area when you need a description. Email, phone, and URL are still text, with a format that validates the value and makes it clickable. Use those formats instead of a plain box. A phone stored as free text will not match, call, or deduplicate the way a phone field will.

Number is for counts, percents, and money. A mandate value and an AUM figure should be currency, not a sentence. Percents stay percents. Integers stay whole. If you type “twelve million” into a text field, you cannot total it on a view or use it in a formula.

Date is either a day, like a review date, or a date and time, like a meeting. Yes or no is for a true binary, such as “IPS on file.” If you find yourself adding “maybe,” you wanted a select.

Select is a short, stable list you control: lead source, risk tolerance, mandate type. One value or several, depending on the field. Options get a name and a color, and they show up as badges. Relation is different. Use it when the value is another record you might open, like Company on a person, or a model portfolio that has its own row. If the list grows, has extra data, or needs a timeline, it is a relation, not a select.

User fields point at people in your Frontline workspace. That is how a lead gets an advisor, and how a ticket gets an owner. The built-in Users field on People, Deals, and Tickets is this type.

File holds an attachment on the record. Avatar is the image on the record, and on Companies it is often filled in for you. Formula calculates from other fields, the way a spreadsheet would, and it updates when the inputs change. Use a formula for something like a fee from AUM, not for a fact a person should type. Formula fields are read-only.

Once a field exists, its type stays put. You can rename it, make it required, or change options on a select. You cannot turn a text box into a select later. If you picked the wrong type, create the right field, move the values, and retire the old one.

Required means the record cannot be saved empty. Unique means the value cannot repeat on that object. You can set both on fields you add. Unique is object-wide. It does not reset per record type, per view, or per owner.

On People, email and phone are unique by design. That is system behavior, not a setting you turn on. Email is the primary identity. Phone is the second. Frontline uses them to keep one person as one person. If James Harrington already exists with james@harringtonfo.com, you cannot create another Lead or Contact with that email. The same is true for his phone number. A second create is treated as a duplicate, not as a new row.

That rule holds across Lead and Contact. Uniqueness does not care which type he is. Converting James from Lead to Contact does not free the email for a new record. It is still the same person, with the same email and the same phone. Search first. If he is there, convert him or update him. Do not invent a second James so each team can “have their own.”

Phone has one more system behavior. Frontline stores a normalized version of the number in the background so formats like (212) 555-0142 and +1 212 555 0142 count as the same person. You work with the phone field you see. The matching is handled for you.

Do not add a second “Work email” or “Mobile” and mark those unique as a workaround. You will fight the identity the platform already enforces. Extra emails or phones, if you need them, are extra facts, not a second key. Leave Email and Phone as the system keys, and convert when the relationship changes.

You can still put unique on a custom field when the business needs it. A client number on Contact, or an account code on a Company, is a fair unique. Just know you are adding a rule for the whole object, every record type included.

A new field can land on every record type, or on one. Source and next step belong on Lead. Household, review cadence, and IPS on file belong on Contact. Name, email, and phone belong on both, so conversion never feels like data vanished. If you add “Review cadence” and forget to scope it, it will show up on every lead. Be deliberate.

Name fields the way people say them out loud. “Review cadence,” not “review_cadence.” “Lead source,” not “src.” The label is what the UI, the API, and Max will use.

On People, James already has first name, last name, email, and phone. Those last two are unique across the firm. As a Lead he also shows Source and Next step. After conversion, those lead fields leave the layout. Contact fields appear: Household, Review cadence, IPS on file. The email did not move. The phone did not move. The company did not move. Only the visible facts changed.

On the Deal, Value is currency and Stage is a select. You might add Mandate type as a select, and Expected funding date as a date. You would not add “Client email” on the deal. That email lives on James, and it is already unique there. You would not add “Last call date.” That is last interaction, driven by activities.

On Harrington Family Office you might add a custodian as a select if the list is short, or a relation to a Custodians table if each custodian has more than a name. The next lesson is about that choice.

A healthy field list is boring in the best way. Types match the data. Lead and Contact each show what they need. Email and phone on People stay the system keys, unique across every type. Nothing duplicates a field Frontline already computes. Nothing stores a conversation that belongs on the timeline.

If you are unsure, write the question on a notepad. “What is James’s review month?” is a field. “What did we say on Tuesday?” is an activity. “What is our fee schedule for every share class?” is probably a table.

Next we will look at activities: the history that fills in around records once the fields and model are in place.