Apologies for the long break between posts!  One of my New Years resolutions is going to be to try to write up a new one at least every 2 weeks.  For now, I’d like to discuss a topic that is fundamental to understanding how Salesforce is built, Objects and Fields.  As with any platform or structure, the building blocks used to build your data model are essential to understand before the building begins, otherwise someone can destroy it with a single, well aimed shot, sometimes even without a targeting computer.

I also wanted to start a series of #AwesomeAdmin specific posts and when applicable, point out how they apply to the Salesforce Certified Administrator certification as per the study guide.  I’m also going to show you which items you should hopefully have a better understanding of from the study guide at the end of the post.  Keep in mind though, there is no replacement for experience.  Where I can though, I’m also going to try to introduce you to some developer lingo here and there either to give you a head start to learning how to code on the platform, or if nothing else, give you a leg up in communicating with the developers that you’ll inevitably be interacting with.

Standard Objects

In case you didn’t remember my referring to Salesforce as a relational database, it’s important to understand how Salesforce works out of the box.  Essentially, you can think of objects as a sheet in an Excel file with header values in the first row, and each subsequent row as an individual record of that object.  Salesforce comes with many of these objects in each instance and they are referred to as Standard objects since they are standard to every org.  Examples include Account, Contact, Lead, Opportunity, Campaign, Case, etc.  There are many others but we’ll focus on just these for now.

Custom Objects

Custom objects are almost exactly the same as Standard objects with some small exceptions.  All objects come with a Label/Object Name and a Name that is used in the API (Application Program Interface).  The Label value is used when referring to the object in conversation with users and in tabs.  API names though are how an object is referenced everywhere else including in validation rules, formulas, workflow rules, and of course, code!  While Standard Object API names match the Label values, Custom Objects are objects that you create as an admin and Salesforce automatically adds “__c” to the Label value to generate the API name.  For example, the API name of the Account object is Account, where as the API name of a Warehouse object that I create specific to my org would be Warehouse__c.  

Salesforce Classic

Lightning Experience

Objects and Fields

While in Salesforce Classic, Standard and Custom objects were separated in the Setup menu, in the new Lightning Experience, the new Object Manager allows you to view all objects in the SAME place in the SAME way (a refreshing change in my opinion!).  Objects are made up of fields, similar to the header values in your Excel spreadsheet or how buildings are made from bricks.  Just like objects, some fields that come with all objects are referred to as Standard fields and fields that you create are referred to as Custom fields, and also get the “__c” appended to their API names.  All fields also have their own Labels and API Names.  You can’t edit several properties of Standard fields though.

Due to the flexibility of Salesforce, you can create custom fields on standard objects and utilize standard fields on custom objects.  Since they’re out of the box though, standard objects tend to come with more standard fields and additional functionality that isn’t always present with custom objects.  Regardless, collectively they are referred to as Objects, or sObjects (Salesforce objects) when dealing with code.  In the Salesforce universe, you can generally use the term Object and sObject interchangeably.  Think of the term Object as you would the term Shape and specific objects such as Account or Contact like the terms Circle or Square.  From an Object’s home page in Lightning Experience, you can now see virtually all attributes, limitations, and automation for that specific object regardless of whether it is standard or custom.

Fields

A little more information about fields, there are a multitude of field types you can create on any sObject.  Some of the more common ones are outlined below:

• Checkbox (referred to as boolean in code) – can be checked or unchecked
  • Sometimes referred to as True or False
  • Sometimes referred to as 1 or 0
• Currency – monetary value that will default to the default currency type of the owner of a particular record
• Date and Date/Time – Includes month/day/year and can also include hour/minute/second.  In the user interface, AM or PM can be specified but a 24-hour clock is used when referring to code, written in the format yyyy-dd-mmThh:mm:ssZ when loading data or filtering records by date
• Number – standard number field (referred to as Integer or Double in code depending on the size)
• Phone – will automatically format input in the form of a phone number
• Picklist – also commonly known as a dropdown list, allows a user to select a specified text value from a list to avoid typos
  • Multi-select picklists can be created as well but those tend to be harder to work with and report on and are generally not recommended unless absolutely necessary
  • Picklists can also be made dependent on each other, for example while selecting classes for school, you can have a controlling picklist to specify you’re looking for a Math class or Language class and a dependent picklist that will contain the values of “Math 101, Algebra, and Geometry” if you pick “Math” or “English, Spanish, or French” if you pick “Language”
• Text and Text Area – allows a user to enter a single or multiple lines of text (also referred to as a String when talking about code)

There are also some special fields with unique properties that sometimes come with limitations to how many can exist on each object, but can come in EXTREMELY handy when automating processes and connecting your objects together.  Think of these as the special legos that come in the package!  They’re super cool but usually there’s only a couple of them in each package.

• Formula – can be a Checkbox, Date, Number, Text value, or a few others and gets its value from logic that you can define based on the values of other fields on the specific object
  • for example if you’re tracking the Street__c, City__c, and State__c fields separately on a custom object, you can create a formula field called Address__c that will equal the value of Street__c + City__c + State__c
  • Formulas have a limit of 3900 total characters in them and can only be extended to reference other formula fields if the total value combines for under 5000 bytes behind the scenes, don’t worry about this too much for now but just be aware that you can’t create unlimited formulas that reference each other
• Lookup – relate objects to each other either in a Master-Detail relationship or a Lookup relationship, more on the differences next time
  • Standard objects come with some of these by default and custom objects can have a maximum of 2 master-detail relationships and they can go up to 3 levels deep
  • Standard objects can’t become details to master Custom objects
• Roll-Up Summary – Can be in the form of a Count, Sum, Min, Max and give the aggregate total of fields on related objects
  • for example an Account record can show how many total Contacts are associated with it, the total value of all opportunity amounts associated with it, or the highest or lowest value opportunity amounts
  • These can only be created on objects that are the Master objects in Master-detail relationships and are limited to 25 per eligible object

Dot Notation

The last major item I wanted to touch on is what is referred to in the coding world as “Dot Notation”.  All it really is though is requesting information about specific fields on specific objects.  For example, Account.Name (read as Account dot Name) will give me the value of the Name field for the Account that is being referenced.  It works the same way for custom objects, as long as we remember that when accessing fields, we use the API name, and therefore need to add the “__c” to each one.  Jedi__c.Lightsaber_Color__c (read as Jedi dot Lightsaber Color or Jedi underscore underscore c dot Lightsaber Color underscore underscore c) will give me the value of the color of the lightsaber of the Jedi that the statement was referencing (hopefully now you’ll understand why the “__c” is often implied on anything custom rather than spoken).  You’ll often see this sort of syntax as an Admin anytime you need to “insert merge fields” whether in a formula, validation rule, or email template.  Hopefully this doesn’t come as too big of a surprise, but you also now know how to reference fields within code too!

Wrap Up

More about the differences in lookup relationships and determining exactly how you can distinguish between different types of the same objects in my next post!  In the meantime, feel free to browse the resources below and pick up a few new related Trailhead badges if you haven’t already. Stay tuned and may the Salesforce be with you!

Additional Resources:

Data modeling Trailhead module: https://developer.salesforce.com/trailhead/module/data_modeling

Accounts and Contacts Trailhead module: https://developer.salesforce.com/trailhead/module/admin_intro_accounts_contacts

Leads and Opportunities Trailhead module: https://developer.salesforce.com/trailhead/module/admin_intro_opptys_leads

Certification Items to Focus On

Standard and Custom Objects from the Certified Administrator Study Guide:

• Describe the standard object architecture and relationship model
• Describe when to use and how to create formula fields