2020 Outlook

As we start Salesforce’s new Fiscal Year, I’ve had some time to take a breath for a few months following Dreamforce, I thought I’d share some thoughts on where I see Salesforce going this year based on what I’ve seen from Dreamforce and the Spring ‘20 Release. While I may not have any more success than Harry Potter at looking into a Crystal Ball, hopefully these predictions will be a little more evidence based.

Admin Takeaways

1. Dynamic Layouts are coming!

As the most requested feature on the Idea Exchange, it is very exciting that truly dynamic layouts are on the way! Soon we’ll be able to customize layouts at the field level and truly give users the fields we want for the use cases we need. Definitely a win for #AwesomeAdmins. It sounds like this feature is in pilot now but should hopefully be GA sometime in 2020!


2. Flows are about to become stronger than ever

I’ve been hearing some rumors that Flows are about to get even MORE powerful than ever before and (spoiler alert from the Spring ‘20 release notes, they did) this was furthered by a slide shown during the Admin keynote. Unclear what “Before Triggers” will mean for the future but if more functionality can be built into flows, including more functionality that currently requires triggers, that’s yet another tool that Salesforce Admins will have that won’t require any custom development. It also sounds like Process Builder functionality may start moving more and more into Flow (as evidenced by Process Builder being listed under the Flow section of the Release Notes). I’ve been hesitant to become a “Flownatic” for a long time but seeing things like this are great reasons to start diving in!


3. Permission Set Groups are changing Salesforce security for good

This is a pretty big change to how security works in Salesforce, and appears to be the first step in “discouraging admins from relying on profile for permissions management going forward” according to this Salesforce Admins blog post. Without a doubt, the ability to assign users multiple permissions at the same time, as well as being able to mute permissions within the group without needing a whole new permission set, is a win for admins. It’s also a win for Devs who have been frustrated about the inability to utilize profiles effectively in Salesforce DX. Definitely excited to see things move in this direction, while there may be some short term pain in having yet ANOTHER place to configure Salesforce security (as per CTA Steve Simpson there are already 17!), it will allow for greater customization, which is always a good thing.


Ways of Sharing

Dev Takeaways

1. Non-Salesforce development languages are coming (Evergreen)

One of the big things I suspected Salesforce was going after when launching Lightning Web Components was developers currently outside the Salesforce ecosystem. They wanted to be able to tell ALL developers that they can start developing on Salesforce. This theory of mine is further confirmed by a demo during the Dev Keynote, Evergreen functions. This will allow you to write standard Java or Node.js on Salesforce and integrate it into your Salesforce code. I suspect this is only the first step as Salesforce continues to cater to more developers, allowing their dev ecosystem to explode and truly become a platform that all developers can use! While it keeps us current Salesforce developers on our toes, I think it’s ultimately the right strategic move and will encourage Salesforce developers such as myself to expand our skills and boost our own careers.

2. Local Development is here

One of the problems with the current Salesforce development experience is that you need access to a Salesforce org in order to see what your components look like. No more! Now you’ll be able to spin up a server on your laptop and get a preview of your component without needing to connect to an org to do it! Very important for developers who want to iterate quickly, especially for UI changes.


3. LWC is the future but the present too!

2 of the biggest takeaways I came away with from Dreamforce though, were from 2 sessions by Greg Rewis, Product Manager of Lightning Components.

  1. Lightning Base Components are now open sourced
  2. Don’t ever write another new Aura component again

One of the increasing trends that Salesforce has embraced is Open Sourcing their technology, and I’m all for it! For those unaware of the term, it basically means they’re revealing the source code behind these products, so that you can download them and customize it yourself!

Don’t know how a component works? Look up the code! Don’t like how a base component works? Download the code and make the edits you want! I think this is very exciting for the future of Salesforce development.

The other thing that I took away from Dreamforce was straight from the mouth of the Product Manager for the technology himself “In Aura we had to take your ‘JS’ file, which was really JSON, compile it, parse it, and turn it into real JS! No wonder it was so slow!”

Greg also shared that all Aura components are actually LWC under the covers. You’re just essentially implementing an intentional performance hit with every Aura component that you build! Based on this information, it’s pretty apparent to me that ALL new component development should come from LWC rather than Aura wherever necessary. This will not only be good to keep up with the latest Salesforce technology, but it’ll be working with more standard technology in general, and help Salesforce devs take the next step to truly becoming Full-Stack Developers. It also continues the trend of allowing non-Salesforce developers to start doing their work on the Salesforce platform!


