Explanation:

1️⃣ Roll-Up Summaries (A)

Used in Master-Detail relationships to aggregate child record data at the parent level.
Allows SUM, COUNT, MIN, and MAX calculations without requiring code.

2️⃣ Relationships (C)

Defines how data is structured in the database via Lookup or Master-Detail relationships.
Controls record ownership, cascading deletion, and roll-up capabilities.

3️⃣ Custom Objects & Fields (E)

Forms the foundation of the database layer in Salesforce.
Allows storage and tracking of unique business data.

Why Not B or D?

B. Triggers → Triggers require Apex code, making them non-declarative.
D. Flow → While Flow is declarative, it focuses on automation rather than database structure.

Explanation:

Lightning Web Components (LWC) use custom events for communication between components, especially from child to parent. Here’s what’s true:

C. By default a custom event only propagates to its immediate container.
Custom events in LWC do not bubble beyond the immediate parent unless the event is explicitly configured with bubbles: true.

D. Data may be passed in the payload of a custom event using a property called detail. To pass data in a custom event, you use the detail property:

this.dispatchEvent(new CustomEvent('myevent', { detail: { value: 'something' } }));

Why the other options are incorrect:

A. Data may be passed in the payload using wire-decorated properties
@wire is for data retrieval, not for event communication. Custom events don't use @wire for passing data.

B. Custom event propagates to both immediate container and child
Custom events propagate upward (to containers), not downward to child components.

Explanation:

A. An invocable method: A Flow can directly call an Invocable method in Apex. This Invocable method can then contain the logic to make a real-time callout to the external order management system (via a REST endpoint, for example). Once the data is retrieved from the external system, the Invocable method can return that data to the Flow, which can then display it on a screen element to the agent. This is the standard and most efficient way to achieve real-time external data retrieval and display within a multi-screen Flow.

Let's look at why the other options are not suitable:

B. An Apex REST class: An Apex REST class is used to expose Salesforce functionality as a web service that external systems can call into Salesforce. It's for inbound integrations to Salesforce, not for Salesforce to call out from a Flow to an external system.
C. An outbound message: An outbound message is a declarative way to send information from Salesforce to an external system. It's typically asynchronous and unidirectional (Salesforce sends data out), and it cannot retrieve data from an external system in real time for display in a Flow.
D. An Apex Controller: While an "Apex Controller" (a generic term for an Apex class that controls logic) would be involved in making the actual callout, the specific type of Apex method that a Flow can directly invoke and get data back from is an Invocable Method. Simply calling it an "Apex Controller" is too broad and doesn't specify the direct integration point for Flows.

Explanation:
To enforce field-level security (FLS) automatically when building forms in a Lightning Web Component (LWC), the developer should use:

inside a

Why this is important:

lightning-input-field automatically respects FLS:

If a user doesn't have read access, the field is hidden
If a user has read-only access, the field is disabled
If a user has read/write access, the field is editable

This ensures that only the appropriate fields are shown or editable based on user permissions, without writing custom logic.

❌ Why the other options are incorrect:

A. force-input-field
❌ Not a valid LWC component — likely a confusion with older Aura naming

B. ui-input-field
❌ Part of the Aura UI namespace, deprecated and not available in LWC

C. aura-input-field
❌ Also Aura framework-specific, not usable in Lightning Web Components

Explanation:

The question is asking how to insert or update records based on a custom external ID field called Order_Number__c on the Order__c object.

🔹 Why Option C is Correct:

The upsert DML statement is used to insert new records or update existing ones.
When using a custom external ID, you can specify it as the matching field for the upsert operation.
This avoids using the Salesforce record ID (Id) and instead leverages a unique external identifier.

❌ Why Not the Other Options?

A. merge orders Order_Number__c;
❌ merge is used for merging duplicate records (only works on sObjects like Account, Contact, or Lead) and does not accept custom external ID fields.

B. merge orders;
❌ Same issue as A, and still not appropriate for Order__c (a custom object).

D. upsert orders;
⚠️ Valid, but it would only work if the list of orders includes the Salesforce Id field.
Since we are told to match using a custom external ID, this statement does not fulfill the requirement explicitly.