This chapter’s objectives are:

• 5.1- Describe the standard object architecture and relationship model
• 5.2- Explain how to create, delete, and customize fields, page layouts, and list views for custom and standard objects
• 5.3- Given a scenario, determine the appropriate fields and page layouts for custom and standard objects
• 5.4- Explain how to create, delete, and customize record types for custom and standard objects

5.1- Describe the standard object architecture and relationship model

• All Objects in Salesforce are related, that is, there exist relations between Objects, for example, an Account can have zero or more opportunities related to it, so the Account Object should be related somehow to the Opportunity Object .
• To visualize the relation between Objects, we use ERD (Entity Relationship Diagram)
• You can check all the different relations between Salesforce Objects in the Salesforce Data Models documentation: SF Data Models: https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/data_model.htm
• To better understand this concept, check out this excellent Video of ERD Tutorial for Beginners by Gina Baldazzi
  
• Also, check out this other Salesforce Video: Data Modeling for Non-Developers: An Intro

Object Relationship Types in Salesforce:

• The relationship between Objects can be of different types, one-to-many, many-to-many
• One to One:
  • Husband / Wife
  • A Wife can have one husband only
  • A Husband can have one Wife only
• One to Many:
  • Team / Player
  • A Player can have one Team only
  • A Team can have many Players
• Many to One:
  • Player / Team
  • A Team can have many Players
  • A Player can have one Team only
• Many to Many:
  • Video / Customer
  • A Customer can rent many videos
  • A video can be rented by many customers
• This is equivalent to 2x One-to-many relationships:
  • Video / Rental
  • A rental can contain One video
  • A video can have many rentals
  • Customer / Rental
  • A rental can be for One customer
  • A customer can do many rentals.
  • Rental (the child of both parents) is called a Junction Object

ERD: Entity Relationship Diagram:

• What is Data Modeling?
  • It is simply organizing your information properly.
  • 3 commandments of DM:
    • Do not duplicate data – don store data in multiple places
    • You want the simplest structure possible while maintain integrity of info
    • Fields need to directly describe the objects that they are on: ex, email address in the Contact Object
  • Terminology:

• Example:
  • Your company processes training for its products
  • Class Registration is tracked via Excel
  • Training is becoming bigger and more complex
• Questions to ask:
  • What are the primary objects you want to track? Students and Classes
  • One-to-Many or many-to-many? Many-to-Many between students and classes
  • How many objects you need? 3, 1 of the Junction Point
  • Where do your fields go? Check the Excel and arrange the fields as per the tables. Status should go in the Junction Object as it describes the Student / Class status

    

• Lookup vs. Master-Detail:
  • SF specific terminology
  • Independent of one to many, many to many
• Lookup:
  • Value in field is not required
  • When parent deleted, children orphaned by left intact
  • Can be any combination of custom / standard objects
  • Just a basic link between 2 objects, not enough features
  • Example: account / contact
• Master-Details:
  • Value required (ex. cannot have registration without a course)
  • When parent deleted, children deleted (when you delete class, registration deleted)
  • Standard Object can only be a parent. Custom can be both
  • Inherited secutiy” if you can view parent record, you can view children
  • Extra: sharing options, UI functionality, reporting capabilities, data analytics tools for example, you can do Roll-Up Summary on parent
