Explanation:

When a new field is created in Salesforce, whether through Schema Builder, Object Manager, or another method, access to the field must be configured through Field-Level Security (FLS). The field's visibility and editability are controlled separately from the object and record-level permissions. The App Builder can grant Read and/or Edit access using Permission Sets or profile-level field permissions. This provides administrators with granular control over which users can view or modify the new field.

❌ Why Other Options Are Incorrect

A. All profiles
– This is incorrect because Salesforce does not automatically grant field access to every profile as a permanent security configuration. Field visibility must be explicitly configured through field-level permissions. Administrators can grant access to appropriate profiles or Permission Sets based on the organization's requirements.

B. Standard profiles
– This is incorrect because standard profiles do not universally receive unrestricted access to every newly created field. Field permissions must be configured according to the required access. A standard profile may receive access when the field's security settings are configured to grant it, but this is not an automatic rule for all new fields.

C. Internal profiles
– This is incorrect because "Internal profiles" is not a standard Salesforce profile category that automatically receives access to newly created fields. Field-level access is controlled through the permissions assigned to individual profiles and Permission Sets, regardless of whether users are internal or external.

📚 References:

Salesforce Help – Field-Level Security – Explains how field-level permissions control whether users can view or edit individual fields and how administrators can configure access through profiles and Permission Sets.

Explanation:

A  master-detail relationship on the Inspection__c object that relates it to  Building__c is the correct solution because it meets both requirements. First, when a Building record is deleted, the master-detail relationship automatically  cascades the deletion to all related Inspection records. Second, Inspection records in a master-detail relationship  inherit the sharing and access settings of the parent Building record. Because each Building can have multiple Inspections, Inspection__c should be the detail (child) object and Building__c should be the master (parent) object.

❌ Why Other Options Are Incorrect

A. Create a required lookup relationship field on Building__c that relates it to Inspection__c – This is incorrect because the relationship direction is reversed. Building__c should be the parent, while Inspection__c should be the child because one Building can have many Inspections. Additionally, a lookup relationship does not automatically cascade delete related child records when the parent is deleted, so this would not meet the deletion requirement.

B. Create a master-detail relationship field on Building__c that relates it to Inspection__c – This is incorrect because the relationship direction is wrong. Building__c should be the master (parent), and Inspection__c should be the detail (child). Placing the master-detail relationship field on Building__c would make Building the child of Inspection, which does not match the requirement that one Building can have multiple Inspection records.

C. Create a required lookup relationship field on Inspection__c that relates it to Building__c – This option has the correct relationship direction because Inspection__c is the child and Building__c is the parent. However, a lookup relationship does not automatically cascade delete the child records when the parent is deleted. Therefore, it does not satisfy the requirement that all Inspections be automatically deleted when their Building is deleted.

📚 References:

Salesforce Help – Master-Detail Relationships – Explains that master-detail relationships establish parent-child relationships, allow child records to inherit sharing and security settings from the master, and support cascading deletion of detail records when the master record is deleted.

Explanation:

 Record Types are the correct solution because they allow the App Builder to define different business processes, picklist values, and  page layouts for Leads based on their Source, such as Web, Trade Shows, or Partners. By creating a separate Record Type for each lead source, the App Builder can assign a unique page layout to each Record Type that displays only the fields relevant to that source, while still storing all Lead data in a single Lead object. This provides users with a clean and intuitive interface tailored to each lead type.

❌ Why Other Options Are Incorrect

B. Create three sections on the Lead layout and instruct users to collapse the non-relevant fields – This is incorrect because it relies on manual user action to collapse irrelevant sections. It does not actually prevent users from viewing or editing those fields. Users could expand the sections and see or accidentally populate information that is not relevant to the lead source. This approach also does not provide the same controlled user experience as separate Record Types and page layouts.

C. Create a Lead object on the Partner Community and a Record Type for Web and Trade Leads – This is incorrect because Lead is a standard Salesforce object that is not recreated separately for a Partner Community. You cannot create a separate Lead object specifically for the community. Additionally, this option does not provide three distinct configurations for Web, Trade Shows, and Partner leads.

