Salesforce Objects, Fields, and Relationships

Lesson 1 established that Salesforce is a metadata-driven platform you configure. Now that configuration meets the CRM fundamentals: Salesforce's data model is where the abstract idea of companies, people, leads, and deals becomes specific objects you work with every day.

Recall from the platform lesson that in Salesforce, everything is built from objects (tables of records) and fields (the columns on them), all defined as metadata. The data model is the collection of those objects, the standard ones Salesforce provides and the custom ones you add, and the relationships that link them.

This is the heart of practical Salesforce work. An administrator spends much of their time shaping this model: which objects, which fields, how they relate. And it is the direct realization of the CRM data model from the fundamentals, so you already know the concepts; this lesson attaches the Salesforce names and mechanics to them.

The lesson covers:

• Standard objects: the CRM model Salesforce ships with.
• Fields and record types: how records carry information and vary.
• Custom objects: extending the model to your business.
• Relationships: how objects link, lookup versus master-detail.
• Lead conversion: the specific mechanic that turns a raw prospect into a real relationship.

The framing: learning Salesforce's data model is learning how the universal CRM model is expressed in this specific platform, and once you have it, the daily work of Salesforce, and much of the admin job, becomes concrete.

Salesforce ships with standard objects, the common business entities every CRM needs, maintained by Salesforce so they stay compatible with each release. These are the CRM fundamentals' core objects under their Salesforce names, and you will recognize them:

