Data Modeling and Management

Question 1

Given a set of requirements, determine the appropriate data model.

• Expect scenario based questions and select whether to apply look up ,master-detail or junction relation

Answer 1

There are two main 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. When you define a lookup relationship, you have the option to include a lookup field on the page layouts for that object as well as create a related list on the associated object’s page layouts.

For example, if you create a lookup relationship field on a Job Application object that references position records, many job application records can be related to a single position record. This will be reflected both with a new Position field on the job application record and with a new Job Applications related list on the position record. You can also put multiple lookup relationship fields on a single object, which means that the Job Application object can also point to a Candidate object.

Master-Detail

This creates a special type of relationship between two objects (the child, or detail) and another object (the parent, or master). This type of relationship closely links objects together such that the master record controls certain behaviors of the detail and subdetail record. In a master-detail relationship, the ownership and sharing of detail records are determined by the master record, and when you delete the master record, all of its detail records are automatically deleted along with it. Master-detail relationship fields are always required on detail records.

Master-detail relationships can be used whenever there is a tight binding between two objects. For example, say your recruiting app has a Review custom object that contains an interviewer’s feedback on a job application. If you delete a job application record, you will probably want all of its review records deleted as well. In this case, you would create a master-detail relationship on the Review custom object with the Job Application object as the master object.

Differences Between Lookup and M-D

There are fundamental differences between the two types of relationships in areas such as data deletion, sharing, and required fields in page layouts.

Master-detail relationships are typically used when there is a direct dependency between the two objects. These relationships have the following unique features.

• You can’t create a detail record without a master record.
• When you delete a master record, all its detail records are automatically deleted.
• The detail record inherits sharing rules from the master record.
• The number of master-detail relationships you can use are limited, depending on your edition and license.
• You can’t set profile object permissions for a detail record. The detail record inherits permissions from the master record.
• Master-detail relationships are automatically included in report record types.

Lookup relationships are appropriate when a relationship between two objects is required in some cases, but not always. Typical scenarios for lookup relationships are:

• To reference commonly shared data, such as reference data.
• To relate multiple parent records to the child record.
• To link two objects together when you don’t want the behavior of the master-detail relationship, such as sharing rules, profile permissions and cascade delete.
• If the detail object has its own tab, then you probably want to use a lookup, and not a master-detail, relationship.

You can convert a master-detail relationship to a lookup relationship as long as no roll-up summary fields exist on the master object. You can convert a lookup relationship to a master-detail relationship, but only if the lookup field in all records contains a value.

Question 2

Describe the capabilities of the various Generic relationship limits and the implications of each on record access, user interface (UI), and object-oriented programming.

Answer 2

Review the following considerations before creating relationships between objects:

Relationship Limits -

• Each custom object can have up to two master-detail relationships and many lookup relationships. Each relationship is included in the maximum number of custom fields allowed.

Converting Relationships -

• You can convert a master-detail relationship to a lookup relationship as long as no roll-up summary fields exist on the master object.
• You can convert a lookup relationship to a master-detail relationship, but only if the lookup field in all records contains a value.

Self Relationships

• You can create a relationship from an object to itself, but it must be a lookup relationship, and a single record can’t be linked to itself. However, a record can indirectly relate to itself. For example, the Holiday Promotion campaign can have the Direct Mail campaign selected in the lookup relationship, and the Direct Mail campaign can have the Holiday Promotion campaign selected in the lookup relationship.
• You can’t create a many-to-many self relationship, that is, the two master-detail relationships on the junction object can’t have the same master object.

Icons for Custom Related Lists

• The icon you select for the associated custom tab also displays in any custom related list you create based on a relationship.
• Custom related lists do not include an icon if they are based on a relationship with a custom object that does not have a custom tab.

Question 3

Describe the capabilities of the Master Detail relationship type and the implications of each on record access, user interface (UI), and object-oriented programming.

Answer 3

Master-Detail Relationships

