- Object Manager and Lightning App Builder: 20%
- Standard Objects
- Master-Detail Relationship
- Roll-Up Summary Fields
- Lookup Relationships
- Junction Relationship Object
- Customization Relationship
- Accounts and Contacts Relationship
- Changing and Deleting Fields
- Required Fields
- Picklists
- Validation Rules
- Cross Object Formula Field
- Page Layouts and Field Level Security
- List Views and Search Layouts
- Lightning App Builder
- Page Layout Assignments
- Record Types
- Assignment Rules
- Business Processes
- Queues
- References
This topic has 3 sub-topics
-
Describe the standard
object architectureandrelationship model.It includes topics e.g.; Standard Objects, Parent-Child Relationship, Master-Detail Relationship, Lookup Relationship, Junction Objects and Relationship, and Record Types. -
Create, delete and customize
fieldsandpage layoutson standard and custom objects and know the implications of deleting fields. It's all aboutfieldsandpage layouts. -
Assign page layout, record types, and business processes based on any given scenario for custom and standard objects.
Common Standard Object includes
| Object | Description |
|---|---|
| Account | Has 1:N relationship with cases and opportunities. Products and Campaigns are not related to it. |
| Contact | |
| Lead | |
| Opportunity | |
| Case | Customer Feedback, inquiry, or complaint. |
| Campaign | Aimed at Campaign Members |
| Products | Related to opportunities |
| Solution | A regularly occurring customer problem that has the solution |
| Work Order | Tracks the different tasks that need to be taken out on a product |
-
In this relationship, if you delete the master record, it automatically deletes the associated detail records.
-
You can't give a new master to a detailed record.- There is no
owner fieldin the detail record, instead, it's shared from the master record because the owner of the master record also owns the detailed record. -
Detailed records can't have
Sharing Rules, Manual Sharing, and Queues, because these require an owner field, which detail records don't have. -
Detailed records inherit the
Sharing and securitysettings of the master record. -
Master relationship field is required on all detailed page layouts (Permanent lookup field).- A custom object can have up to 2 master-detail relationships.
- These
fieldsare only allowed on master records in a master-detailed relationship. Example fields includes
-
Count: count the number of related detail records for any given master record.
-
Sum: Accumulates different fields in the detailed records to be displayed on master record page.
Features of Lookup Relationship include
- Loosely coupled
- No roll-up summary fields.
- Don't share security settings.
- When you try to change the lookup relationship to the master-detail relationship, make sure every detailed object has a lookup field for the master object.
- We can also create a
dependent lookupfield, a lookup field with afilter=> You can only lookup objects or related records which satisfy thefiltercondition.
- You always create a field on the N side of the 1:N relationship e.g.; 1 Provider can have N patients.
- On the 1 side, the related list is maintained.
-
This object is created to be used in a many-to-many relationship.
-
This object will have
2 master-detailrelationships.
-
If a field is a universally required field, it's automatically added to all page layouts.
-
Required field can't be hidden.
-
You can make text, number, and picklist fields as required.
-
They are immune to field security => even if the user doesn't have the right access to see this field, that user will be able to see it.
-
Standard picklist values can be added, updated, and deleted.
-
Global
Value Setsare set of picklist values to be set once and reused by custom picklist fields. -
Master picklistis a complete list of picklist values taht can be used in aRecord Type.
They make sure that the data user has entered meets the specific rules you have set out before data is saved.
System validation rules check the following things.
- Layout Rules compliance.
- Required Fields.
- Valid Field Formats.
- Field Length (max/min)
Custom validation rules are set up by the user manually. You should be aware of following key validation terms.
- PRIORVALUE
- ISCHANGED
-
It's a formula field that spans two related objects and references merge fields on those objects up to 10 levels/relationships away.
-
Formula fields are not editable on the page layout because data is calculated on the fly. Only the formula is stored in the page layout.
-
We can hide or visibility of a field in a number of ways e.g.; Page layouts and Field level security.
-
Field hidden using
field-level securitywillnot show upon 1. Page Layouts 2. Search Results 3. Related Lists 4. List Views 5. Reports. -
Field is hidden using
Page layoutstillavailableon 1. Reports 2. Search Results 3. List Views. -
Page Layoutcan make afield read-only or required.
-
Users can only fields in the List View they have access to. Field level security absolutely applies to List View.
-
User with
Manage Public List Viewspermission either via profile or permission set, allows sharing to 1. The users themselves, 2. A group or Roles 3. Everybody -
Users with the above permission can edit other public list views and add more filters to them.
-
Users without the above permission set can only make List View for themselves only.
-
Search Layoutsare ordered groups of fields, that show up in search results for a particular record e.g.; 1. Lookup Dialogs 2. Search Results for an entire org 3. Related Lists -
Search Layoutsalso control the recently viewed list views.
-
You must
activatea page for a user to view it, even if it has been saved. -
You can assign a page to
Org default,App Default,App, Record Type, or by Profile.
- You can assign page layouts to different profiles without using record types if you like using page layout assignment.
-
It's used to show different versions of one particular object.
-
There can be multiple reasons to do it. e.g.; For different users, you don't want to show all the fields, or maybe different users needed to see different fields of the same object.
-
Real-life examples include, you may be recording student library, accounts and courses information. For an accountant, library information maybe not useful.
-
Another example can be, in a hospital, you can refer a patient and get a referral of a patient. When you are getting referral, the referral number field should be editable because you will be entering the value you got. In-case you are creating referral for a patient, it should be autogenerated and noneditable.
-
when you use record type, you achieve the following 3 main things.
- Show Different page layouts.
- Show different picklist values.
- Show different business processes.
-
Automatically assigning records to a certain owner.
-
You can have multiple assignment rules and they are executed in order.
-
An assignment rule is executed when its rule is met. When one of the assignment rule met, other rules will not executed, just like if-else statement.
-
It's just a path you see on top of the object detail page e.g.; Opportunity (Sales Process), Cases (Support), Solution, and Lead.
-
It helps visually user to see the steps that the user should take to move to the next step.
-
Paths can be created on most Standard Objects, and are controlled by picklist values.
-
They are used to collect, prioritize, and share the workload among number of users.
-
We can prioritize the workload based certain
filteror a condition without assigning it to a certain individual. -
A Listview is automatically created when a queue is created for any object (Standard or custom)
-
Only members of a queue can accept records from that queue and take ownership.
- Extend Salesforce with Clicks, Not Code
- Trailhead | Admin Trail Mix
- Trailhead | Admin Trail Basic Mix
- Trailhead | Admin Trail Intermediate Mix
- Trailhead | Admin Trail Advance Mix
- Salesforce Hulk | Salesforce Administrator and App Builder
- Tutorials Point | Salesforce
- Salesforce | Who see what
- Salesforce Support