• Account: a company or organization you deal with, customer, prospect, partner. (The fundamentals' "Company.")
• Contact: a person, usually one who works at an Account. (The fundamentals' "Person.")
• Lead: an unqualified prospect not yet linked to an Account or Contact. (The fundamentals' "Lead.")
• Opportunity: a specific potential deal, with an amount, stage, and close date. (The fundamentals' "Deal.")
• Case: a customer issue or support ticket, the heart of Service Cloud.
• Activity: Tasks and Events, the logged interactions, calls, emails, meetings, against the records above.

These come "out of the box," already related to each other in the sensible ways the fundamentals described: an Account has many Contacts, an Opportunity belongs to an Account, and so on. Because Salesforce maintains them, they inherit new features automatically and require little upkeep.

The practical significance: a brand-new Salesforce org can run a real sales process on day one using only standard objects, because the standard model is the CRM model. Most companies start here, and a large share of Salesforce work is configuring these standard objects, adding fields, adjusting layouts, setting up the pipeline on Opportunity, rather than inventing new structures.

So the standard objects are your foundation and your default. You reach past them only when your business needs to track something the standard model does not cover, which is where custom objects come in, but always ask first whether a standard object, perhaps with a few added fields, already fits.

Objects are tables; fields are their columns, the individual pieces of information on each record. An Account has fields like name, industry, phone, and owner; an Opportunity has amount, stage, and close date. Every field is defined as metadata, and this is where much day-to-day customization happens.

Fields come in types that shape and constrain the data, and choosing the right type is a real modeling decision:

• Text, number, date, checkbox: the basics.
• Picklist: a fixed list of choices (an Opportunity's Stage is a picklist). Picklists enforce consistency, everyone picks from the same values, which directly serves the data-quality discipline from the fundamentals.
• Formula: a field whose value is calculated from other fields, not entered. It updates automatically and is never stale.
• Lookup / master-detail: relationship fields that link to another object (the next step).

Custom fields are how you extend a standard object without a new object. If your sales process needs a "Contract Renewal Date" on Account, you add it as a custom field, minutes of configuration, no code. This is the most common customization of all, and it is why two companies' Salesforce orgs, both using the standard Account, can look quite different: they have added different fields.

Record types add another layer: they let one object behave differently for different situations, offering different picklist values and page layouts. For example, one Opportunity object can have a "New Business" record type and a "Renewal" record type, each showing the relevant fields and stages. Record types let you model variations of a thing without duplicating the object.

The takeaway: most of shaping a Salesforce data model is adding and configuring fields on standard objects, choosing types that enforce good data, adding the custom fields your business needs, and using record types for variation. It is configuration, not code, and it is the everyday craft of the admin.

When your business needs to track something the standard objects do not represent, you create a custom object, a new table, defined entirely by you as metadata, that behaves like a standard object but models something specific to your company or industry.

Examples: a software company might add a custom "License" object; a university a "Course" object; a property firm a "Unit" object. None of these is a standard CRM entity, but each is central to that business, and Salesforce lets you add it declaratively, with its own fields, relationships, page layouts, and tab, without writing code.

The important discipline, which distinguishes a good admin, is when to create one:

• Extend a standard object (add fields) when you are tracking more information about an existing entity. Extra details about a customer belong as fields on Account, not a new object.
• Create a custom object when you are tracking a genuinely new kind of thing that has its own records and its own relationships. Licenses, courses, and properties are new entities, so they earn their own object.

Getting this right matters because the data model is the foundation everything else sits on, reports, automation, page layouts. A well-modeled org, standard objects where they fit, custom objects only for genuinely new entities, extended thoughtfully with fields, stays clean and comprehensible. A poorly modeled one, custom objects created carelessly, or data crammed into the wrong place, becomes a tangle that is painful to report on and automate.

The unifying principle: model your business's real structure using standard objects by default and custom objects where genuinely needed. Custom objects are what make Salesforce fit any industry, and they are also where inexperienced admins most often overbuild. The skill is knowing that the best data model is the simplest one that faithfully represents how the business actually works.

The CRM fundamentals stressed that a data model is a graph, objects linked together, and in Salesforce those links are relationship fields. How you relate two objects is a genuine design decision, and Salesforce offers two main kinds with an important difference.

• Lookup relationship: a loose link. One record points to another, but they remain independent. A Contact has a lookup to its Account, but if you delete the Account, the Contact can survive (Salesforce just clears the link). Use a lookup when the two records are related but can exist on their own.
• Master-detail relationship: a tight, dependent link. The "detail" record belongs to its "master" and cannot exist without it, delete the master and the details are deleted too. The child's ownership and sharing are controlled by the parent, and, usefully, the master can hold roll-up summary fields that automatically aggregate the details (for example, an Account showing the total value of its related custom records). Use master-detail when the child is genuinely a part of the parent.

The distinction is essentially ownership and lifecycle: does this child stand on its own (lookup), or is it truly a component of its parent that should live and die with it (master-detail)? For a custom "License" tied to an Account, master-detail may fit, a license without a customer is meaningless, and you would want the account to roll up its licenses. For a link between two independent objects, lookup fits.

Relationships are what let Salesforce assemble the 360-degree view from the fundamentals: because Contacts relate to Accounts, Opportunities relate to Accounts, and Activities relate to all of them, opening one Account surfaces everything connected to it. Choosing the right relationship type, and setting it up correctly, is core data-modeling work, and it is where the abstract graph of the CRM becomes a concrete, navigable Salesforce org.

The CRM fundamentals introduced the deliberate separation of Leads from Contacts, and the moment a raw prospect becomes a real relationship. Salesforce implements this with a specific, important mechanic: lead conversion.

Recall the model: a Lead is a standalone, unqualified prospect, not yet attached to any Account or Contact, deliberately kept in a holding area so unverified prospects do not pollute the real customer data. It is a single record holding a person's details and, often, their company's name, but with no relationships.

When a rep qualifies a Lead, decides it is a genuine prospect worth pursuing, they convert it. Conversion is a built-in Salesforce action that transforms the one flat Lead into the proper, related records of the real data model:

• An Account (the company), created new or matched to an existing one.
• A Contact (the person), linked to that Account.
• Optionally an Opportunity (the potential deal), linked to both.

The single Lead record, having served its purpose, is retired, and in its place stands the fully related structure: a company, a person at that company, and a deal, all properly linked and ready to be worked with the full 360-degree view.

This mechanic is the concrete answer to the fundamentals' question of how a prospect "ripens" into a real relationship, and it is why the Lead object exists as something separate. Understanding conversion matters practically because it is a daily action in most sales orgs, and a frequent source of confusion ("where did my Lead go?", it became an Account, Contact, and Opportunity). It also shows the platform embodying the CRM lifecycle in a built-in feature: Salesforce does not just store leads and contacts, it provides the very transition between them that the fundamentals identified as the first real threshold in a customer's journey.

A qualified Lead is converted into an Account, a related Contact, and an Opportunity; standard and custom objects link via lookup or master-detail relationships, and Activities attach across them, so opening the Account surfaces the full 360-degree view.