• To create multilevel master-detail relationships, you need the “Customize Application” user permission.
• When you define a master-detail relationship, the custom object on which you are working is the “detail” side. Its data can appear as a custom related list on page layouts for the other object.
• By default, records can’t be reparented in master-detail relationships. Administrators can, however, allow child records in master-detail relationships on custom objects to be reparented to different parent records by selecting the Allow reparenting option in the master-detail relationship definition.
• You can have up to three custom detail levels.
• Standard objects can’t be on the detail side of a custom object in a master-detail relationship.
• An object can appear once in multilevel master-detail relationships. For example, a subdetail object in one multilevel master-detail relationship can’t also be the owner of the master object in another multilevel master-detail relationship. A subdetail object can’t also be the master object of the subdetail object’s detail object.
• Multilevel master-detail relationships do not support division transfers.
• You can’t create a master-detail relationship if the custom object already contains data. You can, however, create the relationship as a lookup and then convert it to master-detail if the lookup field in all records contains a value.
• Converting relationships from lookup to master-detail, or from master-detail to lookup behaves the same as for two-object master-detail relationships. That is, the two linked objects in the detail-subdetail1, or subdetail1-subdetail2 relationship have the same conversion limits as the master-detail relationship.
• Roll-up summary fields work as in two-object master-detail relationships. A master can roll up fields on detail records; however, it can’t directly roll up fields on subdetail records. To achieve this, the detail record must have a roll-up summary field for the field on the subdetail record, allowing the master to roll up from the detail’s roll-up summary field.
• You can use multilevel master-detail relationships in custom report types. The Allow Reports checkbox must be checked when you create the custom object. Custom report types created for multilevel master-detail relationships count towards the organizations custom report type limit and no reports are generated if this limit is exceeded.
• Custom junction objects can’t have detail objects. That is, a custom junction object can’t become the master object in a multilevel master-detail relationship.
• You can’t delete a custom object if it is on the master side of a master-detail relationship. If you delete a custom object that is on the detail side of a master-detail relationship, the relationship is converted to a lookup relationship.
• Deleting a detail record moves it to the Recycle Bin and leaves the master record intact; deleting a master record also deletes related detail and subdetail records. Undeleting a detail record restores it, and undeleting a master record also undeletes related detail and subdetail records. However, if you delete a detail record and later, separately, delete its master record, you cannot undelete the detail record, as it no longer has a master record to relate to.
• As a best practice, don’t exceed 10,000 child records for a master-detail relationship.

Question 4

Describe the capabilities of the Lookup relationship and the implications of each on record access, user interface (UI), and object-oriented programming

Answer 4

Lookup Relationships

• If the lookup field is optional, you can specify one of three behaviors to occur if the lookup record is deleted:
  
  • Clear the value of this field This is the default. Clearing the field is a good choice when the field does not have to contain a value from the associated lookup record.
  • Don’t allow deletion of the lookup record that’s part of a lookup relationship This option restricts the lookup record from being deleted if you have any dependencies, such as a workflow rule, built on the relationship.
  • Delete this record also Available only if a custom object contains the lookup relationship, not if it’s contained by a standard object. However, the lookup object can be either standard or custom. Choose when the lookup field and its associated record are tightly coupled and you want to completely delete related data.
    
    • Warning​: Choosing Delete this record also can result in a cascade-delete. A cascade-delete bypasses security and sharing settings, which means users can delete records when the target lookup record is deleted even if they don’t have access to the records. To prevent records from being accidentally deleted, cascade-delete is disabled by default. Contact Salesforce to get the cascade-delete option enabled for your organization.
    • Cascade-delete and its related options are not available for lookup relationships to business hours, community, lead, price book, product, or user objects.
• ​In a chain of lookup relationships, these behaviors work independently on each target field at each level. Say, for example, field A is the target lookup of field B, which in turn is the target lookup of field C. You can have a delete restriction on A and none on B, which means that A can’t be deleted but B can. Once B is deleted, the relationship between A and B no longer exists and C will hold an empty value for the lookup.
• In a multilevel lookup relationship, these options might conflict. For example, in the scenario where field A is the target lookup of field B, which in turn is the target lookup of field C, you might specify that A can delete B, but B cannot be deleted because it’s in a relationship with C. If you try to delete A, you’ll get an error saying that B can’t be deleted because it’s linked to C.
• If the parent record in a lookup relationship is deleted, the field history tracking for the child record does not record the deletion. For example, if a parent account is deleted, the Account History related list for the child account does not show the deletion.​

Question 5

Describe the capabilities of the Junction relationship type and the implications of each on record access, user interface (UI), and object-oriented programming.

Answer 5

Many-to-Many Relationships

