Describe a Custom Object

A custom object is one that is not initially packaged with the application.  If it isn’t a standard object, it must be a custom object.  An example of a custom object could be a Payroll object created for a custom payroll application.  Accounts, Contacts, Opportunities, and so on are all standard objects.

 

Describe the types of relationships that can exist between objects

One to Many

There are 3 types of relationships that can be created in Salesforce.com – master-detail, lookup, and hierarchical.  Each of these relationships is a one to many relationship.

Many to Many

Many to many relationships are established by creating a linking object.  The linking object must have a relationship to each of the objects it is linking together.  For instance,

In a custom application, two custom objects “Job Posting” and “Applicant” require a many to many relationship.  To do this, create an object “Job Posting Applicant Link” (the name is not important), and create lookup (or master-detail) relationships on this object to both "Job Posting” and “Applicant”.  If master-detail relationships are used, when either a “Job Posting” or an “Applicant” is deleted, all related "Job Posting Applicant Link” records are deleted.

The related lists on Applicant and Job Posting can be configured to displayed the corresponding information from each object through the linking object.

The only way to create a seamless (no visible linking object to the end user) many to many relationship is to use custom code.  Please vote to include this functionality: Pure many-to-many relationships.

See “Creating a Many-to-Many Relationship” for more details.

Relationship types

Master-Detail

• The owner of master record automatically owns all associated detail records.
• Security controls for the master record control the detail record.
• A detail record must be linked to a master record in order to save the record (e.g. you must link an opportunity to account to save the opportunity).
• Only one level deep – a detail object cannot also be a master object.  Please vote to remove this limitation: Multiple Master-Detail relationships.
• A detail record can have two different master records (two master-detail relationships must be created).
  • This feature was released in Summer 08 to give greater flexibility when creating many to many relationships as described above.  Prior to then, only one master-detail record could be present per object, meaning that record deletions for object “Job Posting to Applicant Link” could only be triggered by a “Job Posting” deletion or an “Applicant” deletion; not either.

Lookup Relationship

• One to Many relationship links one record to another record.
• Can link standard to custom objects and vice versa, or link to the same object type (parent account, for instance).

Hierarchical

• A lookup relationship on the user object to the user object (for instance the standard field “Manager”).
• Record cannot point to itself (I cannot be my own manager).

See “Overview of Relationships” for more details.

 

Create a Custom Object

Create –> Objects

Options:

• Label
• Plural Label
• Object Name
  • Used for API calls
• Description
• Context-Sensitive Help Setting
• Record Name
  • Appears on related lists, e.g. “Account Name” instead of “Account”
• Data Type
  • Either text or auto-number.
• Allow Reports
• Allow Activities
• Track Field History
  • Enables the option to track fields- you still need to add the fields to be tracked and add the related list to the page layout.
• In Development / Deployed
  • If listed In Development, only users with the “Customize Application” permission will be able to see it.

 

Describe a Custom Object Tab and a Web Tab

Custom Object Tab

A custom object tab provides a tab to access a custom object.  Creating a custom object tab will do the following:

• Enable search results for the custom object.
• Enable the object as an option in the “Create New…” menu in the sidebar.
• Set the icon that represents the object.
• Set the color scheme for the page layout of the icon.

 

If a custom object does not have an associated tab, it is only possible to access the object (from the UI) through reporting (if enabled) or through related lists where applicable.  Assets is a standard object example of this situation.

Group+ Edition

 

Web Tab

Web tabs can be used link in external content from websites other than Salesforce via an S-Control or URL.  Here is an example of a web tab set to http://www.google.com:

Group+ Edition

 

Create a Custom Object Tab

Create –> Tabs

• Only one tab per object is possible.
• Enabling a splash page for the object will let you configure an introductory page (similar to introductory pages in setup; for instance, email to case setup), and will give the user the following option:
  

 

Create a Web Tab

Create –> Tabs

There are a few more options for web tabs:

• Choose width
  • Full page width – removes left sidebar
  • 2 columns with Salesforce sidebar
• S-Control or URL
• Content Frame Height
  • You can set the maximum height for the frame (this will create a scroll bar within the frame if the page is longer than the height)
• Splash Page Selection

 

Describe a Custom App

An application determines which tabs are listed by default.  A custom application is no different- you can choose from standard/custom objects and what tabs are displayed by default.  A user can customize this list per application specific to their account.

Applicatio
ns have no impact on object, field-level, or tab security (if a tab is hidden on the user profile, it will never be visible).

