Free Salesforce-Accredited-Agentforce-Communications-Professional Practice Test Questions (2026)

A.   To identify the risk of hitting governor limit with the production load

D.   To understand how long, the data load in production should take

Explanation:

Before migrating data into production, Universal Containers (UC) should perform a full data load in a Full Copy Sandbox. A Full Copy Sandbox provides a production-like environment with a complete copy of production data, making it useful for validating migration performance and identifying potential issues at scale.

A. To Identify the Risk of Hitting Governor Limits with the Production Load:
A full-volume migration test helps identify potential Salesforce governor-limit issues, such as excessive SOQL queries, CPU time, heap usage, or DML operations, especially when the migration process uses Apex or automation.

D. To Understand How Long the Data Load in Production Should Take:
Loading the full dataset in a Full Copy Sandbox helps estimate migration duration, identify performance bottlenecks, and plan the production cutover window.

Why the Other Options Are Incorrect:

B. To Identify Data Errors Not Surfaced During Subset Testing:
A full-volume test can reveal additional data-quality issues, but the key objectives emphasized here are performance, limits, and load-duration estimation.

C. To Identify Metadata-Related Errors:
Metadata is primarily validated through deployment and configuration testing. A full data load is not specifically intended to uncover metadata errors.

Reference:
Salesforce Help: Sandbox Types and Templates — explains sandbox types and how Full Copy Sandboxes support testing in a production-like environment.

Exam Tip:
Before production migration, test the full data volume to estimate load duration and identify scalability or governor-limit risks.

A.   Integrate communication cloud with inventory management system using enterprise product catalog REST APIs. The inventory will expose the EPC API to create the product and product related records in the product catalog.

Explanation:

The requirement is to synchronize SKU data from an external Inventory Management System with Salesforce Communications Cloud Enterprise Product Catalog (EPC) while minimizing customizations and customer issues.

The best practice is to use the Enterprise Product Catalog (EPC) REST APIs, which are specifically designed to create, read, update, and manage products and related catalog entities. Salesforce states that EPC REST APIs provide an abstraction layer that enables external applications to integrate directly with EPC and manage Product, Product Version, Product Child Items, Picklists, and Promotions.

Therefore, integrating the Inventory Management System with EPC through the standard APIs is the recommended solution.

Why A Is Correct ✅

A. Integrate Communications Cloud with the inventory management system using Enterprise Product Catalog REST APIs.
The inventory system uses EPC APIs to create products and related records in the product catalog.

This Approach:
Uses Salesforce-supported APIs.
Minimizes custom code and technical debt.
Supports product lifecycle management through EPC.
Simplifies future upgrades and maintenance.
Provides a standard integration pattern recommended by Salesforce.

Why the Other Options Are Incorrect

B. Create a Custom Trigger and Import CSV Files ❌
This relies heavily on custom Apex and manual or import-based processes. It increases maintenance effort and is less scalable than using the standard EPC APIs.

C. Use a Custom Object and Trigger to Create EPC Records ❌
Creating custom staging objects and triggers introduces unnecessary customization when a standard API framework already exists. This violates the best-practice principle of using out-of-the-box capabilities first.

D. Use CPQ API getCartProducts and EPC APIs ❌
The getCartProducts API is a CPQ Cart API used for product retrieval within cart and quoting processes, not for catalog synchronization or product creation. EPC REST APIs are the appropriate APIs for catalog management.

References

Enterprise Product Catalog (EPC) REST APIs: Explain that EPC APIs enable applications to manage products, picklists, and promotions, and support create, read, update, and delete operations.
Product APIs: Document product creation and management through EPC REST APIs.

Exam Tip

For AP-203 and Communications Cloud exams:

Product Catalog Integration: Think EPC REST APIs.
Cart/Quote Operations: Think CPQ Cart APIs.
Best Practice: Avoid answers involving custom triggers, CSV imports, or custom objects when a standard EPC API capability exists.

Final Answer: A ✅

D.   Create ' Mobile Offer Spec Type ' Object type with the common attributes and set the parent object type as ' Base Offer Spec Type ' . Then, associate mobile device offers with ' Mobile Offer Spec Type ' object type.

Explanation:

Option D (Correct):
In Salesforce Industries (SFI) Enterprise Product Catalog (EPC), Object Types function like classes in object-oriented programming to share common attributes, fields, and layouts across products via inheritance.

A root object type (e.g., 'Base Offer Spec Type') holds foundational attributes common across all offers.
A child object type (e.g., 'Mobile Offer Spec Type') inherits from the parent and adds domain-specific common attributes (such as color, storage, and screen size).
Associating mobile device product offers directly with the 'Mobile Offer Spec Type' ensures they automatically inherit all common mobile device attributes without needing to re-add them manually to each individual offer.