As Salesforce continues to grow at incredible rates, it’s extremely important for the community to go along with it. Salesforce jobs have been some of the hottest around and it’s great to see Salesforce investing in bringing more and more Admins and Devs to the platform. By moving toward industry standards with LWC, open-sourcing the base components, and starting to allow for non-Salesforce code to run on the platform, it is clear that Salesforce is increasing its addressable market of Developers and that’s a good thing. There were also billboards all over Dreamforce this year about people who went from “cashier to engineer” or “driver to developer”. 

With flows becoming even stronger and the addition of Permission Set Groups, it’s clear that the role of the Admin is continuously increasing as well. With each new release it seems that Admins can do more and more without needing a Developer and that’s also a good thing!

Salesforce’s approach to open sourcing Lightning Web Components and allowing for non-Salesforce code with Evergreen, are also welcome developments to not just Salesforce developers, but non-Salesforce developers as well who are thinking about getting into code! Seeing a Beta exam opportunity for a “JavaScript Developer” cert is even more proof that the time is right to get into front-end development if you haven’t already!


Salesforce Record Access


First of all, just wanted to clarify I’m not going to discuss how Salesforce handles security on their end, but rather how you as an admin can configure it in your org.  I would again like to remind you that I highly recommend nailing down the fundamentals of being a Salesforce administrator first regardless of which path you ultimately end up taking.  Salesforce security is so fundamental and universal, it is something that I ask interview applicants for admin positions about 100% of the time.  I should also note that while it’s probably alright to not remember every single different possible way a user could gain access to a record in an interview, demonstrating that you don’t understand the way that security works will always be a red flag for me.

“Security and Access” covers about 15% of the Salesforce Administrator certification exam and “User Setup” covers another 9%.  If you can master your understanding of how and why someone would or wouldn’t have access to a specific record in Salesforce, you’ll be ¼ of the way to being ready for your certification!

Every Job You’ll Ever Have

Every job you’ll ever have, in some capacity or another, will have an element of security to it.  There will be someone or something that you need to protect.  When working in technology, more often than not, the most important asset your company will have, is its data.  This means that you, as the Salesforce admin, will most likely be the keeper of your org’s keys.


For that reason, it is imperative that you learn how to use them in the best way possible!  Salesforce has an easy to remember URL for their series of videos on this topic: sforce.co/WhoSeesWhat!  I’m going to summarize at a high level what the different pieces are but I highly recommend going through the links, Trailhead modules, and gain some experience to capture all the finer points.  I’m continuously learning new things about it all the time!


The most basic level of access starts at the profile.  Users can only be assigned one profile so it is very helpful when choosing how to create your profiles, to choose names that capture the type of user they will be.  Profiles contain a TON of different settings.  There are so many, that Adam Torman once rolled out the complete list over 40 feet long down the side of a building:


The basic things you need to know are that these permissions contain the most basic Object, Field, and System level access for your org.  Nothing in Salesforce can restrict access to a user if their profile explicitly grants it.  The Object permissions are often referred to as CRUD permissions.  While this is an odd sounding name (and still amuses me every time I hear it) CRUD is simply an acronym for Create Read Update Delete.  This means you can grant or deny these 4 permissions for all objects.  There are also special permissions on objects such as “View All” and “Modify All” which override all other permissions in the system to give a user in that profile full access to all records of an object regardless of ownership.

Field level permissions on the same page as the Object permissions are set and can be marked as either Visible (allowing editing if the field is editable), Read Only (which includes the visibility permission by default), or left blank (which gives no access).

System permissions include things such as “Lightning Experience User”, “View All Data”, “Modify All Data”, etc can be set here as well and dictate the behavior that a user will have at an organizational level, beyond specific object permissions.  These will generally be specified on Salesforce Help pages if a certain permission is required to complete a specific action.

Access to Apex classes, Visualforce pages, tabs, apps, and other metadata can be set here as well.  Users MUST be assigned a profile and profiles are tied to license types.  It is also important to note that Standard profiles can’t be modified and are updated automatically with new releases.  They can be cloned to quicken the process of creating custom profiles though.

Organization-Wide Defaults (OWD)

