We step into our digital world of Salesforce. The digital realm is based on logic, on zeros and ones, ensuring that an action will trigger a reaction (unless something goes awry with the Flow, and we receive a charming red error message). It is a bit like digital karma; every action will return to you. Through our actions in the system, we can adjust the rules of digital karma. However, the rules work on certain conditions, and to meet these conditions, structure is important.
The structure of Salesforce is fairly simple. It is based on the main elements, which are the skeleton of this system, with additional elements attached to it.
So, what comprises the main elements? Let us start with objects.
On Cloudy Street, there stands a house. This house is quite ordinary – single-story, built from old (soulful) bricks, and on the door of the house, the name Salesforce is written. If we enter this house, the first thing that catches our eye will be the furniture, which adds warmth and the impression that someone lives in the house.
The same is true with objects; they furnish our CRM, and thanks to them we can enter accounts and contacts. And just like with items of furniture, there are those that are standard, such as a sofa or dining table, and those that are custom, such as a hand-shaped armchair or a bathtub that looks like a pirate ship. Standard objects are given right upon entering a fresh Salesforce, and custom objects, well, only imagination limits us in what we want to create. But what would happen if these objects lived without interactions among themselves – for example, the sofa would only be for sitting and staring at the wall, and you couldn’t watch Netflix or read your favorite book on it? Objects need to have relations among themselves. We connect them in business chains, and although, for instance, there is no connection between Case and Opportunity, we can easily create one. It will enable attaching the opportunity of a sold product to a complaint. Salesforce has provided the opportunity for objects to “date” each other. The idea behind this is connecting objects to create something much larger.
The object is characterized by something, primarily its name and the fields that are located on it. This is the unique DNA of every object. These fields define what data the object is supposed to collect. They can be modified by administrators in any way they see fit. Records in the system are created in the likeness of the original – in other words, the recorded fields on the page layout of a given object. Is that all? Of course not (sorry!). Everyone is entitled to a bit of privacy, records included. By using the appropriate settings, we are able to set user access to specific records. Good filtering will set visibility only on desired records. Salesforce is an exceptionally open system (in this safe manner), allowing the system to connect with external tools, (i.e., integrations). With the right API settings, Salesforce could even brew us coffee in the coffee maker if only it had internet access and an open API. And who watches over all this? We do, the Administrators, Consultants, and Developers. But what kind of care would it be if it weren’t of the highest quality? And here is where best practices come in; thanks to them, you know what to do and in what order. Salesforce shares its best practices at every step, in trailheads, knowledge articles, and other aids, and importantly, we also share this knowledge with you in this book. Use these aids every time you do not know how to carry out certain changes.
But the structure needs to be available somewhere and needs to be accessible. That is why Salesforce brings us applications. We’ll learn more about these in the next section.