Explanation:

A Quick Action is the correct solution because it allows users to create Opportunity records directly from the Account page with predefined field values pre-populated. By creating a Create a Record quick action on the Account object and setting default field values, such as Account Name, Type, or any custom fields, the App Builder can provide a seamless, one-click experience for sales reps to create opportunities without navigating away from the Account record. Quick Actions are the modern, declarative standard in Lightning Experience for creating related records with pre-populated fields, and they can be placed on the page layout, the global header, or the Utility Bar for easy access.

❌ Why Other Options Are Incorrect:

A. Default action – This is incorrect because "Default action" in Salesforce typically refers to the default record view or list view that opens when a user clicks on a record or tab, such as the default tab or list view. It is not a mechanism for creating new records or pre-populating fields. There is no feature named "Default action" that allows users to create Opportunity records from an Account with pre-populated fields.

C. Custom button – This is incorrect because while custom buttons can be used to create records, they require JavaScript or URL hacking to pre-populate fields, which is outdated and not recommended in Lightning Experience. Custom buttons are legacy features from Classic and do not offer the declarative, point-and-click field pre-population capabilities that Quick Actions provide. Additionally, custom buttons often require Apex or complex URL parameters, making them less efficient and more error-prone than Quick Actions.

D. Custom link – This is incorrect because custom links are typically used to navigate to external URLs, web pages, or Salesforce records using a hyperlink. While they can be used to create records via URL parameters, they are also legacy in Lightning and do not provide the same user-friendly, declarative field pre-population, validation, and layout control that Quick Actions offer. Custom links are not the recommended approach for creating related records in Lightning Experience.

📚 References:

* Salesforce Help – Quick Actions – Explains that Quick Actions allow users to quickly create or update records with predefined field values, and can be added to page layouts, the global header, or the Utility Bar in Lightning Experience.

Explanation:

The correct approach is to grant the Service Coordinator (SC) access to work orders and related records owned by technicians in their specific region using Apex Sharing Rules or Sharing Rules if criteria-based sharing is feasible. Given a private data model, records are not visible to users other than the owner and those above them in the role hierarchy by default. To provide the SC with the necessary edit and delete access to attachments and other related records without granting overly broad permissions, a sharing rule should be created that shares work orders and their related records with the SC based on a criteria, such as the Region field matching the SC's region. This grants the SC the required access only to the relevant records, preserving data security while enabling the final review and cleanup process before invoicing.

❌ Why Other Options Are Incorrect:

B. Create a SC activity list with a corresponding audit group – This is incorrect because there is no standard Salesforce feature called "activity list" or "audit group" that grants record-level access. Activities, such as Tasks and Events, are separate objects and do not govern access to Work Orders or Attachments. This option does not provide a valid mechanism for sharing records or modifying attachments owned by technicians.

C. Give the SC a permission set with the Modify All Data system permission – This is incorrect because while granting Modify All Data would technically allow the SC to view, edit, and delete any record in the system, including work orders and attachments, this is overly permissive and violates the principle of least privilege. Modify All Data bypasses sharing rules, object-level security, and record-level security, granting unrestricted access to all data across the entire organization, far beyond what the SC needs. This is a security risk and is strongly discouraged for routine operational tasks.

D. Change work order access on the SC's profile to 'Modify All' – This is incorrect because Profiles do not have a "Modify All" setting for specific objects. They have object-level permissions such as Create, Read, Edit, Delete, and View All/Modify All. Modify All on an object bypasses record-level sharing and grants access to all records of that object, regardless of ownership or region. This would give the SC unrestricted access to all work orders across all regions, not just their specific region, and does not account for the requirement to access other related records owned by technicians. Additionally, modifying Profiles to grant such broad access is not a best practice; Permission Sets are preferred for granular access.

📚 References:

* Salesforce Help – Sharing Rules – Explains that sharing rules enable record-level access for specific users or groups based on criteria, such as region, in private or public/read-only org-wide defaults, granting access beyond the role hierarchy.

Explanation:

This is the correct solution because it accurately models the real-world business structure using Salesforce's standard data model. By creating both customers and dealers as Account records, UC can store separate billing addresses, separate bills, and other business-specific details for each entity. Adding each individual representative as a Contact on their respective Account ensures that the appropriate point of contact is linked to the correct business entity. Finally, establishing an Account Hierarchy by setting the customer Account as the parent of the dealer Account clearly displays the relationship between the customer and its dealers, enabling roll-up reporting, shared visibility, and a clear organizational structure within Salesforce.

❌ Why Other Options Are Incorrect:

