Salesforce Fields
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.
- The first three characters represent Object API eg: 001 --> Account object.
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 pro-grammatically). 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 eg: 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.
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 eg: 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.
Step by Step process to create Custom Field Relations
Please add your comments.
Step by Step process to create Custom Field Relations
Please add your comments.
Comments