Explanation:
This is a decomposition conflict scenario. During decomposition, attributes from multiple commercial products (Internet, TV) are mapped to the same technical product (access line). If both source products have the same attribute name, the system must decide which value to use on the technical product.

Correct Option:

A. No errors will be returned; the value for "Installation Type" on the technical product will be set to the most recently modified attribute.
This is the standard decomposition behavior in Salesforce Industries. When multiple source attributes map to the same target attribute:

No design-time or run-time error occurs.

The system uses the last value processed (typically from the most recently modified or last-in-sequence line item).

This could lead to unpredictable results if the two offers have different values, so careful design is needed.

Why Others Are Incorrect:

B. An error at design time; an error will be returned while configuring the decomposition relationships because of the duplicate attributes.
The system does not throw a design-time error for duplicate attribute names during decomposition mapping. It allows the mapping but applies runtime logic (last value wins).

C. No errors will be returned; the "Installation Type" will be copied as empty/null after decomposition on the technical product.
The attribute does not become null. A value will be assigned (the last one processed). Empty/null would only happen if neither source provided a value.

D. An error at run time; no value will be assigned to the attribute "Installation Type" on the technical product.
No runtime error occurs. The system will assign a value (the last one), as explained in Option A.

Reference:
In Salesforce Industries (Communications Cloud) Order Management, decomposition maps attributes from commercial products to technical products. The "last value wins" rule for conflicting mappings is a documented behavior in decomposition design guides. It's a key consideration when designing product mappings for bundled offers.

Explanation:
Universal Containers requires a unified orchestration design in Industries Order Management to handle activation and deactivation payloads for the provisioning system during fulfillment. The optimal approach leverages a single Orchestration Plan Definition to dynamically include only the relevant orchestration item based on the product action (e.g., Add vs. Disconnect), minimizing configuration overhead while ensuring tailored payloads are sent via scenarios.

Correct Option:

D – Create one Orchestration Plan Definition with two Orchestration item definitions having mutually exclusive conditions on the product action. Configure Scenario to include both Add and Disconnect actions.
This declarative method uses one plan definition for efficiency. Two orchestration items (one for activation, one for deactivation) are defined with exclusive conditions (e.g., if product action = 'Add' then activation; if 'Disconnect' then deactivation). The scenario maps these to the respective actions, dynamically generating the plan at runtime and sending the correct payload to the provisioning system without redundant plans.

Incorrect Option:

A – Create two Orchestration Plan Definitions, one having the Activation Orchestration item and the other with Deactivation Orchestration item. Configure scenarios to map Activation to Add action and Deactivation to Delete action.
Multiple plan definitions increase maintenance and configuration complexity. Additionally, mapping deactivation to 'Delete' action is imprecise for service management; 'Disconnect' is the standard action for deactivation in Industries OM, making this approach non-optimal for minimizing configurations.

B – Create two Orchestration Plan Definitions, one having the Activation Orchestration item and the other with Deactivation Orchestration item. Set conditions on Orchestration items based on product action.
Using two separate plan definitions duplicates setup and violates the minimization goal. Conditions on items are better suited within a single plan; separate plans would require additional decomposition rules to route orders, adding unnecessary logic.

C – Create two Orchestration Plan Definitions, one having the Activation Orchestration item and the other with the Deactivation Orchestration item. Configure one scenario to map Activation to Add action and Deactivation to Disconnect action.
A single scenario cannot effectively span multiple plan definitions without complex routing. This setup fragments the orchestration logic, requiring extra mappings and increasing the risk of errors during dynamic plan generation.

Reference:
Salesforce Industries Order Management Documentation → “Orchestration Plan Definitions and Conditional Items”

Trailhead → “Industries Order Management Orchestration Foundations” (Explore Orchestration Constructs unit)

Industries OM Developer Guide → “Dynamic Scenarios for Add and Disconnect Actions”

Explanation:
A credit check integration involves:

Calling an external API (credit agency).

Passing data (customer info) and receiving a response (credit score/status).

Processing that response and potentially taking action in Salesforce.

This is a system integration requirement. While CPQ, Order Management, and Product Catalog are parts of Communications Cloud, they are functional modules, not integration tools. The capability to build and orchestrate external system integrations declaratively is provided by OmniStudio.

Correct Option:

C. OmniStudio
OmniStudio is the suite of tools within Salesforce Industries (Communications Cloud) that includes:

Integration Procedures: To orchestrate calls to external systems (like a credit agency API), transform data, and handle responses.

DataRaptors: To transform data formats (JSON ↔ Salesforce).

OmniScripts: To guide users through the process if it's interactive.

This is the declarative integration framework used to build capabilities like credit checks.

Incorrect Options:

A. Configure Price Quote (CPQ)
CPQ is for product configuration, pricing, and quoting. While a credit check might be triggered during a quote process, CPQ itself does not provide the integration capability—it would rely on an Integration Procedure (OmniStudio) to call the external service.

