People is the object. Lead and Contact are record types on People. Both are individuals. Both have a name, a way to reach them, and a company. They do not need the same working surface.

A Lead might need a source, a next step, and a first-meeting date. A Contact might need an onboarding date, a household, a review cadence, and a success owner. If you split those into two objects, you split identity. The same email can exist in more than one place. Activity gets scattered. Max cannot tell a single story about James Harrington at Harrington Family Office, because James now lives in two records.

Record types keep one People object and let each kind of person show the fields that matter. Deals can follow the same pattern later, with new business and renewals. The rule does not change. One noun, more than one flavor.

You will also see a Relationship Type field on People, with values like Lead and Customer. That field is a simple label. It is useful when you only need a badge. Use a record type when Leads and Contacts need different fields, different views, or a real conversion step. A label cannot hide a contact’s household fields from a lead view. A record type can.

Conversion is a type change on the same record. It is not a copy, and it is not a new create. Frontline updates the record’s type from Lead to Contact (or the other way). Everything that already belongs to that person stays: name, email, phone, company, notes, files, to-dos, and the activity timeline.

What changes is the working surface. Lead-only fields stop showing. Contact fields appear, ready to fill in. Views switch with the type, so the team lands on a contact layout instead of a lead list. Values on fields that no longer display are still stored on the record. If you convert back, they are still there.

Unique fields still apply across the whole object. On People, email and phone stay unique even if one record is a Lead and another is a Contact. You cannot have james@harringtonfo.com as a lead and again as a contact. Search first. If James already exists, convert him. If you create a second record, Frontline will treat it as a duplicate, and your team will lose the timeline that already exists.

A normal edit cannot change the type. Conversion is its own action, on purpose, so a casual field update cannot quietly move someone from Lead to Contact. You also need permission to update both the current type and the destination type. The change is written to the audit log as a conversion, so you can see who moved the record and when.

Open the person. Use convert, and choose Contact. That is the whole manual path.

Take the wealth firm from the last lessons. James Harrington starts as a Lead, referred in after a first conversation. His email, the family office, and the early emails are already on the record. There is an open Deal for a $12 million discretionary mandate. When the mandate is signed and the first funds land, an advisor opens James and converts him from Lead to Contact. Nobody retypes the email. Nobody rebuilds the company link. The beneficiary-change ticket from last week is still on his timeline. The team now sees contact fields, like review cadence and household, and can finish onboarding on the same record.

Convert in the other direction only when you mean it. A contact who goes cold can become a lead again. It is still the same person. Do not create a fresh lead “to keep the pipeline clean.” That is how duplicates start.

Manual conversion is right when a person makes the call. Workflows are right when the rule is clear and you do not want the team to remember the step.

In Studio, a workflow can change a record’s type. The action is “change record type.” You point it at the record you already have, and you name the destination type. Frontline then does the same conversion a person would do by hand: same row, new type, history intact.

A common pattern for a wealth team is this. When the Deal linked to a Lead is marked Won, the workflow converts that person to Contact. Another pattern: a completed onboarding form, or a funded account at the custodian, triggers the same change. You can also convert in bulk-style paths, such as after an import review, as long as each step still updates the existing record instead of creating a new one.

Build the workflow so it finds James first, then converts him. Do not create a Contact and hope the lead disappears. Creation and conversion are different actions. If the workflow creates, you now have two people. If it converts, you have one person in the right type, with the mandate, the emails, and the family office still attached.

You can still have a person convert a record that a workflow missed. The two paths are not in conflict. They write the same kind of change.

A field can belong to Lead, to Contact, or to both. Shared fields, like name and email, should live on both types so conversion never feels like data disappeared. Lead-only fields, like source and next step, stay on Lead. Contact-only fields, like household and review cadence, stay on Contact. If you add a field and do not scope it, it will show up on every type. Be deliberate.

Views belong to a record type as well. Leads can open as a table sorted by next step. Contacts can open as a table grouped by advisor or review month. Switching types in the UI swaps the columns you see and the view you land on. The object stays one object. The working surface changes with the job.

Every object has at least one record type. One of them is the default. New records land there unless you choose otherwise. Many teams make Lead the default for People, so inbound names start in the pipeline, then convert to Contact when the relationship is real. The default type is protected, so you cannot rename or delete it while it is still the default. You can still change which fields it shows. If you want a different default, promote another type first.

Record types can also carry their own name, icon, and singular noun, so the UI can say “Create lead” instead of “Create person” when that is the type you are in. Small thing, big difference for a team that lives in the product all day.

Do not create a record type for every filter you wish you had. If the only difference is “prospect vs client” as a badge, that can be a field. Use Lead and Contact as types when the process, the fields, and the conversion actually change.

Do not create a new object because two teams want a different layout of the same person. That is the case record types were built for. A new object is for a new noun. A new record type is for a new flavor of a noun you already have.

And do not use record types to bypass uniqueness. If two teams each want “their own” copy of a contact, the fix is permissions, views, or a conversation about ownership. It is not a second record. Frontline is designed so one person is one person, across the whole object.

If you can say “this is still a person, just a lead or a contact,” use a record type, and convert when the relationship changes. Do that by hand when judgment is required. Do it with a workflow when the rule is reliable, like a won mandate or a funded account.

Get that distinction right and the rest of the workspace stays calm. Fields stay on the types that need them. Views stay readable. Max can follow James from first email to client review without losing the thread. That is the point of record types: same record, sharper process.

Next in this course we will look at fields: the details on each record, which types to use, and what Frontline already keeps for you.