Explanation:

A  Lightning Component tab is the standard and best approach to make a custom, standalone Lightning component accessible directly from the navigation bar of a Lightning app. By creating a tab for the component and adding it to the navigation menu of the "Sales Operations" Lightning App, users can access the component with a single click from the navigation bar. This provides a seamless, native Salesforce experience and is the recommended method for exposing standalone Lightning components to users.

❌ Why Other Options Are Incorrect

A. Add the Lightning component to the Utility Bar of the Lightning App – This is incorrect because the Utility Bar is a persistent toolbar at the bottom of the screen designed for frequently used tools such as quick actions, notes, and recent items. It is not the appropriate place for a standalone, full-page component that should be accessed from the navigation bar. The Utility Bar is better suited for compact, always-available utilities rather than primary navigation.

B. Embed the Lightning component into a dashboard and add the dashboard to the navigation menu – This is incorrect because dashboards are designed primarily to display reports and charts, not to provide standalone access to Lightning components. Although a Lightning component can be added to a dashboard in supported contexts, this is a workaround and restricts the component to the dashboard context. A Lightning Component tab is the direct solution for navigation-bar access.

C. Create a Web Tab and point the URL to the Lightning component's generated endpoint – This is incorrect because Web Tabs are intended to display external web content within Salesforce, not to expose internal Lightning components. Using a generated endpoint would add unnecessary complexity and is not the standard Salesforce approach. A Lightning Component tab provides direct and native access to the standalone component from the app navigation menu.

📚 References

Salesforce Help – Lightning Component Tabs – Explains that Lightning Component tabs allow custom Lightning components to be added to an app's navigation menu, making them directly accessible to users.

Explanation:

The  Flow Trigger Explorer is specifically designed to manage the execution order of multiple record-triggered flows on the same object. By assigning a  lower trigger order value to the discount-calculation flow and a  higher trigger order value to the notification flow, the App Builder can ensure that the discount flow runs first, followed by the notification flow that references the calculated discount. This allows the flows to remain separate for ownership and maintenance while controlling their execution order.

❌ Why Other Options Are Incorrect

A. Configure the notification flow to run asynchronously after the save so it executes after other record-triggered flows on Opportunity – This is incorrect because asynchronous execution does not guarantee that the discount flow runs first. It runs the notification logic in a separate transaction after the original save transaction, but it is not the mechanism used to explicitly control the order of multiple record-triggered flows.  Flow Trigger Explorer provides the appropriate trigger-order configuration.

B. Add a scheduled path with a zero-minute interval at the start of the notification flow to delay its execution – This is incorrect because a scheduled path is not the appropriate mechanism for controlling the order of two record-triggered flows. A scheduled path introduces time-based execution rather than establishing a guaranteed trigger order. The requirement is to control which flow runs first, which is handled directly through  Flow Trigger Explorer.

C. Move both flows' logic into a single before-save record-triggered flow on Opportunity to control execution order natively – This is incorrect because the requirement explicitly states that the two flows must remain  separate for ownership reasons. Combining them into one flow would violate that requirement. In addition, before-save flows are intended primarily for updating fields on the triggering record and are not the appropriate place for sending email notifications.

📚 References

* Salesforce Help – Flow Trigger Explorer – Explains how Flow Trigger Explorer allows administrators to view and set the execution order, or trigger order, for multiple record-triggered flows on the same object.

Explanation:

A  master-detail relationship is the correct solution because it supports cascading deletion. When the parent record, `Supplier__c`, is deleted, all related child records, `Supplier_Item__c`, are automatically deleted as well. By making `Supplier__c` the master (parent) and `Supplier_Item__c` the detail (child), Salesforce handles the cascading delete natively without requiring additional code or automation. This directly meets the requirement to simultaneously delete the Supplier record and all associated Supplier Item records.

❌ Why Other Options Are Incorrect

B. Indirect Lookup – This is incorrect because "Indirect Lookup" is not a standard relationship type for custom objects in Salesforce. Although indirect lookup relationships can be associated with external objects, they do not provide the required cascading-delete behavior for `Supplier__c` and `Supplier_Item__c` custom objects.

