Object Manager and Lightning App Builder
Objects, fields, relationships
Standard objects ship with Salesforce; custom object API names end in __c. Choose the relationship deliberately: a lookup is loose (child can exist without a parent, no cascade delete, no roll-up summaries), a master-detail is tight (parent required, sharing inherited, cascade delete, and roll-up summary fields allowed on the parent). Roll-up summaries exist only on the master side of a master-detail relationship.
Formula fields recalculate and cannot be edited by users, and cannot be used as an external ID. Global value sets are shared across objects and fields, so editing one changes every consumer. Dependent picklists allow one or two controlling fields.
Layouts versus Lightning pages
This is the most common trap in the domain. Page layouts are assigned to profiles and record types and control fields, buttons, and related lists in the classic sense. Lightning record pages are built in Lightning App Builder and activated by app, record type, and profile for org default or app default. Changing a page layout does nothing to a Lightning record page that overrides it, and Dynamic Forms (individual field components) exist only on Lightning record pages, never on page layouts.
Worked example
An admin marks a picklist required on the page layout, but users still save records without a value. Layout-required is enforced only in the UI for that layout; an API insert, a data load, or a different record type's layout bypasses it. Fix it by making the field universally required at the field level or by adding a validation rule.
Rule of thumb: layout = what it looks like; field definition = what is allowed; record type = which picklist values and layout apply, and to whom.