Force.com Tutorial
Mock Exam 1
Force.com Introduction
Other Certification sites
Developer Exam Objectives
About ForcePrepare
Tutorial Developer certification
Application and Tabs
Approval and Workflow
Business Logic
Data Loader
General Concepts
Reports and Dashboards
Administration Certification
Admin Exam Objectives
Developer vs admin
Standard objects
Admin tutorial

Welcome to www.ForcePrepare.com
Your tool for Salesforce.com Certification

home | tutorial | Mock Exam

Force.com's objects, fields and relationships

  1. Objects logically correspond to database tables in a relational database. Fields of an object is similar in concept to column in relational database.

  2. Objects can be standard or custom. Standard are objects are predefined by Salesforce like Accounts, Case, Contact etc. Custom objects are created by developers based upon application requirements.

  3. Custom objects have the following characteristics
    1. Custom objects store information that is unique and important to your organization.
    2. Custom objects are reportable and search-able.
    3. Custom objects have configurable access control features.

  4. Force.com provides undelete functionality on objects. Deleted objects go to a recycle bin with an expiry date of 45 days. An administrator may delete objects from recycle bin.

  5. Fields of type Picklist cannot be made required.

  6. There are three type of page layouts:
    1. Detail
    2. Mini
    3. Console

  7. Objects have following fields that need to be entered by developers -
    • Label
    • Plural Label
    • Object Name
    • Description
    • Record Name
    • Record Type

  8. The field for record name is displayed by default when the object has to be displayed (for example in search results). The record type can be text or auto-number. Auto-number can take values like A-{0001}, A-{0002} etc.

  9. The Object name is used to access the object programmatically. __c is added as a suffix to the custom object names. The label name is used for display of the object.

  10. The standard fields are added automatically. Examples of standard fields are Created By, Owner etc.

  11. Custom Fields are added to an object by developers. In the custom object definition detail screen there is a section of custom fields. Click New to create new custom fields in this area.

    Read through the Salesforce customizations at www.npsphelper.com/admin

  12. Custom Fields have properties like:
    • Data Type
    • Field Label
    • Field Name
    • Required checkbox
    • Description
    • Default Value

  13. Examples of valid field types are
    Field TypeComments
    TextText can be upto 255 characters
    Text AreaText Area can be either 255 characters or 32K characters
    PicklistCan be single select or mult-select. The developer needs to provide valid values
    The field types are aligned to user interface elements like picklist and checkbox.

  14. Changing the data type of existing custom fields is possible, but doing so may cause data loss.

  15. Fields can be set as unique, required or as external id. A required field is always displayed in the edit page. A field of type external id is a record id from another system. The performance of reports and SOQL is better for fields defined as external ids. Fields of type number, text and email can be set as external id. Each object can have up to three external ids.

  16. A field defined as encrypted is not visible to users. Typical usage of encrypted field is for password. Only users with "View Encrypted Data" can view the encrypted fields. Encrypted fields are editable.
    1. This is a provisioned feature, so you must contact Salesforce to enable it.
    2. Encrypted custom field cannot be unique, an external ID, or have default values.

  17. Objects can have upto 500 custom fields.

  18. When an object is created, a user interface is created automatically for Create, Update, Read and Delete operations.

  19. Fields of two Picklists can be made dependent on each other. As an example consider an application with customers in US and Canada. If there are two picklists - one for country and the other for state. Based upon user's selections of country, the state settings need to get updated. This is implemented by defining controlling and dependent picklists. In the above scenario, country becomes the controlling picklist and state becomes dependent picklist. The controlling and dependent picklists are defined using "Field Dependency" button in "Custom Field and Relationship" section.

  20. Standard picklist can be controlling picklist but not dependent picklist. Maximum number of values allowed in controlling field is 300. A custom multi-select picklist cannot be controlling field in a picklist.

  21. Merge fields are fields that display values based upon formula calculations.

  22. Salesforce supports history tracking on change in values of fields. This can be enabled for up to 20 fields in an object.

  23. Custom objects can be represented using a Metadata XML.

  24. Deleted data and metadata is stored in recycle bin.

  25. Database tuning is managed by Salesforce. How Objects and fields are stored in the database is internal to Salesforce.

  26. Object Relationships

  27. Force.com allows you to create relationship between objects. The "Custom Fields & Relationship" section of objects is used to define relationship between objects.

  28. There are a two types of object relationships that Salesforce supports -
    1. Lookup relationship
    2. Master-detail relationship
    These relationships are used to implement one-to-many relationship. They are created as fields in the child record. As an example in a recruitment application if one applicant can have many interviewFeedbacks, we could create a lookup (or master detail) relationship in the interviewFeedback object pointing to the applicant object.

    Read through the Relationships at www.npsphelper.com/admin

  29. In Master Detail relationship, if the parent record is deleted, then all its children records are deleted.

  30. Child records in master-detail relationship do not have owners. They inherit ownership from the parent record.

  31. In Master detail relationship, the parent field is required. Also the parent field once specified cannot be changed.

  32. Standard Object cannot be on detail side of Master-Detail relationship.

  33. In the related list section of parent objects, only one field of the child object is displayed by default. This is the field specified as Record Name in the child object. To add more fields, search lookup layout needs to be updated.

  34. Rollup-summary fields are supported in master detail relationship. The parent object can use roll-up summary field type to perform operations of sum, maximum, minimum, count among its children records. These fields are read only fields and are used to calculate values from a set of records.

  35. Many-to-Many relationships are implemented using two master-detail objects. One Junction object is used as the child of the objects between which many-to-many relationship needs to be established.

    Read through the Junction Objects at www.npsphelper.com/admin

  36. The table below compares Master Detail and Lookup relationship
    Lookup relationshipMaster Detail relationship
    Is Parent a required fieldNoYes
    Maximum number of relationship in an object252
    Security of parent determines child record's accessNoYes
    Deleting parent record deletes childrenNoYes
    Parent can be a child in another relationshipYesNo
    Roll-up summary in parent supportedNoYes

  37. Self relationship is a lookup relationship to itself. An example usage could be organization chart where an employee's manager is also an employee.

  38. Hierarchy Relationship exists only for User object. In this, developers create a manager field in User object to relate to another object.

home | tutorial | Mock Exam