Explanation:

This is a classic case of unintended recursion between a trigger and a flow. Let’s walk through the likely sequence:

An Account is updated and marked as a Customer.
The Apex trigger fires and creates an Account Plan.
The record-triggered flow also fires (because the Account was edited), and it updates the "Customer Since" field.
That update causes the Account to be edited again.
Since the flow is configured to run on create and every update, it fires again.

The trigger fires again too—resulting in a second Account Plan record. This loop continues unless one or both automation tools are designed to prevent re-entry.

Explanation:

When Lightning Web Components (LWCs) that are unrelated and in different DOM trees need to communicate, the recommended and standard approach is to use the Lightning Message Service (LMS).

LMS allows components to publish and subscribe to messages on a message channel, even if they are:

Not in the same component hierarchy.
In different DOM trees or application containers (like utility bars, pop-ups, etc.).
On the same Lightning page (or even in Experience Cloud sites, Visualforce, or Aura contexts).

In your scenario:

A search component finishes executing.
It needs to broadcast the search results.
Other components (e.g., a contact detail or contact list component) can subscribe to the message channel and react to the results.

This is exactly what Lightning Message Service is designed for.

Explanation:

Why Option A (Custom Labels) is Correct?

Built for Multilingual Support:

Custom Labels are Salesforce’s native solution for translating UI text (e.g., error messages, buttons, labels).
Supports multiple languages (German, Spanish, etc.) with zero code changes.

How It Works:

Create a Custom Label:
Setup → Custom Labels → Define a label (e.g., Issue_Submit_Button).

Add Translations:
Upload translations for each language (German: Problem einreichen, Spanish: Enviar problema).

Reference in Code/UI:
Apex: System.Label.Issue_Submit_Button
Lightning/LWC: {!$Label.c.Issue_Submit_Button}
Visualforce: {!$Label.Issue_Submit_Button}

Automatic Language Detection:

Salesforce serves the correct translation based on the user’s language/locale settings.

Explanation:

When working with translated picklist values (including custom multi-select picklists) in SOQL, if you want to retrieve the label in the current user's language (as defined by the Translation Workbench), you must use the TO_LABEL() function in your SOQL query.

This function:

Converts the stored API value of the picklist field to the translated label.
Ensures the output is localized based on the user's language settings.

Example:

List accs = [
SELECT Name, TO_LABEL(Product__c)
FROM Account
WHERE Id IN :accountIds
];

This query returns the translated picklist values for Product__c in the current user's language.

Explanation:

In Visualforce page controllers, the transient keyword is used to prevent certain variables from being saved in the view state. This helps with:

Reducing the size of the view state, which directly improves page performance and user experience.
Ensuring that non-critical or temporary data (like UI helper objects or temporary data containers) doesn't consume space in the view state.
The view state is a hidden form field in Visualforce pages that stores the state of the page between requests. If the view state grows too large (over 135 KB), it can lead to errors or slow performance.

Use Case:

public transient List tempList; // This won't be stored in the view state

Explanation:

In Aura components, the $Locale global value provider gives access to the current user's locale-specific formatting preferences, such as:

Date and time formats
Number formats
Currency symbols
Decimal and grouping separators

This makes $Locale the correct tool for ensuring your Lightning application respects the user’s cultural and regional preferences, especially important for multi-national applications.

Explanation:

B. Create a helper class that fetches the high value opportunities
This promotes code reuse and separation of concerns. By centralizing the logic in a helper class, both the Apex trigger and the Lightning Web Component (LWC) can call the same method to determine whether an Opportunity is high value. This avoids duplicating logic and ensures consistency across the application.
> This is a best practice in Apex design—keeping business logic out of triggers and encapsulating it in reusable classes.

D. Use custom metadata to hold the high value amount
Since the threshold for a "high value" Opportunity can change over time, storing it in custom metadata allows admins to update the value without modifying code or redeploying. Custom metadata is also accessible in Apex and can be deployed across environments, making it ideal for configuration data2.

Explanation:

Why Option A is Correct?

Best Practice (DRY Principle):
Helper class centralizes the address normalization logic, avoiding code duplication in triggers.
Changes to normalization rules only need to be made in one place.

Modular & Maintainable:
Triggers handle the DML events (before insert/update).
Helper class (e.g., AddressService.cls) performs the actual normalization:

public class AddressService {
public static void normalizeAddress(SObject record) {
// Standardize street, city, postal code, etc.
record.put('Street', formatStreet(record.get('Street')));
// ... (other fields)
}
}

Trigger Example (Account):

trigger AccountTrigger on Account (before insert, before update) {
for (Account acc : Trigger.new) {
AddressService.normalizeAddress(acc);
}
}

Trigger Example (Contact):

trigger ContactTrigger on Contact (before insert, before update) {
for (Contact con : Trigger.new) {
AddressService.normalizeAddress(con);
}
}

Explanation:

To verify that record-level sharing rules are enforced correctly in Apex tests—especially when different user types (like internal sales reps and external community users) interact with the same Visualforce page—you need to simulate those users in your test context. That’s exactly what System.runAs() is designed for.

What System.runAs() does:

Executes code as a specific user, allowing you to test profile-based and sharing-based access.
Ensures that sharing rules, role hierarchy, and org-wide defaults are respected during test execution.
Essential for testing portal/community users, who often have restricted access.

Example:

@isTest
private class OrderSharingTest {
static testMethod void testCommunityUserAccess() {
User communityUser = [SELECT Id FROM User WHERE Profile.Name = 'Customer Community User' LIMIT 1];
System.runAs(communityUser) {
// Attempt to access or update Order__c record
// Assert access is correctly enforced
}
}
}

Explanation:

When creating multiple related records (like an Account and a required Contact), and you want to ensure atomicity (i.e., either both records are created or neither), you need transaction control.

The correct way to do this in Apex is by:

Creating a Savepoint before inserting the Account.
Attempting to insert both records in a try-catch block.
Rolling back to the Savepoint if any part fails (e.g., if Contact insertion fails).

Example:

Savepoint sp = Database.setSavepoint();
try {
insert newAccount;
insert newContact; // This must succeed
} catch (Exception ex) {
Database.rollback(sp); // Roll back both inserts
// Handle exception (e.g., log error, display message)
}

This guarantees that if the Contact insert fails, the Account won’t be created either — fulfilling the business requirement.

Explanation:

When your unit tests fail because a new required field was added to an object like Account, and many test methods are creating Account records, the optimal and scalable solution is to:

Centralize your test data creation in a TestDataFactory utility class.
Update the Account creation logic once in that class to include the required field.
Use that class in all test methods moving forward.

This approach:

Avoids duplicating test setup code in every test method.
Makes test code easier to maintain and update.
Follows the Single Responsibility Principle and Salesforce testing best practices.

Explanation:

If an Apex class is not getting the expected code coverage, and the @testSetup method is calling the production method, that method’s logic does not contribute to code coverage.
This is because @testSetup methods are designed to set up test data only, and **code executed within them is not counted toward coverage metrics in Salesforce.

To generate proper coverage, you need to:

Move calls to the class/method outside the @testSetup method, into actual @isTest test methods.
If the method you want to test is private or not accessible in test classes, use the @TestVisible annotation to expose it for testing.

What @TestVisible does:
Makes private or protected methods/variables in Apex classes visible to test methods only.
Allows test classes to explicitly invoke and cover those methods.