Explanation:

The requirement is to create a quick way to generate new child accounts from a parent account record, with several fields pre-populated from the parent. This is a classic use case for a Custom Action.

Option C (Custom action on Account) is correct: A custom action can be created on the Account object and added to the Account page layout. When used from a parent account record, this action can pre-populate fields on the new child account record using values from the parent (e.g., Parent Account, Billing Address, Phone Number, etc.). This provides a streamlined, one-click way for users to create hierarchical accounts without manually re-entering data.

Option A (Custom Global Quick Action) is incorrect: A Global Quick Action appears in the global publisher layout and is not specific to a single record. It would not have the context of the parent account from which the user is trying to create the child, so it could not pre-populate fields from that parent.

Option B (Custom Global Quick Account) is incorrect: This is not a valid Salesforce feature or terminology.

Option D (Custom link on Account) is incorrect: A custom link is typically used to redirect users to an external URL or launch a JavaScript function. It cannot create a new record or pre-populate fields based on the current record's data.

How it works:
The app builder would create a "Create Child Account" custom action of type "Create". In the pre-defined values for this action, they would map fields from the parent account (the context record) to fields on the new child account record.

Reference:
Salesforce Help: "Create Actions" - Explains how to create custom actions to streamline creating records.
Salesforce Help: "Predefine Field Values for Custom Actions" - Details how to auto-populate fields in a new record from values in the current record.

Explanation:

Why these work
A. Workflow rule + Outbound Message:
A classic, point-and-click way to notify an external service when an Opportunity becomes Won. Outbound Messages send a SOAP message to a configured endpoint and Salesforce automatically retries on failure.

C. Process + Apex code:
A Process (Process Builder) can invoke Invocable Apex, and Apex can make HTTP(S) callouts to external web services—great if you need REST/JSON, custom headers, or more control.

Why not the others
B. Flow + Outbound Message:
Technically possible today—Outbound Message is now a core action in Flow Builder—but the question asks for two, and the exam’s expected pair here is A & C. If you see this on a newer exam variant, note that Flow + OM also satisfies the requirement.
D. Process + Outbound Message:
Not supported—Outbound Messages can be associated with flows, workflow rules, approval processes, or entitlement processes, but not Process Builder.

References
Salesforce Help: Outbound Message Actions (what they are, where they’re supported).
Salesforce Help: Considerations for Outbound Messages (delivery/retries).
Salesforce Help: Call Apex Code from a Process (Apex action in Process Builder).
Salesforce Docs: Apex Callouts (invoke external web/HTTP services).
Salesforce Release Notes: Outbound Message as a Flow action (FYI for modern orgs).

Explanation:

When replacing workflow rules and Apex triggers with Process Builder (or more broadly, Salesforce Flows, as Process Builder is being phased out in favor of Flows), an app builder must consider several factors to ensure a smooth transition and maintain system performance. Let’s evaluate each option:

Option A: Correct.
Avoid generating infinite loops. In Process Builder, actions that update records (e.g., updating a field on the same object or a related object) can inadvertently trigger the same process or other processes, causing infinite loops. This can lead to performance issues or hitting governor limits (e.g., CPU time or DML limits). App builders must design processes with checks (e.g., using a custom field to track whether the process has run) to prevent recursive updates. This is a critical consideration when replacing workflow rules and triggers, as both can also cause loops if not carefully managed.

Option B: Incorrect.
Apex has a different SOQL query limit than Flow. While Apex and Flow (including Process Builder) have governor limits, the SOQL query limit is the same for both in a single transaction (e.g., 100 SOQL queries in synchronous Apex or Flow). The key difference lies in how Apex and Flow handle execution (e.g., Apex allows more granular control, while Flow is declarative). However, this difference in SOQL limits is not a primary consideration when transitioning from workflow rules and triggers to Process Builder, as the focus is on functionality and performance, not a specific SOQL limit distinction.

Option C: Incorrect.
Create a process for each workflow rule. While it might seem logical to create a one-to-one replacement for each workflow rule with a Process Builder process, this is not a best practice. Combining multiple related workflow rules into a single Process Builder process (or Flow) is often more efficient, as it reduces the number of processes running, simplifies maintenance, and helps avoid hitting governor limits. Creating a process for each workflow rule is not a critical consideration and can lead to overcomplication.

