MB-500 common mistakes
MB-500 · Understand the traps and how to avoid them.
Directly modifying a Microsoft AOT object such as a table, form, or class to add a field or change logic in a scenario that requires a deployable solution.
It is the quickest path in a developer environment, and candidates often focus on making the requirement work rather than on whether the change is supportable in a cloud subscription.
What to do instead
Implement the change through table/form/class extensions, event handlers, or Chain of Command in a separate extension model, and keep Microsoft objects unmodified.
Creating new AOT elements in the default model or in a model that does not reference the model containing the objects being extended.
The model selected in the development environment is easy to overlook, and missing model references surface later as compile or deployment errors.
What to do instead
Before creating elements, confirm the target model, set it as the current model, and verify model dependencies include the models whose objects are used or extended.
Writing a Chain of Command extension method that does not call next or does not call super in an overridden method.
Candidates treat the extension like a replacement method and forget the CoC contract, so the base behavior or the next extension in the chain is skipped.
What to do instead
Call next in every CoC method, preserve and return its result where applicable, and call super in overrides that require base logic.
Putting business logic directly in a form button clicked event or form data source method instead of in a class, service, or controller.
It is convenient to wire behavior to the UI control being tested, and the candidate does not separate UI from application logic.
What to do instead
Move the logic into a class or SysOperation service/controller, call it from the form event, and test the class independently of the form.
Building an SSRS report whose RDP class queries live transaction tables directly in processReport and returns a data table without a contract or temp table.
Candidates focus on getting output quickly and overlook the reporting pattern expected for parameters, temp tables, and controller-driven execution.
What to do instead
Define an RDP contract for parameters, populate a temp table in processReport, and use a controller to pass the contract and temp table to the report.
Creating a data entity for DMF integration without defining entity keys or enabling staging, then testing only a single manual import.
The entity may work for simple export but fail for incremental import, duplicate detection, or error handling when keys and staging are missing.
What to do instead
Set the correct entity keys, map all required fields, enable staging where DMF requires it, and test import, export, and error scenarios with representative data.
Choosing OData or a custom JSON endpoint for a high-volume recurring integration instead of using the Data Management Framework or recurring integrations.
OData is familiar and easy to demonstrate, so candidates default to it without evaluating volume, batch, staging, and error-handling requirements.
What to do instead
Select DMF or recurring integrations for bulk and scheduled data movement, reserve OData for appropriate real-time scenarios, and justify the choice by volume and failure handling.
Assigning users to System Administrator or a broad out-of-the-box role instead of creating or using duties and privileges for least-privilege access.
Broad roles make the scenario work immediately and avoid the effort of tracing duties and privileges to the required menu items and tables.
What to do instead
Model access with roles that aggregate duties and privileges, assign only the required duties, and validate with a test user who lacks elevated access.
Processing records one at a time with a select or update inside a loop over a large record set.
Row-by-row code is straightforward to write and debug, and the performance impact is not visible with small test data.
What to do instead
Use set-based operations, joins, temporary tables, and RecordInsertList or bulk update patterns, and test with production-sized data.
Relying only on manual form testing and submitting code without SysTest or ATL unit tests for classes and data logic.
Manual testing demonstrates the happy path quickly, and candidates underestimate how exam scenarios expect testable, repeatable validation.
What to do instead
Create SysTest or ATL test classes for business logic, use mocks or test data setup, and run the tests as part of the build or validation process.