Fields and Relationships in Salesforce

instagram | bugendaitech  Twitter | bugendaitech  Linkedin | bugendaitech

Fields are an integral part of record creation. They are used to store different attributes of the same object or an entity.

Fields in Salesforce

There are majorly two categories of fields in Salesforce. Firstly we have Standard Fields which are prebuilt in salesforce. Even though we have the privilege of editing this field but in no way it can be deleted. Still want to get rid of it? Well, lucky for us with field visibility settings we can hide it from page layouts. Next, let’s also have a look at Custom Fields. These fields are defined by us i.e. the user which can either be used to extend the functionality of a standard object or add fields to our custom objects. 

The table below lets us know about the types of fields we will come across in  Salesforce.

Field Type
Description
IdentityCase-sensitive, 15 character field which gets generated for every record. Example: 50130000000014c
SystemRead-only fields which give information about a record from the system. Example:CreatedDate, LastModifiedById, LastModifiedDate.
NameText names or auto-numbered names which increment upon record creation. This field is required.
CustomUsers created fields on either standard or custom objects.

What happens at field creation?

The first step at field creation involves selection of its data type. It tells us about the kind of information the field stores. Some of the common data types we might run into includes Checkbox, Date, Text, Number etc.

Unique Fields: Fields can be made unique which would impose no duplicate records to be entered. For example an email field.

Required fields: This field makes it mandatory for a value to be added at record creation. It cant be null. For example: Phone number.

External ID: Used to identify the records uniquely from the external system. For example while importing data from excel sheet to salesforce this field comes in handy.

Overview of Field level security:

Field level security in salesforce controls visibility, accessibility and manipulation for a particular field on an object. It can be applied to multiple fields on a single profile or permission set and can also be applied to a single field on all profiles.

Field Dependencies

They are the filters which allow us to change the contents of a picklist based on the value of another field. City and state is a good example of field dependency where city will be the dependent field and state will be the controlling field.

Relationships

Similar to the concept of relationships that we studied in RDBMS which was introduced to remove data inconsistency and data redundancy, Salesforce also provides us the same concept which can be implemented using Relationship fields.

Lookup relationship:

These share weak association among the two associated objects. 

Special type of lookup relationship:

Self relationship Lookup
Hierarchical Lookup

When an object has a lookup with itself, it is a self-relationship.

Example: Employees referring to a manager who is also an employee.

When a lookup field associates one user with another that does not directly or indirectly refer to itself.
SystemRead-only fields which give information about a record from the system. Example:CreatedDate, LastModifiedById, LastModifiedDate.

Master detail Relationship:

It represents a strong relationship between a master and a detail object. Detail records cannot exist without a master record. Detailed objects inherit the security and sharing settings of master objects. There is one thing to keep in mind that we cannot use standard objects on the detail side of a master-detail relationship. Example: Multiple Employees can be associated with a company

Junction Object:

A custom object with two master-detail relationships. This object helps us in establishing a many to many relationship between two objects. Let’s understand this with a scenario of students filling up application forms. We know that multiple students can fill the same application. Vice versa, multiple applications may be filled by one student. This can be achieved by a third object  “Student Application” which links students and applications.

Leave a reply