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
- Salesforce Platform Basics: https://developer.salesforce.com/trailhead/module/starting_force_com
- Salesforce Basics (Intro to Lightning Experience, Salesforce’s new UI): https://developer.salesforce.com/trailhead/module/lex_implementation_basics
- UI Customizations: https://developer.salesforce.com/trailhead/module/customizing_user_interface
- App Customization Lite: https://developer.salesforce.com/trailhead/module/lex_migration_customization
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
Adam To Architect 
Leave a Reply