AP-203 Salesforce Accredited Agentforce Communications Professional Exam Topics and Questions

Discovery sets the baseline for everything that follows. You are mapping the customer's current state, translating their business pain into measurable outcomes, and determining which Agentforce Communications capabilities fit their vision. The cost comes when you misread the IT ecosystem or miss a constraint that invalidates your design halfway through delivery.

– Architecture and ecosystem assessment

You assess the current IT architecture using guiding principles that tell you whether the existing landscape can support what comes next. This means identifying integration points, understanding how data flows between systems, and spotting technical debt that will block your implementation. The architectural assessment is not a documentation exercise. It is a risk filter. You are looking for the constraints that will force design compromises later, and you need to surface them before the planning phase locks in a direction. Pay attention to platform limits, especially where data volumes are concerned. A customer's expected growth can push you past what Agentforce Communications handles natively, and that changes your catalog design, your orchestration approach, and your migration strategy.

– Business outcomes, KPIs, and product fit

You translate business pain points and objectives into KPIs that define what a transformational outcome looks like. This is not about listing features. It is about identifying the metrics that prove the implementation solved the problem. Budget shapes everything here. It determines how much of the vision you can deliver in the first release and which products you can realistically include. You then map the customer's vision and goals to the right Agentforce Communications products. The trap is recommending products because they exist, not because they solve the stated problem. Every product you bring in adds complexity, licensing cost, and maintenance overhead. The question is always whether the product earns its place in the solution, not whether it could be used.

– Process, persona, and requirement mapping

You map and document the customer's business processes, the personas involved, and the requirements that drive their workflows. This is where you find out how orders are really captured, who approves what, and where manual steps hide. You then map those processes to native Agentforce Communications functionality and identify what needs an off-platform solution. The distinction between native and custom is the pivot point for your delivery plan. If a requirement can be met out of the box, you defer to configuration. If it cannot, you are committing to custom development, and that changes your timeline, your risk profile, and your test strategy. Do not guess at this mapping. The cost of treating a custom requirement as native shows up late, usually during user acceptance testing.

How Discovery is tested

At 24 percent, Discovery carries significant weight, and the questions reflect that by testing your ability to make judgment calls under ambiguity. You are given a scenario describing a customer's environment, pain points, or goals, and you must choose the correct assessment approach, the right KPI, or the appropriate product mix. The demand is on connecting business context to technical decisions. You need to know which guiding principles apply when evaluating architecture, how to distinguish transformational KPIs from vanity metrics, and when a requirement maps to native functionality versus needing a custom build. Candidates lose marks by recommending products that do not align with the stated objectives, by missing platform constraints that invalidate their design, or by confusing process documentation with actual requirement mapping. The exam penalises solutions that are technically possible but commercially or operationally unviable. Read the scenario for budget, volume, and timeline. Those three variables control which answer is correct.

Planning and Design is where Discovery findings turn into a buildable architecture. At 60 percent, this is the exam's centre of gravity. You are rationalising product catalogs, designing orchestration and order capture flows, planning asset management, and structuring data migration. Every design decision you make here either enables delivery or creates a bottleneck that surfaces under load.

– Product catalog design and decomposition

You use architectural guidelines to rationalise, model, and design a scalable product catalog. Scalability means the catalog can grow without requiring a rebuild when the customer adds new offers or enters new markets. The design must account for how commercial products decompose during delivery and implementation. Decomposition scenarios determine how a single customer-facing offer breaks down into technical components, fulfillment tasks, and downstream system actions. Get this wrong and your orchestration flows inherit the complexity. The catalog is not a data model you can iterate on later. It is the foundation for quoting, ordering, fulfillment, and asset management. Changes to catalog structure after go-live are expensive and risky, so the design must be right before you build.

– Order capture, quoting, and orchestration