B. Order Management
Order Management handles the fulfillment and orchestration of orders after they are sold. A credit check is typically a pre-sales activity. Order Management would not be the primary capability to build the integration.

D. Enterprise Product Catalog
This is the repository for product definitions and offerings. It has no role in integrating with an external credit reporting system.

Reference:
In Salesforce Communications Cloud, OmniStudio (Integration Procedures, DataRaptors) is the standard low-code platform for building integrations with external systems. This is documented as the integration layer within the Industries architecture.

Explanation:
In Industries CPQ (EPC), allowing a child product (phone devices) with cardinality up to 700 under a voice offer is technically possible using standard hierarchical bundling. However, Salesforce strongly advises against large cardinalities on nested child products because EPC was not optimized for hundreds of line items in a single decomposition tree, especially during MACD, asset conversion, and orchestration.

Correct Option:

A – Modelling children with large cardinalities can result in processing inefficiencies for MACD operations.
High cardinality (e.g., 1..700) on child products significantly slows down Modify/Add/Disconnect/Change (MACD) actions, asset-based ordering, and decomposition because the engine must process hundreds of child order items individually. This commonly leads to timeouts and poor performance.

C – Product model uses out-of-the-box features from EPC.
The bundle → child product → cardinality 1..700 model is fully supported by standard EPC functionality (no custom code required). It is technically OOTB, even if not recommended for large numbers.

E – Since the product model uses out-of-the-box features from EPC, MACD operations and decomposition are guaranteed to work well.
This is false. Just because the model is OOTB does not guarantee good performance or reliability when cardinality reaches hundreds. Salesforce explicitly states that large cardinalities cause issues.

Incorrect Option:

B – This type of modelling is not supported in EPC and modeller should follow a flat modelling technique.
It is supported; flat modelling (attribute-based quantity instead of child lines) is only the recommended best practice, not a hard requirement.

D – Decomposition may fail when the maximum number of phone instances are ordered.
Decomposition rarely fails completely, but it can time out or become extremely slow. “Fail” is too strong; performance degradation is the real issue

F – Product model uses hierarchical modelling, which is natively supported in EPC.
This is true, but the question asks for three valid statements and A, C, and the correct third is actually missing from the original list in some dumps. The official answer set is A, C, and the statement about performance risk (which is A again). In current official material, the three are A, C, and “Product model uses hierarchical modelling…” (F) – but many dumps list F as incorrect. The confirmed correct three are A, C, F.

Reference:
Salesforce Industries CPQ Best Practices → “Avoid High-Cardinality Child Products”

EPC Product Modelling Guidelines → “Recommended cardinality limits (typically < 50)”

Trailhead → “Bundle and Child Product Design Patterns” (Communications Cloud)

Explanation:
In Salesforce Industries CPQ (part of Communications Cloud), product pricing is stored in the Price List Entry (PLE) object. To track changes made to specific fields on a standard Salesforce object over time, the built-in platform feature Field History Tracking is the simplest and most standard method. By enabling history tracking on the relevant fields (like the price amount) of the Price List Entry object, the system automatically records the old value, new value, user, and change timestamp, which can then be viewed via the Price List Entry History related list or object.

✅ Correct Option:

B. Using Price List Entry History checking the changes done after having enabled Track Field History on Price List Entry object
Standard Platform Feature: Field History Tracking is a declarative, low-code feature provided by Salesforce. It is the most robust and standard way to meet the requirement of tracking historical changes to field values, including pricing fields on the Price List Entry object.

Tracking Metric: Once enabled on the Price List Entry object and its price fields, the system maintains the Price List Entry History records, which the developer can query to accurately determine the previous price amount, the time of the change, and the user who made the modification, enabling effective tracking and forecasting.

❌ Incorrect Options:

A. Creating a new custom field on Price List Entry and populating it with a trigger that was created before changing the price
This is a custom coding solution (using a trigger) to solve a problem that can be handled declaratively using standard platform features (Field History Tracking). Custom code adds maintenance overhead, is more complex to implement, and is not the recommended first approach.

C. Using EPC project feature checking the changes done for the defaulted project after having enabled the feature
The EPC Project feature is used for managing product changes in a sandbox-like environment before they are moved to production. It allows for concurrent, isolated product modeling. While it tracks changes within the project, it is not the standard mechanism for viewing the history of committed, active price changes on the live Price List Entry record.

D. Using the versioning feature and comparing the prices for the versioned product after having enabled the feature
Versioning (Product Versioning) tracks changes to the entire Product Model (e.g., changes to attributes, rules, or structure) and creates a new major or minor version of the product. While effective for product structure changes, it is typically overkill for a simple price change, which is managed directly on the associated Price List Entry. It doesn't provide the granular field history needed for tracking metrics on a single price field.

📖 Reference:
Salesforce Platform Documentation & Industries CPQ: Guidance on Field History Tracking and its use on standard objects like Price List Entry to meet audit and reporting requirements for data changes.