Record ownership is key in Salesforce and by default users will have full access to a record that he or she owns.  What about the records of an object that a user DOESN’T own though?  This is where Organization-Wide Defaults (commonly known as OWDs) kick in.  With a couple exceptions, OWDs on an object can be set to one of 3 options:

  1. Read/Write – gives all users Edit access by default
  2. Read Only – gives all users Read access by default
  3. Private – gives all users No access by default

These settings will depend on you asking yourself a few questions such as “What is the minimum level of access someone needs to a record they don’t own?” and “Is there any reason someone would have to access a record that they don’t own?”  As I mentioned, there are some exceptions to this for specific objects but for the most part it will be one of those 3.  These can be set in Salesforce Classic by navigating to Setup -> Administration -> Security Controls -> Sharing Settings or Setup -> Security -> Sharing Settings in Lightning Experience (or simply searching for Sharing Settings in either search bar).

Permission Sets

A common issue when determining access is generally along the lines of “Well, if I give 10 users the same profile, what if 2 of them need slightly different permissions?” or “What if I need to give 2 users additional permissions for a few weeks, but then want them to go back to normal?”  Fortunately, rather than causing you to go through the 40 feet of a building process of creating a brand new profile, Salesforce has thought of this!  While a user can only have 1 profile at a time, they can have many profile extensions, known in the Salesforce world as Permission Sets.  A permission set is just that, a specific set of permissions.  This can range from Object specific permissions, to field specific permissions, to app specific permissions, to system specific permissions.  

Generally it is a best practice to have a specific use case in mind for a perm set and name it accordingly, such as “Convert Leads”, “View All Account Data”, or “Destroy Deathstar App”.  You can quickly swap out and assign permission sets to users to give them elevated privileges either temporarily or permanently.  You can also use these on users of different profiles in case specific individuals from different departments need to access an app, or a tab, or pretty much anything!

Roles Control Records

Probably one of the most important, and simple, statements that I keep in mind from learning Salesforce was something I was taught in a training video once: Roles control records.  This short, sweet, and alliteration friendly, statement refers to the last major component of basic Salesforce visibility, the Role Hierarchy.  Similar to profiles, users are limited to only 1 role.  Unlike profiles however, roles control ability to access records in an org.  Since managers often have reasons to be able to see records of their direct reports, Salesforce has made this easily doable by allowing the admins to assign roles to users that correspond to what the organization’s visibility looks like.  While I would highly recommend (from experience) against overcomplicating the hierarchy, it is possible to have up to 1000 roles.

Sharing Rules

If you have a more complicated security model you’d like to implement, Salesforce allows you to do this as well in the form of sharing rules!  You can implement rules that share records based on specific criteria to various roles, roles with their subordinates, or public groups.  These can be configured on an object-by-object basis.


Team Sharing

The next type of object sharing is of the “Team” variety.  Users can be added to Account or Opportunity teams in different roles on specific records and get additional Read or Edit access without having a relationship to the record owner.  These teams can also be saved in a user’s settings and be re-applied to help the owner work on selling to specific customers on an automated basis.

Manual Sharing

Sometimes there are one off cases where a user needs to share a record with someone else.  Maybe they’re going on vacation or maybe just need a little push from someone on a different team.  This is where manual sharing comes into place!  Users can manually share individual records at their own discretion.  In order to share a record, you must be the owner, above the owner in a role hierarchy, or an administrator.

Apex Sharing

Yet another option for sharing records is by configuring Apex sharing.  I haven’t personally done too much of this but the general idea is that you can create “share” records for any object through code that allow you to extend access of specific objects based on criteria that your developers (or maybe you someday!) define.

Wrap Up

Wow. With all these options for sharing records, there’s no end to the amount of customization you can give to your security model!  Each one depends on your company’s unique requirements.  If you’re ever in doubt about who has access to a particular record, Salesforce has you covered there as well!  By clicking the “Sharing” button on the top of the record (available if the OWD is set to anything other than Public Read/Write), you can see everyone who has access to the record, what their access is, and even click on “Why?” to see the reason behind why that particular user has access.

Screen Shot 2016-05-28 at 6.56.33 PM

Screen Shot 2016-03-16 at 7.55.05 PM

Hopefully that’s enough to get you started (and pass an interview with me) but just in case it isn’t, feel free to check out the helpful links and the Trailhead modules as a result!  Congrats! You’re on your way to becoming a Salesforce admin!

Relevant Trailhead Modules

Certification Items to Focus On

