Schema Builder
Schema Builder gives you a visual overview of all the objects, object relationships, and fields on all of the objects.
The Schema Builder gives you three main functions.
1.Get a drone-level view of your org
You can visualize and edit your data model directly from the Schema Builder.
This is the only standard tool in Salesforce that gives you an overall visual of your data model.
2.Create objects
you can create objects in the Schema Builder.
You can set the attributes and do all those things you can do from the object manager.
Note :
The only thing you cannot do from Schema Builder is to create a tab, but that can be done in the standard way.
3.Create fields and object relationships
you can create fields and object relationship fields in the Schema Builder.
It's an easy-to-use drag-and-drop tool, and you can create any data type field except for geolocation fields.
Summary :
1.Schema Buider gives a visual high-level view of the data model.
2.Create custom objects,fields and object relationships.
3.A powerful drag and drop tool.
4.Far more efficient than using the object manager.
Object Relationship :
1.Lookup
A lookup field establishes a one-to-many, parent-child relationship between the objects.
The lookup field is on the child object. It allows the child records to be in a related list on the parent record.
1.Both records retain their own security and sharing independently of each other.
2.The parent and the child records, have separate ownership.
3.By default, there is no cascade delete. In other words, if the parent is deleted, the child records will not also be deleted automatically.
This could be requested of Salesforce to enable this, but it's dangerous.
Carefully consider if you really want child records to be deleted when the parent is deleted, before you request this of Salesforce.
4.If the lookup field is required, then you cannot delete the parent record.
5.The OWD settings on the parent and child objects are independent of each other.
Lookup Field Options
what to do if the lookup parent record is deleted?
a.Clear the value of the lookup field.
b.Don't allow deletion of the lookup record that's part of the relationship.
This is probably the most common option chosen by Salesforce customers.
c.By default, no cascade delete.
d.Cascade delete by request to Salesforce to "enable cascade delete" feature.
2.Master-detail
A master detail field establishes a one-to-many parent-child relationship.
The master-detail field is on the child object.
This is why we see the child or detail records in a related list on the parent or master object.
-> Inherited Security :
Master-detail fields establish a tight relationship. There is inherited record security.
If a user could access the parent, they could access all the child records.
-> Inherited Ownership :
There is inherited ownership. If the user owns the parent, they will own all the child records.
->Two master-detail fields per object.
There is a maximum of two master-detail fields per object.
Note : The total number of relationship fields, which are lookups and master details combined, is 40 per object.
-> Cascade delete
Using a master-detail field means that there is cascade delete for the detail records.
If the master is deleted, the detail or child records are also deleted.
-> OWD for the detail object will be 'controlled by parent'
The OWD on the detail object will be set to controlled by parent and it cannot be changed.
Master-detail Field Options
a.Allow reparenting :
When creating the master-detail field, you can allow reparenting of the detail records, which is a best practice.
If the master record must be deleted, the detail records can be reparented to another master record.
b.Sharing Setting :
When you create the field, you set the minimum access required on the master to create, read, edit, or delete the related detail records.
->Read only allows users with at least read access on the master record to create, read, edit, or delete the related detail records
->Read/write allows users with at least read/write access on the master record to create, read, edit, or delete the related detail records.
Advantage of Master-detail Relationship :
1.Allows for the creation of rollup summary fields on the parent(master)object.
You can create them on any custom object that is on the master side of the relationship, the parent.
You can create them on any standard object that is on the master side of a master-detail relationship.
2.Rollups can calculate the count, sum, min, or max on the child records.
->Count gives account of all or a filtered subset of detailed records.
->Number, currency, and percent fields are available when you select sum as a rollup type.
->Number, currency, percent, date, and datetime fields are available when you select min or max as a rollup type.
->Min and max work with date fields, min would give you the most recent, and max would give you the oldest.
Lookup and Master-detail Filters :
There are times when you might not want to look up all the records using the lookup or master-detail, but a subset of records.
It is very common to have a desire to view just a subset of records with lookups or master-detail fields.
Filter criteria allows you to filter based on the current child record that you're working with, the lookup or parent record,
the user record of the user, their permissions or role, and any records related to the parent object.
Note :
1.Lookup filters restrict results to a subset of records.
2.Filter criteria allows comparing fields and values on :
->The current (child) record.
->The lookup (parent) record.
->The user's record,permissions and role.
-> Records directly related to the target(parent) object.
Junction Objects :
The purpose of a junction object is to create a many-to-many relationship.
Note :
The standard object cannot be on the detail side of a master-detail relationship.
The first master-detail relationship you create on the junction object becomes the primary relationship.
So when you create a junction object, you will strategize a bit to determine which of the master-detail relationships you want to be the primary.
The junction object inherits the look and feel of the primary master object.
Additionally, the primary object will be the primary object in standard report types.
Salesforce will create standard reports using the primary object as the primary report type in the report and also use the secondary object as the primary in the report type.
Sharing access to the junction object record is determined by the users sharing access to both associated master records and the Sharing Setting option on the master‑detail relationship field.
Note :
User selects minimum level of access required on master record to CRED related detail records.
Read only, which means that if the OWD of both objects is set to public read only or public read/write,
they will be able to create junction object records.
But if either one of the object's OWD is set to public read only, and either of the master-detail records sharing on the field is read/write,
the user will get an insufficient privileges error.
1.The junction object records inherit the value of the Owner field from their associated primary master record.
2.Objects on the detail side of the relationship do not have a visible Owner field.
Note :
Two standard report types are created with junction objects.
Salesforce creates a report type with the primary master object, the junction object,
and the secondary master object in the primary master object's report category.
Salesforce also creates a standard report type with the secondary master object, the junction object,
and the primary master object in the secondary master object's report category.
Record Deletion Implications :
1.The junction object records are deleted when either associated master record is deleted and they are placed in the Recycle Bin.
2.If both associated master records are deleted, the junction object record is deleted permanently and cannot be restored.
Junction objects establish a many-to-many relationship.
The first master‑detail relationship created on the junction object is the primary relationship, and it causes the junction object to inherit look and feel, and also affects the standard report types created.
The sharing access to a junction object record is determined by the user sharing access to both associated master records in the OWD and the Sharing Setting option on the relationship field.
If the OWD on the object is public read‑only, then you cannot put read/write on the master‑detail relationship or you will get insufficient privileges.
Note :
You could use lookup relationships for creating the many-to-many relationship,
but that will not support the entire features of the many-to-many concepts that you get by using master-detail fields.
Converting Relationship Fields and Data Skews :
1.Converting a master-detail field to a lookup field
You cannot convert a master-detail field into a lookup if there are any roll-up summary fields on the master object.
This is because lookups do not support roll‑up summary fields.
We need to delete our roll-up summary field and erase it out of memory before we can convert the master-detail to a lookup.
Converting a master-detail relationship to a lookup for a custom object on the detail side changes the organization-wide defaults for the object to Public read/write.
2.Converting a lookup field to a master-detail field
We can convert a lookup relationship to a master-detail if the lookup fields in all the records contains a value, that's because that is required in a master-detail relationship.
Converting a lookup to a master-detail relationship changes the organization-wide default to controlled by parent and field sharing setting is updated to read/write.
Data Skews :
if you do have an org that has 10,000 records in any object, you need to consider Data Skews.
There are three types of skews.
1.Account Data Skew
2.Lookup Data Skew
3.Ownership Data Skew
Account Data Skew :
Since the account object in Salesforce maintains special relationships with many child objects,
if too many child records are associated with an account, it creates issues with record locking and sharing performance.
ex :
An account record with over 10,000 contact records if you're updating that many child records with the same account parent and multiple threads.
For each update, the system locks both the child being changed and its parent to maintain integrity in the database.
OwnerShip Data Skew :
This is defined as a single user or queue owning most of the records of a particular object.
it can cause performance issues if that user is moved around the role hierarchy or moved into or out of a role or group
that is the source group for a sharing role. In these cases, Salesforce must do a lot of calculations in the sharing tables of records,
which can lead to long-running recalculation of access rights. Distributing ownership of records across a greater number of users
will decrease the chances of having long-running updates occurring.
Lookup Data Skew :
This happens when a large number of records are associated to a single record in the lookup object.
An example would be 300,000 account records with a lookup to a custom object with three records in it,
and one of those three records must be chosen with the lookup field on the account.
Every time an account is inserted or updated, the relevant lookup target records, which are the three custom object records, have to be locked.
If this were not so, and someone deleted one of the three custom object records while the insert or update was happening,
it would cause Salesforce to blow up, or at least be a reference integrity issue.
how can these skews be mitigated?
1.For account record skews, consider breaking any account with more than 10,000 child records into separate accounts.
2.For ownership skews, if a single user owns more than 10,000 records, they should not hold the role in the role hierarchy.
If they do, put them in a separate role at the top of the hierarchy.
Another way to mitigate would be to distribute ownership of the records to another user or users.
3.For lookup fields, consider using a picklist instead of a lookup field, or distribute the skew to a wider number of records.
No comments:
Post a Comment