Objects in Salesforce

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.

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.

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, 

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 the 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.

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 to “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.