ave you ever wanted to roll your eyes when you hear someone use the term "Architecture"? It may sound like a bunch of hand waving or a shortcut to say "you wouldn't understand". But it's important for everyone to align on good architecture, which all boils down to objects.
Primer for Objects in Salesforce
Objects are data containers designed to hold similar items or concepts. For example, the Contact object is filled with only people. Similarly, 'deals' are stored in the "Opportunity" object, and 'companies' in the "Account" object.
These Objects are data containers designed to hold similar items or concepts. For example, the Contact object is filled with only people. Similarly, 'deals' are stored in the "Opportunity" object, and 'companies' in the "Account" object.
These containers are purpose-focused, having standardized sets of information for describing a certain thing.
'Object Oriented'
I say 'purpose focused' as a more intuitive description for what a tech person might call "object oriented". In either case, what is meant, is if you have a data point, it's very important to think of what "object" it describes DIRECTLY - so a 'Start Date' usually belongs on an Opportunity, not an Account, since the Account might actually 'start' more than once, but the Opportunity usually is what has unique start/end dates. We don't overlap data on different types, we connect them "relationally".
'Relational'
Think of the data like a spreadsheet, but with separate tabs for separate types of things. So all your companies are on one tab, all your deals on another, all your Contacts on a third. Each row on the tab is a "record", describing one of that thing. So you could have an "Account record" which is one company. Every record in Salesforce has a unique ID (one of its columns/fields). So when a Contact record wants to specify its Account/company, they'd have a field that holds ID of the Account, essentially pointing at it.
The above actually is a totally basic explanation of any "relational database", meaning 'object-oriented, separated by relationships'. If you've heard of SQL databases, the above is a total non-tech attempt at explaining exactly what SQL (or any relational database) is.
How to look at objects in Salesforce
Practically, in Salesforce, you're looking at these 'spreadsheet tabs' in the UI at the top of the page. So if I want to see my company data, I'm clicking the Accounts tab. At which point, I see my list view. If you ever wanted to visualize these relationships, you can have an admin look up the Schema Builder in the Setup tab:
Object design is architecture design
It may seem to be overthinking things, but being a stickler for "object-oriented" architecture, where we are very thoughtful about where data belongs, is truly the foundation for clarity, organization, and data completeness.
Custom Objects
Also - remember - the starting data model in Salesforce is just a jumping off point. If you have additional teams and workflows you'd like to add, consider installing our custom object for Operations in Salesforce.