Option A (Incorrect):
This misinterprets the inheritance structure and does not properly follow EPC best practices for extending base object types into domain-specific child object types.

Option B (Incorrect):
Putting all attributes into a single root 'Base Offer Spec Type' leads to bloated, unmaintainable object models, violating the principle of modular catalog design.

Option C (Incorrect):
Associating mobile device offers directly with 'Base Offer Spec Type' instead of 'Mobile Offer Spec Type' would mean the offers miss out on inheriting the specialized mobile attributes (color, storage, screen size) defined on the child object type.

B.   Use Digital Commerce APIs

Explanation:

Airtalk needs a fast way to expose and sell Mobitel’s products (managed in Communications Cloud / Industries CPQ + Order Management) on its own consumer portal without migrating the product catalog.

Digital Commerce APIs (also called Digital Commerce / Cacheable APIs) are the recommended solution for this scenario because they are purpose-built for:

External / consumer-facing digital channels and portals.
High-volume browsing and product selection.
Anonymous (guest) shopping experiences.
Retrieving offers, configurations, and pricing directly from the Enterprise Product Catalog (EPC) without requiring Opportunity, Quote, or full Cart records in many cases.
Built-in caching for performance and scalability.

This allows Airtalk’s portal to call Mobitel’s Communications Cloud APIs to browse, configure, and order products while the catalog and order management remain in Mobitel’s org.

Why the Other Options Are Not Ideal

A. Use Cart Based APIs:
These are designed for full CPQ cart operations (create/update cart, pricing, etc.). They work well for assisted or authenticated flows but are heavier and less optimized for pure external consumer portals compared with Digital Commerce APIs.

C. Use CPQAppHandler Methods:
These are internal Apex/handler methods primarily used within OmniScripts or platform processes, not the preferred external integration approach for a third-party portal.

D. Use EPC APIs:
These are mainly for catalog administration and management (CRUD on products, promotions, etc.), not for shopping, configuration, or order capture experiences on a consumer portal.

Salesforce Guidance
Digital Commerce APIs are the standard recommendation when an external application or portal needs to interact with a Communications Cloud catalog for digital commerce use cases without a full catalog migration. This pattern is frequently tested in AP-203 scenarios involving multi-company or acquisition integrations.

B.   Use OmniScript to build the guided ordering journey for agents and call OmniScript via Experience Builder on a Salesforce Experience Cloud.

D.   Use OmniScript to build the guided ordering journey for agents and expose OmniScript via OmniOut on a third- party CMS.

Explanation:

The requirement is to provide a guided ordering process for both:

Internal Sales Agents
External B2C Customers

In Salesforce Communications Cloud, OmniScript is the preferred tool for building guided selling and ordering journeys because it provides a declarative, step-by-step user experience.

B. Use OmniScript to Build the Guided Ordering Journey for Agents and Call OmniScript via Experience Builder on a Salesforce Experience Cloud. ✅

This is a standard Communications Cloud implementation pattern:

Sales Agents can launch OmniScripts directly within Salesforce.
Customers can access the same OmniScript through an Experience Cloud site using Experience Builder.
This is a supported and commonly implemented architecture for B2C self-service journeys.

D. Use OmniScript to Build the Guided Ordering Journey for Agents and Expose OmniScript via OmniOut on a Third-Party CMS. ✅

OmniOut allows OmniScripts to be rendered outside Salesforce and embedded into external websites or third-party CMS platforms while maintaining Communications Cloud business logic.

This is specifically designed for use cases where customers interact through non-Salesforce digital channels.

Why the Other Options Are Incorrect

A. Use OmniScript for Agents and OmniScript via OmniOut on a Salesforce Experience for Customers. ❌
OmniOut is intended for external non-Salesforce applications and third-party websites. When using Salesforce Experience Cloud, OmniScripts can be hosted directly through Experience Builder. Using OmniOut inside a Salesforce Experience is unnecessary and not the recommended pattern.

C. Use Salesforce Flow for Agents and Salesforce Flow via Lightning Out on a Third-Party CMS for Customers. ❌
While Flow is powerful, Communications Cloud guided ordering processes are typically built with OmniScript because of its deep integration with EPC, CPQ, and Industries processes. Salesforce Flow does not provide the same Communications Cloud guided selling capabilities expected for complex telecom ordering scenarios.

Why the Answers Are Right

Option B:
Supported Experience Cloud deployment of OmniScript for customer self-service.

Option D:
OmniOut is specifically designed to expose OmniScripts on third-party websites and CMS platforms.

Option A:
Incorrect use of OmniOut within Salesforce Experience Cloud.

