Salesforce Object Model

Objects are key components in Salesforce.com. They allow you to store your data. Similar to a table in a database, an object consists of several fields to store data. You can set some fields as mandatory, while some other fields such as ID, Created Date, Created By, Last Modified Date, and Last Modified By will be automatically populated by the system.

You can illustrate an object as a table, a field as a column in the table, and a record as a row in the table. In the following table, field 1 will store the values for all first names, field 2 will store the values for all birth dates, and so on:

	field 1	field 2	field 3
record 1	John	29 Jun	…
record 2	May	10 Dec	…
record 3	Steve	24 Feb	…

There are two type of objects in Salesforce:

• Standard object
• Custom object

Standard objects

Standard objects are provided by Salesforce.com by default. Each standard object has its own uniqueness, and the objects are named by their common uses. Some of the main Salesforce.com objects when you subscribe for Sales or Service Cloud are as follows:

• Account: This is used to store information about the businesses and organizations your company interacts with.
• Contact: This is used to store information about the people associated with your customers.
• Opportunity: This is used to store information about sales interactions with your customers. It is often known as the sales cycle.
• Lead: This is used to store information about people who may become customers or partners of your company.
• Case: This is used to store information about interactions with your customers related to the products or services you provide.
• Campaign: This is used to store information about your company's marketing activities and responses.

Some other standard objects are Activity, Asset, Contract, Quote, Order, Products, and Price Book.

Each standard object comes with default fields based on the purpose of the object, for example, Stage in Opportunity and Mobile Phone in Contact. You can create your own fields in a standard object called custom field. The maximum number of fields you can create depends on the Salesforce edition purchased.

Note

You can upgrade Salesforce.com to a higher edition simply by paying the increased subscription fee, and continue using the same organization with the existing database and customization. But if you plan to "downgrade" to a lower edition (it is actually not possible to downgrade), Salesforce.com will give you a brand new organization where you will need to reconfigure and transfer all your data.

Custom objects

Custom objects are specific objects created in your organization to store data for your business that does not fit into standard objects. Only a user with admin access is allowed to create custom objects. Most AppExchange packages create and use custom objects, since they provide specific business processes.

The maximum number of custom objects that can be created depends on the Salesforce edition. If you have admin permission, you can create objects and fields in Salesforce with just point-and-click rather than using complex SQL scripts as in traditional databases.

For a standard object, the number of standard fields depends on the object itself, but a custom object comes with a few standard fields that are the same for all custom objects:

• Id
• Name
• Created By and Created Date
• Last Modified By and Last Modified Date
• Owner (if the object is not a child of another object in a master-detail relationship)

Just as with a standard object, you can create custom fields in a custom object.

Object relationships

You can relate an object to other objects in Salesforce.com, for example, relating the Expense custom object to the Project custom object. With this relation, you can know for which project the specific expense is used. In this example, Project will be considered as the parent and Expense as the child object. Remember that one parent can have many children, while the child can have only one parent. To build this relationship from the child object, create a lookup or master-detail relationship field for the parent object.

There are two types of object relationships in Salesforce.com:

• Master-detail relationship
• Lookup relationship

Here is the comparison between master-detail relationships and lookup relationships:

Master-detail relationship	Lookup relationship
You can define master-detail relationships between custom objects or between a custom object and a standard object (standard object must be the parent).	You can define a relationship between any two objects, standard or custom.
When a record in a master object (parent) is deleted, all the records in the detail object (child) that are related to that master record will be deleted.	When a parent object is being deleted, you can configure a child object to either clear the parent record value in the child record or prevent deletion of the parent record.
All child records must have a related parent record.	The parent record may not require a related parent record.
The ownership of the child record is determined by the related parent record. Child records do not have an owner.	Each child record has an owner and is not related to the parent record.
The detail record inherits sharing and security from the master record.	There is no security or inheritance between related parent and child records.
To relate an object to another object, no records should exist in the child object.	To relate an object to other objects, there is no condition on the number of records.
If you have the Roll-Up Summary field in the parent object, any create, edit, or delete action in the child record will trigger an edit action in the parent object. If you have a validation rule and other rules in parent object, the validation rules will trigger for the parent object.	You cannot create the Roll-Up Summary field in the lookup relationship using out-of-the-box Salesforce functionality.
Supports cross-object workflow. You can configure a field update action to update a field in the parent record using a value from the child record.	Does not support cross-object workflow.

Tip

To create a master-detail relationship for an existing object with records as the child object, you can initially define it as a lookup relationship, populate all parent fields for all records, and then change the relationship to a master-detail relationship.

You can build a many-to-many object relationship using two master-detail relationships in a single custom object, which is known as a junction object in that case.

Field types

Salesforce.com comes with field data types that fit your business model. Some of them are built with business logic, such as e-mails and URLs, these need to follow valid e-mail and URL formats respectively. Invalid values will be automatically rejected by the system. When you define custom fields, the data type you select determines which additional options you can specify Required, Unique, Case sensitive, External ID, and Default Value.

Here is the list of Salesforce's data types:

• Auto Number
• Formula
• Roll-Up Summary, if the object is a parent in a master-detail relationship
• Hierarchical Relationship (only for the User object)
• Lookup relationship
• Master-detail relationship
• Checkbox
• Currency
• Date
• Date/Time
• E-mail
• Geolocation
• Number
• Percent
• Picklist
• Picklist (multi-select)
• Text
• Text Area
• Text Area (long)
• Text Area (rich)
• Text (encrypted)
• URL

Sandbox or Developer Edition?

It is advised that you get your hands on all exercises in this book in a Sandbox org or Developer Edition, not in the production environment, as you might change something without knowing.

If you do not have Sandbox org for testing, you can sign up and get Developer Edition for free by clicking on Sign Up at https://developer.salesforce.com/page/Developer_Edition.

Sandbox has an exact copy of your production configuration on the date of Sandbox creation or Sandbox refreshes. Depending on the Sandbox type, you can have a complete copy of production data, partial data, or no data in a Sandbox, but all of them will have a configuration copy from the production environment. We will discuss more on Sandbox in Chapter 2, Managing Data in Salesforce.com.

While Developer Edition is an environment without any relation to your production environment, it is good enough for you to try anything explained in this book.