Salesforce Data Model Fundamentals

Objects are akin to tables in a relational database. Each object stores records (rows) described by fields (columns). A single record is one instance of the thing: one company, one person, one deal.

Objects come in two kinds:

• Standard objects are pre-built by Salesforce and represent common business entities. The ones you will meet everywhere:
• Account: a company or individual you do business with
• Contact: an individual person, usually associated with an Account
• Opportunity: a sales or business opportunity: a potential deal moving through stages
• Case: a customer service request or issue (the heart of Service Cloud, as you saw in Module 2)
• Lead: a person or company that might become a customer, before qualification
• Custom objects are created by admins to store business data that does not fit the standard objects: anything from Volunteer Shifts to Grant Applications to Solar Installations. Custom objects are created through the Setup menu, and by convention their names appear with a __c suffix in technical contexts.

The first data-model instinct to build: when a stakeholder names a thing their business tracks, ask yourself whether it maps to a standard object or needs a custom one. Reusing standard objects where they fit is almost always preferred: they come with built-in functionality, reporting, and ecosystem compatibility that custom objects have to earn.

Fields hold the actual data on a record: the attributes, the columns.

• Standard fields come pre-defined on every standard object: Name, Created Date, Phone, Email, and so on.
• Custom fields are user-defined additions to standard or custom objects. When you create one, you choose its type, and the type determines what data it can hold and how it behaves: text, number, currency, date, checkbox, picklist (a predefined dropdown of values), and lookup (a pointer to another record, which is really a relationship in disguise: more below).

Field-type choices sound technical but are packed with business meaning, which makes them BA territory. A "Status" field as free text produces seventeen creative spellings of "In Progress" and useless reports; the same field as a picklist produces clean data and clean dashboards. When you gather requirements, capture not just what needs to be stored but what values are valid, who sets them, and how they will be reported on. Those answers drive field design.

Records rarely live alone. Relationships link objects together and create associations between different types of data: this Contact belongs to that Account; this Opportunity is for that Account. Two core relationship types do most of the work in any org:

• Lookup relationship: one object references another, similar to a foreign key in a relational database. The connection is real but loose: the two records have independent lifecycles. Example: an Account with multiple associated Contact records.
• Master-detail relationship: a stronger bond where the child (detail) record's lifecycle is tightly coupled to the parent (master). If the parent record is deleted, the child records are deleted with it. The child typically inherits ownership and sharing from the parent as well. Example: a Property record (master) with multiple Offer records (details) from prospective buyers: delete the property listing, and its offers go with it.

The lookup-versus-master-detail decision is one of the most consequential in any data model, and it is driven by business logic, not technical preference. The question a BA should ask stakeholders: "Can this child thing exist meaningfully on its own, without its parent?" An Offer without a Property is meaningless (master-detail). A Contact whose Account closes might still matter to the business as a person (lookup). Getting this wrong in either direction causes pain: too-tight coupling deletes data the business wanted to keep; too-loose coupling orphans records and breaks roll-up reporting.

Record types let one object serve several distinct business processes. They allow different picklist values, page layouts, and business processes for different kinds of records within the same object.

Example: a university tracks both undergraduate and graduate applications on one Application object. The processes differ, the stages differ, the required information differs, but the thing is the same. Two record types on one object handle it cleanly, where the alternatives (two custom objects, or one object cluttered with fields only half the users need) are worse.

For a BA, record types are the answer to a pattern you will hear constantly in discovery: "Well, it works that way for this kind, but differently for that kind." When variations share a fundamental identity, record types; when they are truly different things, separate objects. Capturing which variation applies, and what differs between them, is requirements work.

Page layouts control the organization of fields, sections, related lists, and buttons displayed on the user interface for an object. Same data, different presentations: a sales rep might see pricing sections a service agent never needs.

Layouts matter to BAs because they are where the data model meets the actual human. Requirements like "the intake team needs the eligibility fields front and center" or "volunteers should not see donor giving history" are layout (and security: Module 7) requirements. During UAT (Module 12), layout complaints are among the most common feedback, and among the cheapest to fix if caught early.

Schema Builder is a visual tool that shows all the objects, fields, and relationships in a Salesforce org. You can navigate the entire data model graphically, and even create new objects, fields, and relationships directly on the canvas.

For a BA, Schema Builder is primarily a reading tool, and a wonderful one: it is the fastest way to answer "what does this org actually look like?" during discovery of an existing implementation. Pair it with the reverse-engineering technique from Module 3 when documentation is missing: the schema is the ground truth.

These two components store configuration data: settings that applications use, as opposed to business records.

• Custom metadata types hold metadata-level information that can travel across environments: when configuration is deployed from a sandbox to production, custom metadata records can move with it.
• Custom settings store application-level settings that code (Apex, Salesforce's programming language) can access efficiently.

A BA needs only recognition-level knowledge here: when an architect says "we'll put the fee schedule in custom metadata so we can deploy it," you should understand that they are storing configuration (the fee rules) as data that moves between environments, rather than hard-coding it. The business benefit: rules can change without code changes. If stakeholders have values that change periodically (rates, thresholds, mappings), mention them to the architect: they are candidates for exactly this treatment.

3. External Lookup. Links a child object (standard, custom, or external) to a parent external object: an object whose data actually lives outside Salesforce and is viewed through a connection rather than imported. Example: an external Business Partner account linked to an internal Account record as well as an external Sales Orders object.

4. Indirect Lookup. Links an external child object to a parent standard or custom object inside Salesforce, used when the two systems' IDs do not match: the link is made on another unique field instead. Example: linking order records from an external sales platform to a parent Account in Salesforce when the customer IDs differ between the two systems.

(External and indirect lookups matter whenever a client keeps some data in another system: an external ERP, an order platform, a legacy database. If discovery reveals "that data stays in the other system," these are the relationship types the architect will reach for, and your requirement should capture which fields link the systems.)

5. Many-to-Many. Links multiple records of one object to multiple records of another, built from two master-detail relationships through a junction object in the middle. Example: assigning speakers to conference sessions via a "Session Speaker" junction object, allowing one speaker to speak at multiple sessions and one session to feature multiple speakers. The junction object is the pattern to recognize: whenever the business says "many of these relate to many of those," a junction object (which often accumulates its own useful fields, like "role" or "date assigned") is the standard answer.