Attention Trailblazer!

Salesforce has two different user interfaces: Lightning Experience and Salesforce Classic. It’s easy to switch between the two. You can learn about switching between interfaces, enabling Lightning Experience, and more in the Lightning Experience Basics module here on Trailhead.

This module is designed for Salesforce Classic.

Learning Objectives

After completing this unit, you will be able to:
  • Describe the advantages of Force.com objects for app development.
  • Explain the difference between standard objects and custom objects.
  • List the types of custom fields an object can have.
  • List the two types of relationships between objects.

Overview of Objects

The Force.com platform provides a powerful database, with many features that make it faster and easier to create applications. In a relational database, data is stored in tables. Each table comprises a number of columns of a particular data type, such as text, number, or date. Information is stored in rows of the table. Tables can be related to other tables, using primary and foreign keys. Apps manage information by creating, reading, updating, and deleting rows in a table.

The database in Force.com, on the other hand, uses objects to store data. Objects contain all the functionality you expect in a table, with additional enhancements that make them more powerful and versatile. Each object comprises a number of fields, which correspond to columns in a database. Data is stored in records of the object, which correspond to rows in a database.

There are two types of objects.
  • Standard Objects—These are objects included with Salesforce, by default, for example the objects used to store data in standard tabs such as accounts, contacts, or opportunities.
  • Custom Objects—These are new objects you create to store information unique to your organization. Custom objects extend the functionality that standard objects provide. For example, if you’re building an app to track product inventory, you can create custom objects called Merchandise and Invoices, as shown in the figure below.

Schema Builder interface

Objects can have relationship fields that define how records in one object relate to records in another object. These fields play the same role as primary and foreign keys in a database, but they’re more flexible, making it easier to design and implement your data model.

Whether they’re standard or custom, Force.com objects not only provide structure for storing data but also power the interface elements that allow users to interact with the data, such as tabs, the layout of fields on a page, and lists of related records. They also have built-in support for features such as access management, validation, formulas, and history tracking. All attributes of an object are described with metadata, making it easy to create and modify records either through a visual interface or programmatically.

As you can see, objects are a lot more than simply containers for storing data. They provide a rich set of functionality that frees you up to focus on building the features unique to your product. This ensures you can focus your development efforts on the features unique to your product, enhancing productivity and reducing time to market.

Fields and Relationships

Each standard or custom object consists of a set of fields. There are several different types of fields, as described below.

Identity Field

Force.com automatically assigns an identity field (called ID) to every object, and manages the identity data in every record. This identity field usually comes in a 15-character case sensitive form, which you may have already seen while using the platform. For example, when looking at the details of a record, the URL has the form:

https://yourInstance.salesforce.com/0015000000Gv7qJ

Here, 0015000000Gv7qJ is the identifier for the record. Every record in your application will have such an identifier, and as a result you can view every record (across all objects) by simply using a URL of the above form. The platform will automatically retrieve the record and the associated metadata, and display that record using the automatically generated user interface.

System Fields

All objects have a number of read-only system fields automatically associated with them. The ID field, discussed above, is one such field. Others include:
  • CreatedDate—the Date and time when the object was created
  • CreatedById—the ID of the User who created the object
  • LastModifiedById—the ID of the User who last modified the object
  • LastModifiedDate—the date and time when the object was last modified by a user
  • SystemModStamp—the date and time when the object was last modified by a user or process, such as a trigger
The database automatically assigns values to these fields when an object is created or modified.

Name Field

The name field of an object is a required field that has a special place in the life of the object. The record name is intended as a human-readable identifier for a record. It's not required to be a unique identifier, but it is supposed to be the primary way users distinguish one record from another. In the automatically generated user interfaces, you’ll see that the value for the name is always displayed as a link to the record itself, to its own detail page.

A name can be one of two types: a text string or an auto-number field. For an auto-number field, you must specify the format for the field and the starting number. Auto number fields increment by one each time a record is created.

Custom Fields