• How to do this scenario?
  • First create the 3 Object: Build | Create | Objects
  • Class, Registration and Contact (already created)
  • For Registration, Unique ID will be a Number (RegCode) – this is the Junction Object
  • Registration will have 2 Master-Details Relations, one with Class and another with Contact (we will call this field “Student”. Registration is the child of both.
  • These relation will be created from the child object custom fields section
  • Also add another field called Status (dropdown) in the Registration Object
• Extra stuff on the parents::
  • Roll-Up summary fields (RSF) on the Class Object (one of the parent of the Registration Object
  • Create new custom field on Class, field type: Roll-up summary, call it Number of Registered, choose type to be sum, choose the filter to be Status Not Equal to Cancel (this way you don’t count the cancelled ones)
  • Create Formula field called “Slots Remaining” with type=number, next page enter the formula among fields.
  • Add the Slots remaining to the Search Layout (to show it when you click on a list view) – Serouj.

5.2- Explain how to create, delete, and customize fields, page layouts, and list views for custom and standard objects

Object (and Tabs):

• Custom Object vs. Standard Objects

  

• Manage Objects:
  • Create: Capture Info
  • Edit: change Object characteristics and behaviors
  • Delete: non-permanent removal of Object
  • Erase: permanent Removal
  • Undelete: recover object
• Create a custom object.
  • Go to Build | Create | Objects – New Custom Object / Schema Builder
  • Give Label, Name and Plural Label, give the record name (name or number)
  • Deployed vs in development
  • Check the box launch new custom tab wizard to create a tab, or alternatively, you can create a tab later on by going to Build | Create | Tabs
  • Tab exposes the Records within the Object to the users
  • Once created, you can edit it: change label, add fields, layouts,
  • You can delete custom Object, very hard to recover unlike field

• difference between an object and a tab:
  • An object stores the field definitions and records.
  • An object tab is used to expose an object’s records within the user interface.
• Difference between deleting and erasing a custom object: When deleting a custom object some data loss may occur even if the object is undeleted later (associated workflow rules are lost, for instance). Otherwise, objects follow the same rules a fields (deleted objects are permanently erased automatically after 15 days).
• properties of an object:
  • Label & Plural Label: How the object is displayed to the user within the user interface.
  • Name: How the object is referenced programmatically and via the API.
  • Record Name Label & Format: How record within the object are named (either text or auto-number). The name field is what is displayed when the object is referenced in a lookup or master-detail relationship.
  • Allow Reports: Allows reporting on the object (enables default report types).
  • Allow Activities: Allow activities to be associated to records of the object type.
  • Deployment Status: Either “Deployed” or “In Development”. Objects “In Development” can only be viewed by users with the “Customize Application” permission.

Field History Tracking:

• Field history tracking allows you to capture when the values within specified fields change when a record is edited.
• Use field history tracking to create an audit trail of modifications to your company’s critical data. This can be particularly helpful in identifying instances where data was updated incorrectly and by whom.
• Enable it:
  • Standard objects: Select “Set History Tracking” within its field configuration
  • Custom Objects: Ensure the object properties have “Track Field History” enabled. Then click “Set History Tracking” and select fields from the object

    

  • Once enabled, track the field change by adding the field history related list to the page layout

    

• Note: Field history tracking will only track values for specified fields once enabled.  Enabling history tracking or adding additional fields will not yield any historical data
• Fields longer than 255 characters (such as long text, rich text, and multi-select picklist fields) do not track values when changed (only that a change has occurred).
• You can track up to 20 fields per object by default (the limit can be raised by contacting Salesforce support, but may impact record save time)

Create Relationship between Objects:

• One to Many: Go to the child Object, in this case the Object that can have 1 of the other: Object that has Crow foot attached to it — Classes.
• Create a new field on this Child Object, with type Lookup or Master-Detail to the Parent Object (that will have the Related List at the bottom)

   

• Select the other object to which this object is related (Teachers)
• Enter the label and name for the lookup field
• Select the minimum access level required on the Master record to create, edit, or delete related Detail records
• In the case of Many-to-many, it is the same, but you have to create 2 relations as per the photos on the right. In this case, go to Course Offering, create 2 relations one with Course Object and the other with Classroom Object.
• Course Offering Object can also have fields like start date, end date, current occupancy. Also classroom can have Max occupancy
• In the parent page, you can edit the layout and add more fields on the Course Offering section at the bottom (Serouj):

  
  

• In the case of one-to-one:

1. Create a master detail relationship between two Object.
2. On master Object create a rollup summary field which count the child records
3. Now write trigger on child Object which checks if the rollup summary count on master is equal to one then throw an error that the master have already one record attached select another.

• This way every master Object have one record of the other objec hence one to one relaship is established.
• You can follow this link for more detail: http://www.infallibletechie.com/2013/05/how-to-create-one-to-one-relationship.html

Roll-up summary fields

• A roll-up summary field calculates values from related records, such as those in a related list.
• You can create a roll-up summary field to display a value in a master record based on the values of fields in a detail record. The detail record must be related to the master through a master-detail relationship. For example, you want to display the sum of invoice amounts for all related invoice custom object records in an account’s Invoices related list. You can display this total in a custom account field called Total Invoice Amount.
• Roll-up summary fields can be used within a master-detail relationship to summarize data contained within child records. A maximum of 25 (10 prior to Winter 16 release) roll-up summary fields per object can be created.
• It can also be used in:
  • Any custom object that is on the master side of a master-detail relationship
  • Any standard object that is on the master side of a master-detail relationship with a custom object
  • Opportunities using the values of opportunity products related to the opportunity (MDS)
  • Accounts using the values of related opportunities (Exercise in Certifiedondemand)
  • Campaigns using campaign member status or the values of campaign member custom fields
• The types of fields you can calculate in a roll-up summary field depend on the type of calculation. For example,
  • Number, currency, and percent fields are available when you select SUM as the roll-up type.
  • Number, currency, percent, date, and date/time fields are available when you select MIN or MAX as the roll-up type.
• https://help.salesforce.com/HTViewHelpDoc?id=fields_about_roll_up_summary_fields.htm&language=en_US

Rename Objects and Tabs

• You can rename the Standard Tab and Labels, for example, rename Leads to Prospects, this way this name will be reflected in the whole system.

  

  

• Step 2 involves all the fields in the Lead Object, I can rename them 1 by 1

  

• Once renamed, I can see that a tab has been renamed, and by whom. And Lead is now Prospect

  

  

• But in the left side setup menu, Lead is still named Lead.

Picklist vs Object.

Here are a few guidelines to help determine whether it is appropriate to use a picklist or custom object to capture data:

Lookup Filters

• A lookup filter limits which records can be associated within an object relationship.
• For example, when selecting a venue (parent) for a campaign (child), users should only be able to select approved venues. You configure the lookup filter on the “venue” lookup relationship field in the “campaign” Object.
• Go to the filed in question, go to “Lookup Filter” and fill it accordingly
• Now when users try to choose a value that is not approved, they get error message.

Fields:

• Create new field to capture information
• Can later edit the field, delete, undelete, erase (after 15 days delete)
• Standard vs. Custom fields:

  

• Create custom fields: Same way for both standard and custom Objects. What differs is where to click for each.
  • For standard, go to: Build | Customize | Object Name | Fields
  • For Custom: Build | Create | Object – choose the Object name
  • Go to the Custom Fields &Relationship, click on New

  
  

• Field Attributes:
  • Label: How the field appears to users.
  • Name: How the field is referenced programmatically and via the API.
  • Unique: Indicates that only one record within the object can have the specified value.
  • External ID: Used for data operations (upsert) referencing the primary key of an external system.
  • Default Value: Sets the default value for records created.
  • Required: Ensures the field must have a value in order for a record to be saved.
  • By default, each object can have up to 7 (3 prior to Summer 14 Release) unique or external ID fields.
• Field Types:
  • Auto Number: a unique sequence number generated for every record. Read Only, The sequence can be controlled by adding date elements and leading 0s.
  • Checkbox: True/1 for checked False/0 for not
  • Currency: enter a currency amount
  • Date: enter a date or pick it from a popup calendar
  • Date/Time: same, can also add current date/time
  • Email: validated, can’t be used for mass emailing
  • External Lookup Relationship: lookup links child to a parent external object from an external datasource.
  • Formula: automatically calculate values based on other values or fields
  • Geolocation: specify a location by its latitude and longitude. Counts 3 times against org limits
  • Hierarchical Relationship: Allows users to use a lookup field to associate 1 user to another (like manager)
  • Indirect Lookup Relationship
  • Lookup Relationship: See above
  • Master-Detail Relationship: See above
  • Number: enter a number, any leading zeros are removed
  • Percent: will convert a number to percentage. 0.10 = 10%.
  • Phone: enter phone num, with US/Canada format if locale is US/Canada and digits is right. No validated,
  • Picklist: select a single value from a list that you define
  • Picklist (Multi-select): same as picklist, but multi-value
  • Roll-Up Summary: see above
  • Text: any string, You can set a maximum length, up to 255 characters
  • Text (Encrypted): You can set a maximum length of up to 175 characters. Use ASE 128-bit master keys. To enable master encryption key management, contact Salesforce
  • Text Area: up to 255 characters that display on separate lines similar to a Description field
  • Text Area (Long): up to 131,072 characters that display on separate lines
  • Text Area (Rich): With the use of a toolbar, users can format the field content and add images and links
  • URL: When users click on the field, the URL will open in a separate browser window. Can be encrypted.
• Changing field types (e.g. Date/Time to Date) can cause data loss
• Most field types are validated by Salesforce to the corresponding data type (e.g. you cannot enter an invalid email address into an email field, period). There are a few exceptions: picklist fields are not validated via the API, and phone fields are not validated at all.
• Some fields are not validated like: phone. User can type anything in this field. But formatting is only applied when phone typed through UI, user locale US/Canada, number of digits 10 or 11. If you want to make sure that proper phones are entered, use Validation Rules.
• Partial validation like Picklist and Picklist multi-selection: only validated in the UI (can only enter the picklist value), but not the API. You can push any value in API.
• Controlling and Dependent fields: picklist values can be displayed dynamically based on the value of another field. For example, if you choose a country with a picklist, the second picklist can only display the cities of this country:
  • Continent is the controlling field of country
  • Country is the dependent field of continent and controlling field of city
  • City id the dependent field of country

5.3- Given a scenario, determine the appropriate fields and page layouts for custom and standard objects

•  Based on the above, you can now determine the appropriate fields and page layouts for different objects.

5.4- Explain how to create, delete, and customize record types for custom and standard objects

From Video 9: Record Type is the ability to gather data in different ways on the same object (ex. Internal/External Case), each with different fields and process. Record types allow an Admin to configure different page Layouts, Business Processes and Picklist values to different users based on their profiles, or to the same user with many RT options.

• Record Type consists of:

1. Business process (lifecycle): what stages and status? 10 to 50 to 100? For Lead and Solution: Status, and for Opportunity and Case: Stage.
2. Page Layout (group of fields)
3. Create the Record Type itself and then specify the picklist value of other picklist fields. This way each RT have different picklist for fields.

• The user Profile + Record Type = Page Layout displayed
• You need to create all 3 – in this example, Case:

1. Before, go to the field that you want to add picklist values for: Build | Customize | Case | Fields | Status | Case Status Picklist Values – add the picklist values
2. Go To Support Processes: Cases | Support Processes – New – name it internal – Select the picklist values for the Case Status for this Internal Process
   Go To Support Processes: Cases | Support Processes – New – name it external – Select the picklist values for the Status for external process
           
3. Page Layout: internal layout first: Cases | Page Layout | name it internal and base it on the existing layout | add the fields you want and remove fields that are not needed. (Before 2, make sure you created any custom fields you might need in either Record Types)
4. Finally, create the Record Type itself: Cases |Record Types – New – select the Support Process and Profiles that will use it – next – select the page layout for each Profile

• IMPORTANT: After creating Record Type, you can edit picklist values to any pickist field (other than status and Stage, which are the Process).
• Finally, add the “Case Record Type” to both pages layouts for the user to know which type he is having. Now when the profile user wants to open a new case, he gets the options on the screenshot! Note that the description that you put appears here!
• The main RT is called Master RT. And all Records that existed before cresting any RT are part of this Master RT.
• Can also remove Lookup fields that allow Related list (bottom section)
• You can Edit Record Types assignment in the User | Profiles or Permission Sets.
• A user can see Master RT, or RT1/RT2.
• Record types do not influence record-level security by default. However, they can referenced in sharing rules.

5.5- Given a scenario, determine the appropriate record types and business processes for custom and standard objects

• When you need different picklist values based on another fields: no need for RT, use field controlling/dependent
• When you need different picklist value based on profuiles: RT is needed
• When you need different layout based on different profiles: RT is not needed, this can be done through Profile

5.6- Explain the implications of deleting fields

• When a field is deleted, it can be recovered. When a field is erased, it is permanently removed from Salesforce. Deleted fields are automatically erased after 15 days if not undeleted.
• Before deleting a custom field, consider where it is referenced. You can’t delete a custom field that is referenced elsewhere. For example, you cannot delete a custom field that is referenced by a field update or Apex.
• When you delete a custom field, all of the field history data is deleted and changes are no longer tracked.
• A background process periodically runs that cleans up metadata associated with deleted custom fields. This process will affect the Last Modified Date and Last Modified By fields on page layouts, record types, and custom objects.
• Deleted custom fields and their data are stored until your organization permanently deletes them or 15 days has elapsed, whichever happens first. Until that time, you can restore the field and its data. However, the field still counts against the maximum number of custom fields allowed in your organization.

5.7- Describe when to use and how to create formula fields

• Same as Excel formula – not stored in SF, but auto updated and displayed only
• Formula often is used with Roll-Up Summary fields. Roll-up with do math on the child objects.
  • For example, RSF on the parent that adds the Number of Registrations
  • Create Formula field called “Slots Remaining” enter the formula among fields that uses the RSF
• Example, Job Application is Parent and Review is Child using a Master-Detail relation (Hiring App)
• On the parent, you can create a RSF that counts the number of review that an Application has
  • Create custom field of type RSF
  • Summarized Object is Review, Roll-Up Type=count
  • Add it to page layout of Application Object
  • Now create another field on the Application called “Max Reviews” type number. Make it 100.
  • Now let’s create a Formula field to calculate the remaining
  • Go to Build | Create | Object | Application | Custom fields – new
  • Type=formula, and Formula Return Type=number with 0 decimal places
  • Add this Max_Applications__c – Number_of_Review__c
  • Add it to layout (next page)
• A Cross Object Formula is one that references data in a related record. For instance, I could create a formula field on opportunity to display the account’s phone number. When the account’s phone number gets updated, the field on opportunity automatically reflects the change. For exaqmple here, the Formula Text field points to the formula “$Organization.Name” which displays the name of the company.
• Formula fields are read-only (the same is true for roll-up summary fields) for all users.
• For this reason, formula fields will not be displayed when editing records. The value of the formula is only calculated after the record is saved.
• Limitations of Formula Fields:
  • Cannot reference some field types, like not limited to: Text (Long), Text (Rich), Picklist (Multi-Select).
  • Some formula fields cannot be referenced by roll-up summary fields.
• When editing formula syntax, there are two types of editors:
  • The simple editor does not provide access to cross-object formulas or functions
  • Advanced Formula editor, which exposes cross-object variables and functions

5.8- Extra Notes

Person Account:

• Salesforce mainly uses Business accounts, which are used to store information about companies
• On the other hand, Person accounts provide a way to represent an individual as both a contact and an account in Salesforce, and are frequently used to facilitate business-to-consumer (B2C) relationships.
• They are used to store information about individual people. For example, online shoppers, gym members, vacation travelers, or other individual consumers.
• They can’t have contacts. Instead, the it stores the information you’d typically save for business contacts
• You can treat a person account like a contact: invite a person account to a meeting, associate it with campaign
• Enabled via feature request (raising a case with Salesforce).