Explanation:

To send an outbound message when a record meets specific criteria (without Apex), use these declarative tools:

Approval Process (A):

Criteria: Configure entry conditions in the approval process.

Outbound Message: Add an outbound message action to notify external systems when a record is approved/rejected.

Workflow Rule (C):

Criteria: Define rule conditions (e.g., "Status = Closed Won").
Outbound Message: Add an outbound message action as the workflow action.

Process Builder (D):

Criteria: Set up conditions in the process.

Outbound Message: Use the "Send Outbound Message" action in the process.

Why Other Options Are Incorrect:

B: Process Builder does not require Apex to send outbound messages (it’s declarative).

E: Visual Workflow (Flow) cannot send outbound messages natively (requires Apex or Process Builder integration).

Explanation:

Salesforce requires that triggers must have at least 1% code coverage to be deployed to a production environment. Even if a related class has high coverage, the trigger itself must be explicitly executed by a test method for deployment to succeed.

Why other options are incorrect:

B: Assertions are best practice but not required for deployment.

C: The overall code coverage of 75% is necessary, but every individual trigger must have at least 1% coverage.

D: Deployment includes both trigger and class, but lack of trigger coverage still causes failure.

To fix this, you must create a test method that actually causes the trigger to fire (e.g., inserting a Contact record).

Explanation:

Salesforce allows developers to override standard buttons like Edit with custom user interfaces, but the technology used depends on the UI experience:

✔️ For Salesforce Classic:

You can only override buttons using Visualforce pages.
Lightning components do not run in Classic.

✔️ For Lightning Experience:

You can override buttons with Lightning components (Aura or LWC).
This allows for modern, responsive UI.

🔧 Override Configuration:

When overriding the Edit button on the Contact object, Salesforce lets you specify:

A Visualforce Page for Classic
A Lightning Component for Lightning Experience

❌ Why other options are incorrect:

B. Lightning component in both Classic and Lightning
❌ Lightning components cannot run in Classic.

C. Visualforce page and Lightning page
❌ Lightning pages (App Builder pages) are not valid for button overrides.

D. Lightning page in Classic and Visualforce in Lightning
❌ Lightning pages don’t work in Classic, and Visualforce in Lightning defeats the purpose of a native Lightning experience.

Explanation:

In the code shown:

public static void insertAccounts(List theseAccounts){
for(Account thisAccount : theseAccounts){
if(thisAccount.website == null){
thisAccount.website = 'https://www.demo.com';
}
}
update theseAccounts;
}

The method always calls update theseAccounts.
If even one record in theseAccounts causes an error (for example, a validation rule, required field missing, or duplicate rule), the entire DML operation fails and throws a DmlException.
To handle such errors gracefully, a developer should wrap the DML statement in a try/catch block. This allows you to catch the exception, log it, and maybe handle records individually if needed.

Corrected Example with try/catch:
public static void insertAccounts(List theseAccounts){
for(Account thisAccount : theseAccounts){
if(thisAccount.website == null){
thisAccount.website = 'https://www.demo.com';
}
}
try {
update theseAccounts;
} catch (DmlException e) {
// Handle gracefully: log error or take corrective action
System.debug('Update failed: ' + e.getMessage());
}
}

Why not the other options?

A. Upsert → Wouldn’t solve the exception problem. Upsert only helps when you want to insert or update based on an external ID. Errors like validation failures would still throw exceptions.

B. Change Data Capture → This is for event-driven integration, not error handling.

D. Remove null items → That prevents null pointer issues but doesn’t stop DML exceptions (e.g., validation rules or required fields).

Reference:
Salesforce Apex Developer Guide – Exception Handling