MB-500 · Question #8
Case Study 1 - Wide World Importers Background Wide World Importers sell office supplies, furniture, and fittings to their customers across the United States. The company has the following…
The correct answer is deployable package; existing model; package; deployable package. Dynamics 365 Finance - Vendor Exclusion List: Develop, Test, Deploy The four actions and their correct objects follow the standard D365 Finance development-to-deployment lifecycle. Here's the breakdown: --- Concept Map (Before Diving In) | D365 Artifact | What It Is | |---|---|…
Question
Exhibit
Answer Area
Drag items
Correct arrangement
- deployable package
- existing model
- package
- deployable package
Explanation
Dynamics 365 Finance - Vendor Exclusion List: Develop, Test, Deploy
The four actions and their correct objects follow the standard D365 Finance development-to-deployment lifecycle. Here's the breakdown:
Concept Map (Before Diving In)
| D365 Artifact | What It Is |
|---|---|
| Model | Logical container for X++ code/metadata; compiled into a DLL assembly |
| Package | One or more models compiled together (e.g., ApplicationSuite) |
| Deployable Package | Binary bundle applied to cloud environments via LCS |
| Project | Visual Studio grouping - dev-time only, never deployed |
Action-by-Action Breakdown
Action 1 → deployable package
This covers installing the third-party credit card processing solution. The case study is explicit: "The third-party company will provide a deployable package." You apply it to your environment via LCS - no compilation needed. You don't get source; you get a ready-to-deploy binary.
Common mistake: Choosing
model file. A.axmodelis a binary model distribution format, not the mechanism for applying solutions to cloud environments. Deployable packages are what LCS accepts.
Action 2 → existing model
This covers developing the Vendor Exclusion List (the VendExclusions table, PrimaryIdx index, security objects, etc.).
You add this to an existing model rather than creating a new one because:
- The
VendExclusionstable referencesCustAccount,ItemId, andVendAccount- fields that live in existing tables (CustTable,InventTable,VendTable) - Referential integrity (explicitly required) depends on those references being resolvable at compile time within the same package/model scope
- Working in an existing model (e.g., ApplicationSuite or a custom extension model already in your package) gives direct access to existing EDTs and table references
Common mistake: Choosing
new model. The requirement says "isolate as a new assembly," which sounds likenew model. However, a completely isolated new model with no dependency chain to ApplicationSuite cannot referenceCustTableetc. without explicit model dependencies configured - and the exam answer assumes the simpler, integration-safe path of using an existing model.
Action 3 → package
After developing in the model, you build/compile in Visual Studio. The output is a package - the compiled binary set of one or more models. This is your intermediate artifact before deployment.
At this stage you can run unit tests in the dev environment (satisfying the requirement: "All new code must be unit tested in a development environment").
Common mistake: Jumping straight to
deployable package. A package is the compiled build output. A deployable package is a separately created distribution artifact wrapping that output for LCS upload.
Action 4 → deployable package
To deploy to UAT (and later Production), you create a deployable package from your compiled package and upload it to LCS. From LCS, it is applied to the UAT environment for QA validation before going to Production.
This satisfies: "You must deploy code to a UAT environment for testing before deploying code to production."
Common mistake: Choosing
package. Raw packages cannot be applied to cloud environments directly - LCS only accepts deployable packages. This is the most common confusion on D365 Finance exams.
Summary Table
| # | Action | Correct Object | Why |
|---|---|---|---|
| 1 | Install third-party credit card processor | deployable package | ISV provides it ready-to-deploy; apply via LCS |
| 2 | Develop Vendor Exclusion List | existing model | Referential integrity requires access to existing tables |
| 3 | Build/compile for testing | package | Compiled output of the model, used for unit testing |
| 4 | Deploy to UAT → Production | deployable package | Required format for LCS cloud environment deployment |
Key Misconceptions to Avoid
new modelvsexisting model: "New assembly" in the requirements refers to the isolation of logic, but the model still needs to live within a package that can resolve existing table references.packagevsdeployable package: These are not interchangeable. Package = compiled output. Deployable package = LCS-ready distribution artifact.project: Only relevant in Visual Studio during development. Never appears in deployment workflows.model file(.axmodel): Used for distributing model binaries between developers, not for deploying to cloud environments.
Topics
Community Discussion
No community discussion yet for this question.