You can define custom fields, either to extend the functionality of a standard object, or when creating new custom objects. All fields in an object must be defined as a particular data type. Here's a summary of many of the supported data types:

  • Auto Number—a system-generated read-only sequence number, analogous to the SQL identity type. These fields can be used to provide a unique ID that is independent of the internal object ID. These fields are not used in creating object relationships.
  • Checkbox—for representing Boolean data.
  • Date or Date/Time—for representing dates or date and time combinations.
  • Number—for representing real numbers, with optional decimal points.
  • Email, Phone and URL—format-validated email, phone and URL string representations.
  • Picklist and Multi-Select Picklists—represent values from a list.
  • Text and Text Areas—for representing text of various lengths.
  • Currency—a formatted number type, with optional multi-currency support.
  • Formula—a read-only field holding data generated from a formula expression.
  • Geolocation—allows you to identify locations by their latitude and longitude and calculate distances between locations.

The basic Text, Auto Number and Number are found on many relational databases. The Formula field type is somewhat different to the others. Instead of holding a value, it derives its value from a supplied formula expression. The field is then updated whenever any of the source fields are changed. Checkbox fields, Email fields, URL fields and Phone fields include some automatic formatting capabilities when displayed as part of the automatically generated user interface.

Relationship Fields

The Force.com database differs from relational databases in the way that record relationships are implemented. Instead of having to deal with primary keys and foreign keys, to define relationships between data, Force.com uses relationship fields. A relationship field stores the ID of the parent record in a relationship, as well as optionally providing user interface representations in both the parent and child records.

You can define two types of relationship fields.

  • Lookup—This creates a relationship that links one object to another object. The relationship field allows you to navigate from records in one object to the related records in another object (both visually, and programmatically). Lookup relationships can be used to create one-to-one and one-to-many relationships.
  • Master-Detail—This creates a special type of relationship between two objects (the child, or "detail") and another object (the parent, or "master"). Master-detail relationships can be used whenever there is a tight binding between two objects. For example, consider a blog and blog posts. If the blog is deleted, the blog posts should go too. They can also be used to create many-many relationships.
    Note

    Note

    The master object in a master-detail relationship can also contain rollup summary fields. These fields store values aggregated from the child records in the relationship. For example, you can use these fields to count the number of child records, sum values in field of a child record, or determine the maximum/minimum of a field in a filtered set of child record.

The use of relationship fields greatly simplifies the task of designing and implementing an effective data model for your app.

Other Features of Objects

Here is a partial list of features available with all objects.

  • Formulas—Formulas can be used in many places, such as setting up validation rules, creating workflow rule criteria, and even to define a field. A formula field type behaves much like a spreadsheet formula—it reflects some calculation based on other fields and operations on those fields. The formula language is a rich expression language that lets you perform calculations and manipulate strings, dates, numbers and regular expressions.
  • Validation—Validation rules help improve data quality by preventing users from saving incorrect data. These rules use the same formula syntax as found in formula field types to define a formula which is evaluated each time a record is saved. If the formula for a validation rule evaluates as “True”, the save is aborted and an error message displayed. You can define one or more validation rules that consist of an error condition and corresponding error message. For example, you can create a validation rule to ensure that a number falls within a particular range.
  • Triggers—Triggers, written in the Apex language, are pieces of code that can fire before or after a record is saved, updated or deleted.
  • Labels—Every object and record has a label and can include a description, for help, which is automatically included in the user interface.
  • Notes and Attachments—You can create, view, and edit notes and add attachments for any record in an object that has this functionality enabled. This provides users of the object the ability to easily add arbitrary text notes, and upload associated documents, for each record.
  • Track Field History—Certain fields on your objects can be configured to track their history. Any time a user modifies any of the field data whose history is set to be tracked, a new entry is added to an automatically created History related list. This History list tracks the date, time, nature of the change, and who made the change.
  • Security—Database services provide a flexible security model that you can use to control who has access to objects, records and/or fields.

In most cases, you can simply activate and configure these features on your objects to get the desired functionality.

Share Time Estimate
Topics

Having trouble with your challenge verification?

Here are some tips:

  1. Check for typos (hey, it happens)
  2. Try using a new Developer Edition (existing customizations can interfere with the validation)