• Junction object records are deleted when either associated master record is deleted and placed in the Recycle Bin. If both associated master records are deleted, the junction object record is deleted permanently and can’t be restored.
• Sharing access to a junction object record is determined by a user’s sharing access to both associated master records and the Sharing Setting option on the relationship field. See Custom Object Security. For example, if the sharing setting on both parents is Read/Write, then the user must have Read/Write access to both parents in order to have Read/Write access to the junction object. If, on the other hand, the sharing setting on both masters is Read-Only, a user with Read-Only rights on the master records would have Read/Write access to the junction object.
• In a many-to-many relationship, a user can’t delete a parent record if there are more than 200 junction object records associated with it and if the junction object has a roll-up summary field that rolls up to the other parent. To delete this object, manually delete junction object records until the count is fewer than 200.
• The first master-detail relationship you create on your junction object becomes the primary relationship. This affects the following for the junction object records:
  
  • Look and feel: The junction object’s detail and edit pages use the color and any associated icon of the primary master object.
  • Record ownership: The junction object records inherit the value of the Owner field from their associated primary master record. Because objects on the detail side of a relationship do not have a visible Ownerfield, this is only relevant if you later delete both master-detail relationships on your junction object.
  • Division: If your organization uses divisions to segment data, the junction object records inherit their division from their associated primary master record. Similar to the record ownership, this is only relevant if you later delete both master-detail relationships.
• The second master-detail relationship you create on your junction object becomes the secondary relationship. If you delete the primary master-detail relationship or convert it to a lookup relationship, the secondary master object becomes primary.
• Roll-up summary fields that summarize data from the junction object can be created on both master objects.
• Formula fields and validation rules on the junction object can reference fields on both master objects.
• You can define Apex triggers on both master objects and the junction object.
• A junction object can’t be on the master side of another master-detail relationship.
• You can’t create a many-to-many self relationship, that is, the two master-detail relationships on the junction object can’t have the same master object.

Question 6

Describe the capabilities of the External Object relationship types and the implications of each on record access, user interface (UI), and object-oriented programming.

Answer 6

Relationships on External Objects

Lookup, external lookup, and indirect lookup relationships have some special behaviors and limitations.

• Only lookup, external lookup, and indirect lookup relationships are available for external objects. No other relationship types are supported.
• Relationships that involve external objects allow users to create child records from the record detail pages of parent records. However, the relationship field on each new child record isn’t automatically populated to identify the parent record.
• Syncing doesn’t create relationship fields on the external objects in your Salesforce org. However, you can change the field type of a sync-created custom field to Lookup Relationship, External Lookup Relationship, or Indirect Lookup Relationship. Changing the field type of an existing custom field is simpler and more efficient than manually creating a relationship field on the external object.
  
  • For example, suppose that the external system has a foreign key relationship. Syncing the related tables creates a text field in your org for the external column that identifies the foreign keys. To reflect the foreign key relationship within your org, change the field type of that text field to External Lookup Relationship.
• A relationship field is a type of custom field. Therefore, like all custom fields on an external object, relationship fields can be overwritten when you sync the external object. See the sync considerations for each Salesforce Connect adapter that you use.
• Cascade-delete isn’t available for external object relationships.
• In Salesforce Classic only, external lookup and indirect lookup relationship fields don’t display the expected names of parent records.
• An external lookup field displays either the parent object ID or the value of the parent object’s External ID standard field. The latter appears by default. If, however, a custom field on the parent object has the Is Name Field attribute, the parent object ID is displayed.
• An indirect lookup field displays the value of the target field on the parent object. To find related records, target field values are matched against the values of the indirect lookup relationship field on the child object. The target field, which has the External ID and Unique attributes, is selected when an indirect lookup field is created.
• When a user tries to edit an external lookup or indirect lookup relationship field, a lookup dialog isn’t available for selecting the parent record.
  
  • To edit an external lookup relationship field, manually enter the value of the External ID standard field for the parent record.
• To edit an indirect lookup relationship field, manually enter the value of the target field of the parent record. The target field is the custom field with External ID and Unique attributes that was selected when the indirect lookup relationship was created. To determine related records, Salesforce matches target field values against the values of the indirect lookup relationship field on the child object.
• With external lookup and indirect lookup relationships, the parent record appears as a clickable link in the relationship field on the child record. If the child record is viewed by a user who doesn’t have access to the parent record, the parent record appears in the relationship field as plain text instead of a link.
• Lookup filters aren’t available for external lookup relationship fields.
• Indirect lookup relationship fields can be created on external objects only.
• Only objects that have a custom field with the External ID and Unique attributes are available as parent objects in indirect lookup relationships. If you don’t see the desired object when you create an indirect lookup relationship field, add a custom unique, external ID field to that object.
• If the external system uses case-sensitive values in the specified External Column Name, make sure that the parent object field is also case-sensitive. When you define the parent object’s custom field, select External ID, Unique, and Treat “ABC” and “abc” as different values (case sensitive).

Question 7

Describe the impact of relationships on Reports and the implications of each on record access, user interface (UI), and object-oriented programming.

Answer 7

Impact of Relationships on Reports