You design quoting and order capture flows that align to architectural guidelines, ensuring the customer's sales and service teams can configure offers, apply pricing, and submit orders without hitting workflow limits or performance issues. Then you design orchestration flows that translate an accepted order into a sequence of fulfillment actions. Orchestration is where order management meets the real world: provisioning systems, inventory checks, third-party APIs, and manual fallback steps. The design must handle both the happy path and the failure scenarios. Candidates often design for success and forget to model what happens when a downstream system is unavailable or returns an error. Your orchestration flow is only as reliable as its exception handling.

– Asset management and MACD flows

You design asset management flows that track what the customer has installed, where it is, and what state it is in. MACD flows handle moves, adds, changes, and disconnects, which are the day-to-day transactions that keep the asset base accurate. This is not a reporting feature. Asset management drives billing, entitlement, and service fulfillment. If the asset record is wrong, the customer gets billed for something they do not have, or they cannot order an upgrade because the system does not know what they own. MACD flows must be designed to handle partial changes, bulk updates, and corrections without creating orphan records or breaking parent-child relationships in the asset hierarchy.

– Data migration and sprint planning

You create a scalable and extensible migration strategy that ensures data quality and a seamless transition from the legacy system. This means defining extraction, transformation, validation, and load steps, and planning for data that does not fit the new model. Migration is not a one-time script. It is a workstream with its own risk, dependencies, and test cycles. You also take a set of user stories and identify priority, dependency, and size, then align them to sprints. The goal is to sequence work so that each sprint delivers testable value and does not block the next one. Dependencies are the constraint. If story B cannot start until story A is done, they cannot be in the same sprint unless A finishes early. Size determines whether a story fits at all.

How Planning and Design is tested

Planning and Design accounts for 60 percent of the exam, and the questions are correspondingly detailed. You are given a scenario describing processes, requirements, or data constraints, and you must choose the design approach that aligns with best practices and architectural guidelines. The demand is on applying those guidelines under realistic conditions, not reciting them. You need to know how to model a product catalog for scale, when to decompose a commercial product, how to sequence orchestration steps, and how to structure a migration without losing data quality. Candidates lose marks by designing solutions that work in a demo but fail under volume, by ignoring dependencies when planning sprints, or by treating asset management as a passive data store rather than an active fulfillment input. The exam tests whether your design survives contact with the customer's real environment. Constraints matter more than features.

Delivery is where your design meets the build phase. You determine what can be delivered out of the box and what requires customisation, how to implement the architecture and catalog components you designed, and how to execute the data migration strategy. At 16 percent, this topic carries less weight than Planning and Design, but it tests whether you can translate a final design into a realistic delivery plan. The cost comes when you underestimate the customisation effort or misjudge the migration risk. Delivery decisions shape your timeline, your resource allocation, and your testing strategy. You are not designing anymore. You are deciding how to build, in what order, and with what trade-offs. The line between out-of-the-box and custom is not always clear, and drawing it incorrectly creates rework. If you treat a native feature as custom, you waste development time. If you assume something is native when it is not, you discover the gap too late to adjust scope. The migration strategy you planned earlier now becomes a set of executable steps, and you must account for the legacy system landscape, data quality issues, and the to-be architecture. This is not a one-time load. It is a phased transition with validation gates, rollback plans, and cutover windows.

How Delivery is tested

Delivery questions test your ability to take a final design and make implementation decisions. You are given a project design and asked to determine what can be delivered out of the box versus what needs custom work, or how to implement architecture, catalog, and order management components. The demand is on recognising the boundary between configuration and code, and on structuring delivery so that dependencies are respected and risk is managed. Candidates lose marks by overestimating what is available natively, by proposing migration approaches that ignore data quality or system constraints, or by failing to sequence implementation steps in a way that allows for testing and validation. The exam expects you to know how Agentforce Communications components are delivered in practice, not just in theory. Read the scenario for clues about the legacy landscape and the customer's tolerance for downtime. Those details determine which delivery approach is viable.