D. Create custom objects for each type of Lead with each page layout containing only the relevant fields – This is incorrect because creating separate custom objects for each lead source would fragment the data and make reporting, searching, automation, lead conversion, and deduplication more complex. Salesforce provides Record Types and page layouts specifically to support different business processes and user experiences while keeping related records within the same standard object.

📚 References:

Salesforce Help – Record Types – Explains that Record Types allow organizations to provide different business processes, picklist values, and page layouts for different types of records and users.

Explanation:

The most likely reason the scheduled flow is hitting governor limits is that the flow uses a  Loop element with an  Update Records element placed inside the loop. This pattern causes Salesforce to perform  one DML operation per record, quickly consuming the DML governor limit of 150 operations per transaction. For a data cleanup job updating hundreds or thousands of Opportunities, this approach can exceed governor limits and cause the flow to fail. The correct best practice is to use a  single Update Records element outside the loop to update the entire collection of records in one DML operation, improving efficiency and helping the flow stay within limits.

❌ Why Other Options Are Incorrect

A. The App Builder did not specify an object and filter criteria in the Start element of the schedule-triggered flow – This is incorrect because schedule-triggered flows must specify an object and filter criteria in the Start element to define which records to process. If this configuration were missing, the flow would fail to start correctly or would not retrieve the intended records, but it would not cause governor limits during execution. This is a configuration issue, not a governor limit issue.

B. The App Builder did not create a Fault Path on the Update Records element – This is incorrect because a Fault Path is used to handle errors, such as validation rule failures or field validation issues, during flow execution. While a Fault Path is a useful error-handling practice, its absence does not cause governor limits. Without one, the flow may fail without proper error handling, but it would not contribute to exceeding DML limits.

D. Schedule-triggered flows do not support updates to standard objects like Opportunities – This is incorrect because schedule-triggered flows support updates to standard objects, including Opportunities. There is no general limitation preventing standard object updates in schedule-triggered flows. If the operation were unsupported, the flow would fail because of an invalid configuration or operation, not because of excessive DML operations during execution.

📚 References:

* Salesforce Help – Flow Builder Best Practices – Recommends avoiding database operations inside loops and collecting records for a single DML operation outside the loop to help prevent governor-limit issues.

Explanation:

When a Lead is converted in Salesforce, the system creates corresponding Account, Contact, and optionally Opportunity records based on the Lead data. By default,  validation rules on the Account, Contact, and Opportunity objects are bypassed during Lead conversion unless the  "Require Validation for Converted Leads" setting is enabled in Lead Settings. If this setting is disabled, the converted records can be saved without triggering those validation rules. This explains why converted Accounts may be missing information that would normally be required by Account validation rules.

❌ Why Other Options Are Incorrect

A. Account validation rules fail to validate on records converted from a Lead
– This is incorrect because Account validation rules do validate during Lead conversion when the "Require Validation for Converted Leads" setting is enabled. They do not inherently fail to validate. Rather, they are bypassed by default unless the setting is explicitly enabled.

B. The Lead settings are allowing users to intentionally bypass validation rules
– This is incorrect because Lead Settings do not provide an option for individual users to intentionally bypass validation rules. The setting is an organizational configuration that determines whether validation rules are enforced during Lead conversion. It is not a user-level permission to bypass validation rules.

D. Lead validation rules fail to validate on records when they are being converted
– This is incorrect because Lead validation rules are not the issue during Lead conversion. Validation rules on the Lead object apply when the Lead is created or edited, while the conversion process creates the resulting Account, Contact, and optional Opportunity records. The relevant issue is whether validation rules on the converted objects are enforced.

📚 References:

Salesforce Help – Lead Conversion Settings – Explains the "Require Validation for Converted Leads" setting and how it determines whether validation rules on converted Account, Contact, and Opportunity records are enforced during Lead conversion.