• The type of relationship you create affects which standard report types are available and how they are categorized. These report types determine which related objects can be included in the report:
• Lookup relationships allow data from the two related objects to be joined in one report.
• Master-detail relationships allow data from three objects to be joined in one report: the master object, the detail object, plus one other lookup object. If the detail object has multiple lookup relationships, a separate report type is available based on each lookup.
• Many-to-many relationships provide two standard report types that join the master objects and the junction object. The report types are:
• “Primary master with junction object and secondary master” in the primary master object’s report category.
• “Secondary master with junction object and primary master” in the secondary master object’s report category.
• The order of the master objects in the report type is important. The master object listed first determines the scope of records that can be displayed in the report.
• The reporting impact of each relationship type is summarized in the following table:

Question 8

Describe the impact of schema design and modifications on Apex Development.

Answer 8

• Changing from lookup to master-detail has child record deletion impacts when master record is deleted.
• master detail rels. make data management more difficult in that parents must be set first before children so that the relationship field is populated.
• • adding relationships may not be handled already in existing code
    *

Question 9

Describe how to visualize and create entity relationships.

Answer 9

Schema Builder is enabled by default and lets you add the following to your schema:

• Custom objects
• Lookup relationships
• Master-detail relationships
• All custom fields except: Geolocation

Question 10

Describe the options for and considerations when importing and exporting data into development environments.

Answer 10

Salesforce offers two main methods for importing data:

• Data Import Wizard—this tool, accessible through the Setup menu, lets you import data in common standard objects, such as contacts, leads, accounts, as well as data in custom objects. It can import up to 50,000 records at a time. It provides a simple interface to specify the configuration parameters, data sources, and the field mappings that map the field names in your import file with the field names in Salesforce.
• Data Loader—this is a client application that can import up to five million records at a time, of any data type, either from files or a database connection. It can be operated either through the user interface or the command line. In the latter case, you need to specify data sources, field mappings and other parameters via configuration files. This makes it possible to automate the import process, using API calls.
• Note
  
  • With both methods, the number of records you can import depends on your permissions, the type of data you’re importing, and the overall data storage limits for your organization. The type of objects you can import depends on your edition.

​Use the Data Import Wizard when:

• You need to load less than 50,000 records.
• The objects you need to import are supported by the wizard.
• You don’t need the import process to be automated.

Use Data Loader when:

• You need to load 50,000 to five million records. If you need to load more than 5 million records, we recommend you work with a Salesforce partner or visit the AppExchange for a suitable partner product.
• You need to load into an object that is not supported by the Data Import Wizard.
• You want to schedule regular data loads, such as nightly imports.

Note

Data Loader uses the SOAP API to process records. For faster processing, you can configure it to use the Bulk API instead. The Bulk API is optimized to load a large number of records simultaneously. It is faster than the SOAP API due to parallel processing and fewer network round-trips.

Question 11

Describe the options for and considerations when importing and exporting data into development environments.

Answer 11

Introduction to Data Export

You can easily export data from Salesforce, either manually or on an automatic schedule. The data is exported as a set of comma-separated values (CSV) files. This provides a convenient way to export your data, either for backup or for importing into a different system.

Salesforce offers two main methods for exporting data.

• Data Export Wizard—this is an in-browser wizard, accessible through the Setup menu. It allows you to export data manually once every six days (for weekly export) or 28 days (for monthly export). You can also export data automatically, at weekly or monthly intervals.
• Data Loader—this is a client application that you must install separately. It can be operated either through the user interface or the command line. The latter option is useful if you want to automate the export process, or use APIs to integrate with another system.

Using the Data Export Wizard

• Follow these steps to export data using the wizard.
• From Setup, enter Data Export in the Quick Find box, then select Data Export and Export Now or Schedule Export.
• The Export Now option prepares your files for export immediately. This option is only available if enough time has passed since your last export.
• The Schedule Export option allows you to schedule the export process for weekly or monthly intervals.
• Select the desired encoding for your export file.
• If you want images, documents, attachments, and so on included in your data, select the appropriate options.
• Select Replace carriage returns with spaces to have spaces instead of carriage returns or line breaks in your export files. This is useful if you plan to use your export files for importing or other integrations.
• If you’re scheduling your export, select the frequency (only available for organizations with monthly exports), start and end dates, and time of day for your scheduled export.
• Under Exported Data, select the types of data to include in your export. We recommend that you select Include all data if you’re not familiar with the terminology used for some of the types of data.
• Click Start Export or Save.
• Salesforce creates a zip archive of CSV files and emails you when it’s ready. Exports will complete as soon as possible, however we can’t guarantee the date and time the export will complete. Large exports are broken up into multiple files. Follow the link in the email or click Data Export to download the zip file. Zip files are deleted 48 hours after the email is sent.