C. Hierarchical – This is incorrect because hierarchical relationships are specific to the  User object and are used to represent manager-subordinate relationships. They cannot be created between custom objects such as `Supplier__c` and `Supplier_Item__c`, and they do not provide cascading deletes.

D. Many-to-Many – This is incorrect because a many-to-many relationship is typically implemented with a  junction object containing two master-detail relationships. It is intended for situations where records on both sides can have multiple related records. The requirement describes a simple parent-child relationship with cascading deletion, so a master-detail relationship is more appropriate.

📚 References

* Salesforce Help – Master-Detail Relationships – Explains that master-detail relationships establish a parent-child relationship and support cascading deletion of detail records when the master record is deleted.

Explanation:

A  validation rule is the correct solution because it enforces data integrity at the point of entry by validating the format of the shipping ZIP code before the record can be saved. The App Builder can create a validation rule that uses the `LEN()` function or `REGEX()` to check that the ZIP code contains exactly 5 digits. For example, `LEN(ShippingPostalCode) = 5` can verify the length, while `REGEX()` can validate that all characters are numeric. If the ZIP code does not match the required format, the validation rule fires, prevents the save, and displays a custom error message. This ensures  only properly formatted 5-digit ZIP codes are saved.

❌ Why Other Options Are Incorrect

A. Create a screen flow to enter address information and populate the ZIP code in the desired format – This is incorrect because while a screen flow could guide users and format the ZIP code, it requires  manual user interaction and does not prevent users from bypassing the flow and entering data directly through list views, API integrations, or other methods. A screen flow is a useful UI enhancement but does not enforce the format at the database level.

C. Create a custom ZIP code field with help text displaying the desired data input formatting as XXXXX – This is incorrect because help text is  informational only and does not enforce or validate data entry. Users can ignore the help text and enter incorrectly formatted ZIP codes, so this does not solve the data consistency problem.

D. Create an approval process for manager sign-off on all shipping codes entered by users – This is incorrect because an approval process would add unnecessary overhead for every ZIP code entry and is not designed for data validation. Approval processes are used for routing records for human review, not for enforcing field formatting. This would create delays and would not be an efficient solution for maintaining data consistency.

📚 References

Salesforce Help – Validation Rules – Explains that validation rules enforce data quality by verifying that records meet specified criteria before they are saved and can use functions such as `LEN()` and `REGEX()` to validate field formats.

Explanation:

A  Roll-Up Summary field on the Account object with  SUM as the aggregation type is the correct solution because it sums the Amount field from all related Opportunity records. To ensure that only  Closed Won sales are included, the roll-up summary field must have filter criteria on the Stage field set to `StageName = "Closed Won"`. This ensures the total sales displayed on the Account record reflect only Opportunities that are Closed Won, excluding other stages such as Open, Closed Lost, or Negotiation. This provides an accurate view of total sales per Account.

❌ Why Other Options Are Incorrect

A. Create a roll-up summary field for the Opportunity object with COUNT rollup type summarizing Accounts – This is incorrect because a roll-up summary field cannot be created on the  Opportunity object to summarize Accounts. The roll-up summary must be on the  parent object (Account) to aggregate child records (Opportunities). Additionally, COUNT would only count the number of records, not sum sales amounts.

C. Create a roll-up summary field for the Account object with SUM rollup type summarizing Opportunities aggregated by Amount including all records in the calculation – This is incorrect because while the SUM aggregation is correct, including   all records without filtering by Stage would sum amounts from Opportunities that are not Closed Won, including Open, Closed Lost, or other stages. The requirement is to calculate total sales from Closed Won Opportunities, so a Stage filter is required.

D. Create a roll-up summary field for the Account object with COUNT rollup type summarizing Opportunities – This is incorrect because COUNT would only count the number of Opportunities, not sum their Amount values. The requirement is to see  total sales, which requires a monetary sum rather than a record count. Additionally, this option does not include a filter on Stage to restrict the calculation to Closed Won Opportunities.

📚 References

* Salesforce Help – Roll-Up Summary Fields – Explains that roll-up summary fields on parent objects, such as Account, can use SUM to aggregate number or currency fields from related child records, such as Opportunities.