Option D: Correct.
Combine actions when possible. To optimize performance and maintainability, app builders should consolidate related actions into a single Process Builder process (or Flow) whenever feasible. For example, multiple workflow rules that update different fields on the same object can be combined into one process with multiple actions. This reduces the number of processes executed, minimizes the risk of hitting governor limits, and simplifies the automation logic, making it easier to manage compared to fragmented workflow rules or triggers.

Key Considerations:
Infinite Loops (Option A): Process Builder processes can trigger other processes or themselves if they update records that meet the same criteria. To avoid this, app builders can use techniques like a checkbox field (e.g., Bypass_Automation__c) to prevent re-execution or carefully design entry criteria to avoid recursion.
Combining Actions (Option D): Consolidating actions into fewer processes improves performance and reduces complexity. For example, if multiple workflow rules update fields on an Opportunity when it reaches a certain stage, a single Process Builder process can handle all field updates in one go.
Transition Context: Salesforce is retiring Workflow Rules and Process Builder in favor of Flows (as of late 2025, per Salesforce’s roadmap). While the question specifies Process Builder, the same principles apply to Record-Triggered Flows, which are the recommended replacement. The considerations of avoiding loops and combining actions are equally relevant for Flows.
Governor Limits: Both Process Builder and Apex operate within Salesforce’s governor limits (e.g., 100 SOQL queries, 150 DML operations per transaction). Combining actions and avoiding loops helps stay within these limits.

References:
Salesforce Documentation: Process Builder Best Practices – Discusses avoiding recursive loops and optimizing processes.
Salesforce Help: Flow and Process Builder Limits – Covers governor limits and best practices for combining actions.
Trailhead: Business Process Automation – Explains transitioning from Workflow Rules and triggers to Process Builder or Flows, including combining actions.
Salesforce Blog: Flow Best Practices – Highlights avoiding loops and consolidating automation.

Explanation:

The requirement is to perform an action on a parent record when a child record is deleted. This is a specific trigger event that is not fully supported by most declarative automation tools.

Option C (Apex code) is correct: An Apex trigger can be written with the after delete event. This trigger would have access to the child records that were just deleted. From there, the code could gather the IDs of the affected parent records and perform a update operation on them. This is the only reliable way to handle actions based on a delete operation for a lookup relationship.

Option A (Screen flow) is incorrect: A screen flow is user-triggered and requires a UI. It cannot be automatically triggered in the background when a record is deleted.

Option B (Process Builder) is incorrect: Process Builder can only be triggered on create and edit events. It has no ability to trigger on a delete event. Therefore, it cannot detect when a child record is deleted.

Option D (Workflow rule) is incorrect: Like Process Builder, workflow rules can only be triggered on create or edit events. They cannot be triggered by a record deletion.

Key Consideration:
While declarative tools like Flow are powerful, a record-triggered flow can only be invoked on delete events for the object it is on—and its actions are limited to the deleted records themselves. It cannot perform DML operations (like updating a parent record) after the child record is deleted due to order of execution constraints. Therefore, Apex is the necessary tool for this specific requirement.

Reference:
Salesforce Help: "Trigger Order of Execution" - Explains that after a record is deleted, no further DML operations are allowed on that record, but operations on other records (like the parent) are possible in an after delete Apex trigger.
Apex Triggers: Are the programmatic method to handle delete events and perform subsequent actions on related records.

Explanation:

To control when the Convert button appears or is usable on a Lead record, the App Builder needs to combine UI customization with business logic enforcement:

✅ Custom Button:
You can replace the standard Convert button with a custom button or quick action that only appears under specific conditions.
This allows you to control visibility using record types or page layouts.

✅ Validation Rule:
Even if the button is visible, you can block conversion unless Lead Status = 'Qualified' using a validation rule.
This ensures that users cannot bypass the requirement by manually triggering conversion.

✅ Record Types:
Use record types to assign different page layouts and control which users see the Convert button.
For example, only show the Convert button on layouts tied to the “Qualified” record type.

❌ Why the other options fall short:
A. Picklist dependency, page layouts, record types
Picklist dependencies don’t control button visibility or enforce conversion logic.
C. Process builder field update, quick action, record type
Process Builder can update fields but can’t control button visibility or enforce conversion rules.
D. Page layout, record types, process builder field update
Again, no enforcement mechanism — Process Builder doesn’t block conversion.

🔗 Reference:
You can explore this topic in the Trailblazer Community discussion on controlling Lead conversion, where admins share strategies for gating the Convert button based on Lead Status.