Security and Access from the Certified Administrator Study Guide:

  • Explain the various organization security options
  • Describe the features and capabilities of the Salesforce sharing model
  • Given a scenario, apply the appropriate security controls
  • Describe the various settings and permissions a profile controls
  • Given a scenario, determine the appropriate use of a custom profile

User Setup from the Certified Administrator Study Guide:

  • Identify the steps to setup up and/or maintain a user
  • Given a scenario, troubleshoot common user access and visibility issues

Additional Resources

Sharing Tips: http://resources.docs.salesforce.com/198/14/en-us/sfdc/pdf/salesforce_sharing_cheatsheet.pdf

More Info on Ownership: https://developer.salesforce.com/blogs/engineering/2013/10/behind-the-scenes-of-record-ownership-in-salesforce.html

Adding and Managing Users: https://help.salesforce.com/HTViewQuickStarts?id=000120152

Salesforce On Security: sforce.co/WhoSeesWhat

Profiles and Permission Set Auditing: http://www.salesforcehacker.com/2013/10/visualizing-users-permissions-across.html

Admin Hero on Security: http://www.adminhero.com/salesforce-security-part-1-record-access/

Manual Sharing: https://help.salesforce.com/apex/HTViewHelpDoc?id=granting_access_to_records.htm&language=en

Building Even More with Salesforce

Happy New Year!.  I wanted to expand a little bit on my last post and introduce a few other basic admin tools to round out the Standard and Custom objects portion of the Certified Admin exam, compromising 18% according to the rubric.  I also wanted to share my new Journey Progress page and encourage you to start your own if you haven’t already!

More on Lookups

Last time we introduced the unique concept of creating a field on an object that links that object record to another object record, such as a Contact to the Account that it corresponds to.  By connecting 2 objects together, you can create complex automations and gather additional data on parent objects when its child objects get updated.  Creating a lookup relationship creates what is called a One-To-Many relationship meaning that there will be one single parent object and potentially many child objects.  The child object record will have a single field that will be a hyperlink to the parent record and the parent object record will have what’s called a related list on the bottom of the record page that will show all of the associated child records.  

Use Master-detail lookup relationships when you want the child objects to depend on the parent objects.  For example, if you had a custom object called Jedi Knight and a related object called Lightsaber, you may want a Jedi’s lightsabers to also be deleted if the Jedi record is deleted.  You could also have a roll-up summary field to count the total lightsabers a specific Jedi owned*.  The detail object record will inherit all security and visibility from its master record.

If you had another object called Vehicle, you probably would want to assign the Vehicle a new Pilot if something happened to the original one.  A standard lookup relationship would be best here to relate the two objects but not make them dependent on each other.  This allows you to have a variety of vehicles and pilots that you can swap out as necessary.  It may be possible that better pilots could be driving multiple vehicles but chances are vehicles should only have one primary pilot.

Sometimes it’s necessary to create a many-to-many relationship, for example if I was setting up a college course signup app, I might have a custom object called Student__c that would be enrolled in multiple Course__c objects.  In turn, each course would have multiple student objects associated with it.  In order to set up a relationship such as this, we can use what is called a “Junction object”.  We could create an additional object, such as Course_Slot__c that would have a lookup field, and a One-To-Many relationship, to both the Student and Course objects and would represent one student signing up for one course.  We could then adjust our Course Slot related lists on both the Student and Course objects so we could see a student’s complete schedule and a course’s full roster by looking at their specific records.

*You can also create a one-to-one (1:1) relationship using a hack with roll-up summary fields and validation rules outlined here: http://one-to-one-salesforce.blogspot.in/

Chained Dot Notation

In the last post, we also introduced the concept of “Dot notation” where I can say Wand__c.Wizard__c and be referencing a Wand’s corresponding Wizard lookup field.  But what if I wanted to know what Hogwarts house the Wizard was in without having to click on the Wizard to find it?  If I was looking at the wizard, I could look at the Wizard__c.House__c field and that would tell me!  Wouldn’t it be pretty cool if I could ask a wand which house its wizard was in though?  Fortunately, Salesforce let’s us do this!  We just have to let Salesforce know we want to ask a wand about its related record.  Because it’s a related object though, we’ll use slightly different notation, namely “__r” instead of “__c”.  We can say Wand__c.Wizard__r.House__c to ask about the Wand’s Wizard’s House from the Wand record!