Example:

Select my custom Projects application:

And get the custom image (Projects Home w/triangle) with just the Projects tab visible:

 

 

Create a Custom App

Create –> Apps

• Custom Image
  • The image must be a document marked as an Externally Available Image to be selectable
• Default Landing Page (Home or object)
• Select tabs
• Assign visibility to profiles

Describe a Profile

Profiles are primarily used to control the permissions for a user- see below.

Explain what a Profile controls

• Tabs shown (Default On, Default Off, Hidden)
• IP restrictions (Enterprise+)
• Object-level security
• Field-level security
• Login hours
• Apex/VF pages accessible
• Console layout
• Selectable applications (sales, call center, etc.)
• Administrative & General User permissions (modify all data, run apex, approve contracts, etc.)

List the Standard Profiles

• Contract Manager
• Marketing User
• System Administrator
• Solutions Manager
• Standard User
• Read Only

Evaluate when to create a Custom Profile

You must create a custom profile if you want to change any of the following on a standard profile:

• Administrative permissions (modify all data, view and setup configuration, etc.)
• General User permissions (manage self service portal, manage cases, etc.)
• Object-level permissions

Standard profiles and custom profiles are essentially the same, except that the above 3 areas of configuration cannot be changed on a standard profile.

Explain the differences between a Custom Field and a Standard Field

Standard fields are created by Salesforce and packaged with the object.  Custom objects are those that you create.

Custom fields and objects always have "__c" appended to the API name.

Side note:  Custom related lists to have "__r" appended to the API name.

List the different types of Custom Fields

Here we go:

• Auto Number (there are some options here, but this is essentially a counter that grows as records are created)
• Checkbox
• Currency
• Date
• Date/Time
• Email
• Formula (covered later)
• Hierarchical (creates a lookup relationship from the user object to the user object and does not reference role- this could be used to create a field for a user’s supervisor)
• Lookup Relationship
• Master-Detail Relationship
• Number
• Percent
• Phone
• Picklist
• Picklist (Multiselect)
• Roll-Up Summary
• Text
• Text (Encrypted) – Available by request only.
• Text Area
• Text Area (Long)
• URL

Set up a Custom Field

(you’re sunk if you haven’t done this a few dozen times already)

Map Custom Lead Fields

1. Create the custom field on the lead
2. Create the custom field on the object that you wish to transfer the information to
3. Map the field (Customize –> Leads –> Fields, Map Lead Fields)

Let’s say I have a field on my lead called "Page Source" (I have mutliple web-to-lead forms running; this page tracks which page the lead was submitted from).  I would create the picklist field "Page Source" on the lead object, and then on the opportunity object, then head back to the lead page and map it over.

Re-label a Standard Object

Customize –> Tab Names and Labels –> Rename Tabs and Labels

Available in Pro+

List objects for which you can enable Field History Tracking

• Accounts
• Cases
• Contacts
• Contracts
• Leads
• Opportunities
• Solutions
• Custom Objects

Notably AWOL: campaigns, assets, ideas, documents, opportunity products, price books, products

Define the dependencies when using a Dependent picklist

Straight-forward.  You select the options you want listed and those you do not by double clicking each of them.

You can have many dependant fields, but only one controlling field.  For instance, you can have the field "Type" control options for the field "SLA" and "Status"; however "Status" cannot have options that change based on "SLA" and "Status".

Picklist dependencies work for Picklist and Picklist (Multiselect) fields only.

Create and modify a Dependant Picklist

Describe the capabilities of Custom Lookup fields

• Create a related list on the other object (for instance, opportunities listed on the account page- the name of the related list is controlled by the lookup field, the fields displayed in the list is controlled by the page layout)
• Enables cross-object formulas (I can create a formula on an opportunity that references a field on the account)

Create and modify a Lookup Field

Describe the capabilities of Formula Fields

Formula fields have an immeasurable number of uses.  See the article "Useful Advanced Formula Fields" for some great examples.

The key is to understand that a formula field can capture and manipulate data.  It can pull data from:

• Any field on the record the formula is created
• Any field on a record that is linked via lookup relationship (a maximum of 5 lookups)- for instance you can create a formula on the opp object and reference account’s data

The key limitation of formula fields is that they cannot reference data in related lists. For instance, you cannot reference any information about the contact roles on the opportunity in a formula because contact roles is a related list, not a lookup (I’ve been burned by this!).

Create and modify a formula field

