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!

CustomFields

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).

Wires

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.

SchemaBuilder

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

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.

legos

  • 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