Generally you can have Salesforce figure this out for you by inserting merge fields such as in the screenshot above but it’s definitely good notation to know, and even better to know that we can do it!  You’ll most often see this in formulas, validation rules, and email templates, and as with most things, you can also do it in code.  You can also create a chain of objects up to several lookup levels deep!  As with electronics though, it can get messy, not to mention dangerous, if you go down too many levels so Salesforce has a depth limit of 5 levels in place (3 for master-detail).


Schema Builder

A good way to view all the relationships between your objects is by using the Schema Builder.  The example below shows that the Account object has a One-To-Many relationship to the Case, Opportunity, and Contact objects, Contact has a One-To-Many relationship to the Case Object, and the Lead object is not connected to the other objects via lookup.  You can also create fields from here but I generally prefer going through the UI instead.


Record Types and Page Layouts

While it is great to be able to create a great data model full of standard and custom objects and fields, it is likely that you’ll have different types of records for each object and different users are probably going to need to see different fields.  For example, you may have a bunch of different droids represented as Contacts.  Some will be protocol droids such as C-3PO, some will be astromech droids such as BB8 or R2-D2, and some will be medical droids.  All of these would be classified as contact records but are going to have very different relevant fields.  

Is there really a point in an astromech droid having a field called Languages_Spoken__c or a protocol droid having a field called Medical_Skill_Level__c?  Most likely not.  The Contact object will need to have both of these fields though.  This is where the concept of Record Types come in, so you can quickly figure out how many of each type of droid, or Contact you have.  You may also allow certain users to only be able to create certain types of new droids.

You might also have different employees that need to see different fields of the same type of record.  For example, you probably won’t want a Sith in your organization, or any one else in the Dark Side department, to know the value of Home_Planet__c on the protocol droid Contact record type but they still may need to know about its existence for reporting purposes.  You can create separate page layouts for various users and assign them to record types and user profiles so you can determine exactly which fields each type of user should see for each record.  

Note that fields are added to Page Layouts, Page Layouts are assigned to Record Types and associated with Profiles.  You can’t add fields directly to record types and you can’t restrict visibility of Page Layouts directly to users.  The combination of record types, page layouts, and field level security (more on this next time) together will dictate exactly what each user will see when viewing a specific record.  

List Views

Between objects, fields, records, and record types, there’s a lot of potential data to be viewed at once.  Fortunately, Salesforce lets us filter what records we want to see in what are called List Views.  List Views allow you not only to filter which records you see at any given time, but also which fields show up on each particular view.  Sometimes it’s useful to only see records that you own, sometimes all records for a given time period, sometimes sorted by record type, or sometimes by a filter of your choice!  You can also choose if you want the current view to be visible just to you or to your entire org as an admin.  You can also allow end users to create their own list views so they can filter however they like as well.  With Lightning Experience, you can also add cool charts to your list views for quick data analysis!

Wrap Up

A lot of info to cover but hopefully you have a better understanding of how to start building on the platform and customizing a little bit more using both the built in functionality of the standard objects and some custom objects that are built specifically to support your org.  To get a little hands on practice, feel free to check out a few of the Trailhead modules listed below and the additional resources for some more information.  After you finish the modules, feel free to add yourself to the Trailhead leaderboard!


Relevant Trailhead Modules


Certification Items to Focus On

Standard and Custom Objects from the Certified Administrator Study Guide:

  • Explain how to create, delete, and customize fields, page layouts, and list views for custom and standard objects
  • Given a scenario, determine the appropriate fields and page layouts for custom and standard objects
  • Explain how to create, delete, and customize record types for custom and standard objects
  • Given a scenario, determine the appropriate record types and business processes for custom and standard objects
  • Explain the implications of deleting fields: https://help.salesforce.com/apex/HTViewHelpDoc?id=deleting_fields.htm&language=en


Additional Resources

Object relationships: https://help.salesforce.com/HTViewHelpDoc?id=relationships_considerations.htm&language=en_US

Roll-Up Summary Fields: https://help.salesforce.com/apex/HTViewHelpDoc?id=fields_about_roll_up_summary_fields.htm&language=en

Junction objects: https://help.salesforce.com/HTViewHelpDoc?id=relationships_manytomany.htm


How is Salesforce Built

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.  

Screen Shot 2015-12-29 at 10.40.01 PM

Salesforce Classic

Screen Shot 2015-12-29 at 1.19.18 AM

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.

Screen Shot 2015-12-27 at 9.24.55 PM

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.

Screen Shot 2015-12-29 at 1.25.29 AM


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