Option C:
Flow is not the preferred Communications Cloud guided ordering framework.

References

OmniScript is the recommended declarative framework for guided customer and agent journeys in Communications Cloud.
OmniOut enables OmniScripts to run outside Salesforce on external websites and CMS platforms.
Experience Cloud supports embedding and running OmniScripts directly for customer self-service experiences.

Exam Tip

For AP-203, remember:

Internal Guided Process: OmniScript
Experience Cloud Customer Portal: OmniScript via Experience Builder
External Website/CMS: OmniScript via OmniOut

Answer: B and D ✅✅

A.   Decompose Modem & STB into one CFS using M:1 decomposition pattern configure scope field on CFS technical product definition to Account

Explanation:

In Salesforce Communications Cloud, product decomposition maps commercial products to technical products for fulfillment. Acme Technology wants to ship a modem and a set-top box (STB) in a single call to the shipping fulfillment system, while avoiding unnecessary inventory storage in the customer base.

The many-to-one (M:1) decomposition pattern allows multiple commercial products, such as the modem and STB, to map to a single Customer-Facing Service (CFS) technical product for fulfillment.

Setting the scope field on the CFS technical product definition to Account helps consolidate the relevant fulfillment items at the account level. This supports a single shipping request rather than separate requests for each device and helps avoid unnecessary duplication of customer-base inventory records.

Why the Other Options Are Incorrect:

B. Incorrect ❌
Uses separate CFS technical products and Order Item scope, which does not directly support the desired consolidation into one Fulfillment Request.

C. Incorrect ❌
Uses separate CFS technical products, so it does not achieve the intended single combined shipping operation.

D. Incorrect ❌
Uses M:1 decomposition but places the Account scope on the commercial modem and STB products rather than on the CFS technical product definition, as specified in option A.

Reference:
Salesforce Help — Consult the Communications Cloud Enterprise Product Catalog documentation for product decomposition patterns, technical product scope, and order decomposition.

Exam Tip:
When multiple commercial products must be fulfilled together, look for an M:1 decomposition relationship and the appropriate scope configuration to consolidate fulfillment.

B.   Modeling children with large cardinalities can result in processing inefficiencies for MACD operations.

C.   Product Model use hierarchical modeling which is natively supports EPC

D.   Product model uses OOTB features from EPC. Decomposition may fail when the maximum number of products is processed.

Explanation:

Option B (Correct):
In Salesforce Industries (SFI) Enterprise Product Catalog (EPC) and CPQ, defining bundles or product specifications with extremely large cardinalities (such as allowing up to 700 child products) introduces massive performance overhead. During MACD (Move, Add, Change, Disconnect) operations, the cart must evaluate, price, and validate eligibility and compatibility rules for these large lists, leading to significant processing inefficiencies and latency.

Option C (Correct):
EPC natively supports hierarchical product modeling, allowing products to be structured as parent bundles with child components, options, or add-ons configured via cardinalities and relationships.

Option D (Correct):
While EPC supports cardinality features out of the box, pushing limits to hundreds of items (like 700) can cause engine timeouts or memory/governor limit exhaustion during the decomposition phase when generating downstream technical orders, occasionally resulting in failures.

Option A (Incorrect):
High cardinalities like 700 are not guaranteed to work seamlessly or perform well without careful tuning and design adjustments.

Option E (Incorrect):
Hierarchical modeling with child cardinalities is fully supported by EPC; flat modeling is not a strict requirement, though keeping hierarchies balanced is a best practice.

C.   Create one orchestration plan definition with two orchestration definition having mutually exclusive condition. Configure the scenario to include both Add and disconnect actions.

Explanation:

This is essentially the same scenario as the previous question, and the principle remains the same: consolidate into a single orchestration plan and use item-level conditions to differentiate the payload for activation versus deactivation.

Why This Is the Recommended Approach:

One Orchestration Plan Definition:
A single plan groups all the orchestration items required for this offer's fulfillment. This reduces the number of plans to maintain and keeps the logic for a single offer in one place.

Two Orchestration Items with Mutually Exclusive Conditions:
Within the plan, define two separate callout items:

Activation Item: Condition set so it only executes when the product action is Add.
Deactivation Item: Condition set so it only executes when the product action is Disconnect.

Because the conditions are mutually exclusive, only one item will ever run for a given order action, ensuring the correct payload is sent to the provisioning system.

Scenario Includes Both Actions:
The orchestration scenario must be configured to trigger the plan for both Add and Disconnect actions. This way, regardless of whether the customer is activating or deactivating the service, the same plan is selected, and the appropriate conditional item executes.

This design minimizes configuration by avoiding duplicate plans and leveraging the built-in conditional logic of orchestration items.

❌ Why the Other Options Are Incorrect

