Objects, fields, and relationships

Objects are tables, fields are columns, and relationships link records together. Picking the right relationship type matters most: it decides ownership, sharing, deletion behavior, and whether you can roll values up to the parent.

Objects and fields

• Standard objects: Shipped by Salesforce: Account, Contact, Lead, Opportunity, Case, Campaign, and more. You can add fields to them but can't delete them.
• Custom objects: Objects you create; their API names end in __c. Creating one gives you a tab option, page layouts, list views, and reporting support.
• Field types: Text, number, currency, percent, date, date/time, checkbox, picklist, multi-select picklist, email, phone, URL, text area, and more. Pick the narrowest type that fits so data stays clean and reportable.
• Changing a field type: Possible for many types but can lose data (for example long text to short text truncates). Check dependencies such as formulas and reports first.
• Field history tracking: Tracks changes to up to 20 chosen fields per object and shows old and new values in a related list and in history reports.

Relationship types

• Lookup: A loose link. The child has its own owner and sharing, the lookup can be optional, and deleting the parent normally just clears the field.
• Master-detail: A tight link. The detail record has no owner of its own: it inherits ownership and sharing from the master, the field is always required, and deleting the master deletes its details.
• Roll-up summary fields: Available on the master of a master-detail relationship (and on some standard parent-child pairs such as Account and Opportunity). They COUNT, SUM, MIN, or MAX the detail records, optionally filtered.
• Many-to-many: Built with a junction object that has two master-detail relationships, one to each object. A common example is linking jobs to candidates through job applications.
• Limits worth knowing: An object can have at most two master-detail relationships. Converting a lookup to master-detail only works when every existing record has a value in the field.
• Hierarchical relationship: A special lookup on the User object to another user, such as a custom Manager field.

Formula fields

• What they are: Read-only fields calculated each time the record is viewed or reported on. They don't store a value, so they can't be edited and don't fire automation when their result changes.
• Cross-object formulas: Reference fields on parent records through relationships, such as showing the account's industry on a contact.
• Common functions: IF, CASE, ISBLANK, TODAY, TEXT for picklists, and HYPERLINK. ISPICKVAL tests a picklist value.
• Use a formula when the value can always be derived from other fields. Use a roll-up summary when you need totals from child records.

Schema Builder and picklists

• Schema Builder: A drag-and-drop diagram of objects and relationships. You can view the data model and create objects and fields from it.
• Global value sets: One shared list of picklist values that several picklist fields can use, so they stay identical.
• Dependent picklists: A controlling field filters the values available in a dependent picklist, for example Country controlling State.
• Restricted picklists: Only accept the defined values, even through the API, which keeps imports from adding stray values.