Describe Roll-up Summary Fields

The key benefit of a roll-up summary is that it performs math on data in related lists. The key limitation is that roll-up summaries are only available for data in a master-detail relationship.

Types of rollup:

• COUNT (record count of related list)
• SUM (addition of field within related list-number/currency/percent only)
• MIN (lowest value within related list-number/currency/percent/date/date-time only)
• MAX (highest value within related list-number/currency/percent/date/date-time only)

You can only set filter criteria for records to enter into the summary.

Example:  Create a field on account that displays the total of all opportunities won for the account:  Create the roll-up summary SUM of opportunity.amount and set the filter criteria to stage=won.

Create and modify a Roll-up Summary Field

Try my example.

Describe the elements within a Page Layout

Page layouts are comprised of sections; each section contains either fields, custom links, or related lists.  Key facts:

• The displayed fields within a related list are controlled by the page layout; the name of the related list is determined by the lookup/master-detail relationship on the other object (see customize a related list below).
• Page layouts can make an object required or read only.  Combine page layouts and field-level security: take the lowest possible permission.  For instance, a "hidden" (field-level permission) will never display regardless of page layout.  Likewise, a field marked "Always require a value in this field to save a record" will always be required on the
  page layout.
• Page layouts are assigned by profile and by record type.

Create and modify a Page Layout

Create, customize, and print a List view

When you click on Accounts and see "My Accounts" next to view- that’s a list view.  Click new to create a new one.  Quick facts:

• Every object that is associated with a tab will have at least one list view.  No tab, no list view.
• You can assign filter criteria to your list view (just like a report).
• You can assign list views to: yourself only, groups, and roles.
• To print a list view click the printable view button on the top right of the page.  Printable list-views can be disabled org wide (user interface settings).

Customize a Related List

Exmple:  Custom object "Sample Object" lookup relationship to account.  Rename the related list from the object doing the looking- in this case edit the lookup to account.  Notice the label in the bottom right "Those Objects".

The fields displayed on the related list are controlled by the page layout.  Here is the account page layout (that should read "Fields displayed in the related list"):

Describe how to use Record Types

Quick facts:

• Enterpise+ only.
• The record type "Master" is always present for every object, but is not listed under the record types list.  It contains all picklist/process options.  It can be assigned as a record type for a profile so long is it the only assigned record type for that profile.
• Each record type is assigned to 1 page layout type per profile.  This means if you have two custom record types for account and 5 profiles, you will have 15 page assignments (5×2 for each custom, and 5 for Master).
• Selectable record types are assigned per profile.
• Field-level security is configured separately for each record type.
  

The overall process for creating a record:

1. What record types are associated with the current profile?
2. If more than 1 record type, prompt user for record type selection.  If just 1, select that record type without prompting.
3. Based upon record type and profile, assign appropriate page layout.
4. Based upon record type, assign the appropriate process and picklist values.

A process is a selection of picklist values specific to an object:

• Lead Process:  Lead Status (open, closed, etc.)
• Sales Process (opportunity):  Stage (won, lost, percentage)
• Support Process (case):  Case Status (open, closed, etc.)
• Solutions Process:  Solution Status (draft, deployed, etc.)

Exampe:  My sales staff sells an opportunity that represents a contract.  My customer service department can then upsell on this contract.  I would create two sales processes, two different record types, and two different page layouts: "Contract" and "CSR Upsell".  I would create a lookup relationship from opportunity to opportunity, and only require/display this only for the CSR profile.  I would also configure the roles of the organization so that they could not modify each others’ opportunities.

Create and modify a Record Type

I would suggest trying to configure my exmaple above.  If you do send me screenshot so I can update this doc 🙂

List the objects that require a business process

Do you remember?

• Lead
• Opportunity
• Case
• Solution

Explain how Field-Level Security affects page layouts and visibility

Apply whatever security is most restrictive between the page layout and field level security of the profile.

Examples:

1. Field level: Hidden
   Page Layout:  Listed normally
   Result:  Not displayed (treated as if it were not listed on the page layout)
2. Field level: Read Only
   Page Layout:  Listed normally
   Result:  Read Only
3. Field level:  Edit
   Page Layout: Read Only
   Result: Read Only

Set up Field-Level Security

Administrative Setup –> Security Controls –> Field Accessibility.  This will allow you to view by fields, profiles, or record types.

Administrative Setup –> Manage Users –> Profiles.  This will allow you to configure field-level security per profile.