A. Create both customer and dealer as accounts, create account teams on each account and associate the dealer records with the parent account – This is incorrect because Account Teams are designed for sharing access and collaboration among multiple users on a single account. They do not establish a parent-child relationship between accounts. Associating dealer records with the parent account via a custom lookup or other means would not create a formal Account Hierarchy, missing the requirement to clearly display the business entities and their appropriate representatives. The term "associate" is vague and does not provide the structured, hierarchical visibility that an Account Hierarchy offers.

B. Create a single account record, add each rep as a contact and create a custom dealer object – This is incorrect because creating a single Account record does not allow for separate billing addresses and separate bills for customers and dealers. It would conflate two distinct business entities into one record, causing data integrity issues. Additionally, creating a custom Dealer object is unnecessary and overcomplicates the data model when Salesforce already provides the Account object to represent all business entities, including customers and dealers, natively.

C. Create a single parent record, add each rep as a contact to the parent account and add each dealer as a child record – This is incorrect because it still uses a single parent record, likely an Account, to represent both the customer and dealer relationship, which does not allow for distinct billing and business information for each dealer. "Adding each dealer as a child record" is unclear. If child records are Contacts, that would incorrectly model dealers as individuals rather than business entities. If child records are custom objects, that again adds unnecessary complexity. The recommended approach is to treat both customers and dealers as Accounts and use the native Account Hierarchy.

📚 References:

* Salesforce Help – Account Hierarchies – Explains that Account Hierarchies allow you to define parent-child relationships between accounts, which is ideal for modeling customers with multiple locations, subsidiaries, or dealers. The hierarchy provides roll-up visibility and reporting.

Explanation:

The Utility Bar is the correct solution because it provides a persistent, collapsible toolbar at the bottom of a Salesforce console or Lightning app. It allows users to access frequently used components and tools, such as quick actions, Notes, History, and custom Lightning components, from anywhere within the app without leaving the current record or page. This helps sales representatives work efficiently while keeping essential tools readily accessible throughout their workflow.

A. Utility Bar – This is the correct answer. The Utility Bar provides persistent access to commonly used tools and components while users navigate through the Salesforce app. Because it remains available across the app, users can perform tasks, open tools, or access information without navigating away from the page they are currently viewing.

❌ Why Other Options Are Incorrect:

B. Home page – The Home page is a landing page that users must navigate to through the Home tab or navigation menu. Its components are not persistently available from every page in the app. Leaving a current Opportunity, Case, or other record to access Home page content would interrupt the user's workflow.

C. Favorites – Favorites allow users to bookmark records, list views, reports, dashboards, and other frequently accessed items. They provide quick navigation but do not create a persistent toolbar containing interactive components and tools. Users must still navigate to the favorited item rather than accessing it directly from a fixed panel.

D. Global actions – Global Actions provide quick access to actions such as creating records or logging calls from supported areas of Salesforce. However, they are action buttons rather than a persistent, multi-component toolbar. They do not provide the continuously available collection of tools and components offered by the Utility Bar.

📚 References:

Salesforce Help – Utility Bar – Explains how the Utility Bar provides persistent access to utilities and components from within Lightning apps and console applications.

Explanation:

To detect when a Task is deleted and notify the Case owner after the deletion, the appropriate solution is an  after-delete Apex trigger on the Task object. The trigger can use `Trigger.old` to access the deleted Task records and retrieve the related Case ID from the Task's `WhatId`. It can then query the Case owner and send the required notification. This provides direct control over post-deletion processing and cross-object logic.

After-delete Apex trigger on Task – This is the correct solution. An after-delete trigger executes when a Task record has been deleted and can access the deleted record through `Trigger.old`. The trigger can capture the related Case ID, retrieve the Case owner, and perform the required email notification. This directly satisfies the requirement to notify the Case owner after a Task is deleted.

❌ Why Other Options Are Incorrect:

A. Configure an assignment rule – Assignment rules are used to automatically assign records such as Cases and Leads to users or queues based on defined criteria. They are not designed to detect deletion of related Task records and cannot perform the required post-deletion notification to the Case owner.

B. Set up an escalation rule – Escalation rules are primarily used with Cases to escalate records when specified conditions, such as age or priority, are met. They do not trigger when a related Task is deleted and therefore cannot satisfy the requirement to notify the Case owner after Task deletion.

C. Build a record-triggered flow to run after the Task is deleted – A record-triggered flow can support delete-related automation, but this scenario requires post-deletion processing that uses the deleted Task's relationship information to identify the Case owner and send a notification. An after-delete Apex trigger provides direct access to `Trigger.old` and greater control over this cross-object processing, making it the appropriate solution for the stated requirement.

📚 References:

Salesforce Help – Apex Triggers – Explains trigger events such as after delete and the use of `Trigger.old` to access records that have been deleted.