A, B, and D (All Variants Proposing Two Orchestration Plans):
Creating two separate orchestration plans for activation and deactivation is unnecessarily redundant. It doubles the configuration effort because you must:

Maintain two plan definitions.
Create and manage separate scenario associations (or complex scenario logic) to route orders to the correct plan based on action.

This approach increases maintenance overhead and the risk of inconsistency between plans. The requirement can be fully satisfied with a single plan containing conditional items, making the two-plan approach contrary to the goal of minimizing unnecessary configurations.

D (Configuring Orchestration Items Based on the Product):
This option misplaces the condition. The differentiation is based on the product action (Add vs. Disconnect), not on the product itself. The product is the same in both cases; only the action being performed on it differs. Setting conditions on the product would not correctly distinguish between activation and deactivation.

📊 Key Principle
Number of Plans:
Use one orchestration plan definition for a single offer's fulfillment.
Differentiating Logic:
Use orchestration item conditions on the Action field (Add vs. Disconnect).
Scenario Configuration:
Include both Add and Disconnect actions in the scenario.
Payload Selection:
Achieved automatically by which conditional item executes.

A.   Use Salesforce Flow for building the guided ordering journey for agents and salesforce flow via community builder on a salesforce community for customers to leverage the development team ' s flow expertise

C.   Use Omni Script for building the guided ordering journey for agents and call Omni script via community builder on a salesforce community to maximize reuse

D.   Use OmniScript for building the guided the ordering journey for agents and expose OmniScript via OmniOut on a third-party CMS for Customers to Maximize reuse.

Explanation:

Why A Is Feasible:
Salesforce Flow can run as the guided journey for agents in the console. Flow screens can also be placed on an Experience Cloud (community) page through Experience Builder, so one Flow skill set covers both audiences.

Why C Is Feasible:
OmniScript is the standard guided-journey tool in Communications Cloud. It runs for agents in the console, and the same OmniScript can be added to an Experience Cloud site through Experience Builder. This is the best reuse story, with one script serving both channels.

Why D Is Feasible:
OmniOut exposes OmniScripts outside Salesforce, for example on a third-party CMS or external website. Agents use the OmniScript in Salesforce, and consumers use the same OmniScript via OmniOut.

Why B Is Wrong:
OmniOut is designed for non-Salesforce platforms. Using it inside a Salesforce community is the wrong tool, since Experience Builder already supports OmniScripts natively. The "maximize governor limits and performance" rationale is also not a real benefit.

Why E Is the Weakest:
Flow can technically be embedded through Lightning Out, but it is a less standard and more limited pattern than OmniOut. It also does not integrate as naturally with Communications Cloud's product and cart configuration, which is built around OmniScripts and Industries tooling. That makes it the most likely distractor of the five.

References:
Salesforce Help documentation on OmniScript in Experience Builder, OmniOut (OmniScript for external sites), and embedding Flow in Experience Cloud.

A.   Create a product class and assign it to all top level offers, create orchestration plan with a scenario on a product

B.   Use product class to decompose each top offer to a CFS specific for the notification email orchestration plan with a scenario on the CFS

Explanation:

UC is launching products iteratively (Mobile first, then TV, etc.), but the same notification email activity is required no matter which top-level offer is sold. The goal is maximum reusability, fastest time-to-market, and minimal ongoing maintenance.

Best Practices in Industries Order Management:

A – Product Class + Scenario on the Class
Assign all top-level offers (Mobile, TV, future offers) to the same Product Class. Create one Orchestration Plan Definition and attach a single Orchestration Scenario that targets the Product Class instead of individual products.

→ New offers simply inherit the class, so the notification plan runs automatically. No additional scenarios are needed.

B – Product Class + Common CFS
Use the Product Class to drive decomposition of every top-level offer into the same technical CFS (e.g., "Notification Email CFS"). Then create one Orchestration Plan with a scenario on that CFS.

→ The email orchestration is completely decoupled from commercial offers. Adding new offers only requires the class assignment and decomposition relationship to the shared CFS.

Why the Other Options Are Less Optimal

C – Separate Decomposition Relationships:
Creating a separate decomposition relationship for every commercial offer to the CFS requires more design-time work and ongoing maintenance as new offers are introduced.

D – Separate Scenario for Each Top-Level Offer:
Defining a separate scenario for each top-level offer is the least reusable approach and increases configuration and maintenance effort with every new product launch.

Key Takeaway:
Both Product Class (for commercial offers) and a shared CFS (for technical fulfillment) are standard Salesforce patterns for making common orchestration activities, like a notification email, reusable across many products with the least configuration overhead. These two approaches best satisfy the requirements of iterative go-lives and minimal long-term maintenance.