A validation rule on the Opportunity object is the most direct and declarative method. It can reference the parent Account’s Industry field using a cross-object formula (e.g., ISBLANK(Account.Industry)) and prevent the save if the condition is met, ensuring data quality at creation.

Manually combining two separate, unrelated reports (one on Opportunities, one on Accounts) provides no meaningful correlation between the data sets. You cannot reliably see which Opportunities belong to which Accounts for the rep in this way. The other options use established Salesforce reporting relationships (report types, joined reports) to correctly link the data.

This follows the standard layered security model. The Profile grants the object-level permissions (Read/Edit). Setting Organization-Wide Defaults (OWD) to ‘Private’ restricts base visibility to owned records. A criteria-based sharing rule can then be used to programmatically open access, but the scenario only requires access to owned records, so the ‘Private’ OWD alone achieves the goal. The other options either grant excessive privilege (Modify All Data), use the wrong OWD level, or are overly complex.

A core characteristic of a Master-Detail relationship is that the detail (child) record does not have its own independent security. Its visibility and editability are controlled by the permissions on the master (parent) record. This is not true for Lookup relationships, where each record has its own security. Option A is false (roll-up summaries are optional). Option C is false (both can be required). Option D is false (deleting a master causes cascading deletion of details).

A custom object with a Master-Detail relationship to Account is ideal. It allows for an unlimited number of related project records per Account, provides a separate object with its own fields, page layouts, and reporting capabilities. The Master-Detail relationship ensures projects are deleted with the Account and inherit sharing. Using record types (option 0) on a Lookup is also valid, but Master-Detail is often preferred for strict ownership. Option 2 is not scalable, and option 3 misuses the Opportunity object.

A validation rule is the correct declarative tool to enforce this ‘either/or’ logic. The rule would check ISBLANK(ContactId) && ISBLANK(AssetId) and prevent save if true. Making both required (option 0) would force users to always fill both, which violates the requirement. Option 3 relies on training, which is not enforceable. Option 2 adds complexity without solving the core validation need.

This is a fundamental concept. Every user must have one Profile, which defines their baseline permissions (object CRUD, field-level security, tabs, etc.). Permission Sets are additive; they are used to grant extra permissions to specific users without changing their underlying Profile. This allows for a more modular and maintainable permission model. The other options misrepresent the core functions of each component.

Reports respect field-level security (FLS) but not necessarily object-level security in a cross-object context if the user has access to the primary object. A user can run a report on Contacts (which they can see) and filter based on a related field from Account (like Industry), even if they cannot directly view the Account tab or records. The report engine handles the underlying data relationship. Options 1, 2, and 3 are inefficient workarounds that don’t leverage platform capabilities.

Organization-Wide Defaults (OWD) define the baseline level of access to a record. Setting an object to ‘Private’ means the record is accessible only to the owner, and users above them in the role hierarchy (if hierarchy is enabled). No other user can see, edit, or report on that record unless access is explicitly opened via sharing rules, teams, manual sharing, or a more permissive role in the hierarchy. It is the most restrictive starting point.

A validation rule on the Opportunity object is the most direct and declarative method. It can reference the parent Account’s Industry field using a cross-object formula (e.g., ISBLANK(Account.Industry)) and prevent the save if the condition is met, ensuring data quality at creation.0