MB-700 common mistakes
MB-700 · Understand the traps and how to avoid them.
Treating the MB-700 architect case study as a single-project exercise and proposing one Dynamics 365 app (for example, Sales only) when the stated business processes span finance, supply chain, and field service, instead of mapping each requirement to the correct app and integration boundary.
Candidates transfer habits from functional exams where a single app is the scope, and they skim the case study narrative rather than building a requirement-to-app matrix. The architect role is explicitly about cross-app solution design, so a single-app answer scores poorly on solution strategy items.
What to do instead
Before answering, extract every distinct business capability from the case study and write a two-column list: capability and best-fit Dynamics 365 app or Power Platform component. For each capability that crosses apps, note the integration pattern (virtual entity, dual-write, Power Automate, or custom API). Practice with two or three synthetic multi-app scenarios and defend why each app was chosen.
Choosing a licensing and deployment model (for example, recommending a full Unified Interface deployment with premium connectors for every user) without first segmenting users by usage pattern and justifying the cost and governance implications.
Technical candidates focus on functional fit and skip commercial and operational constraints, which the architect exam tests because solution strategy must be defensible to stakeholders. Case study details about budget, user counts, or intermittent usage get ignored.
What to do instead
For every solution, produce a short licensing rationale: user personas, expected usage frequency, required premium features, and the resulting license tier. Explicitly connect each premium component to a business justification. When a scenario mentions cost pressure or occasional users, propose alternatives such as Power Apps per-app plans or embedded canvas apps.
Designing data migration as a single bulk import at go-live without addressing data quality, deduplication, field mapping, and cutover sequencing, and without identifying which legacy records should not be migrated at all.
Migration is treated as a technical checklist item rather than an architectural decision. Candidates underestimate how much of the implementation domain is about planning and risk, and they forget that the exam expects explicit treatment of data volume, ownership, and validation.
What to do instead
Build a migration plan with phases: profiling, cleansing, mapping, trial loads, reconciliation, and cutover. State the record counts and field mappings you would validate, name the tools (Data Import Wizard for small sets, Dataflows or SSIS/KingswaySoft for large sets), and define a rollback point. Identify legacy data you would archive rather than migrate and justify why.
Listing test cases only as happy-path user stories and omitting non-functional, integration, security-role, and regression testing, plus the environment strategy that supports them.
Candidates conflate testing with user acceptance testing and forget that the testing domain in an architect exam covers test strategy, environment topology, and release validation. Time pressure pushes them toward a short list of functional checks.
What to do instead
Structure the answer around a test pyramid: unit and component tests, integration tests for each external interface, role-based security tests using impersonation or test users, performance and volume tests, and regression suites tied to solution releases. Pair each layer with the environment it runs in (dev, test, UAT, production) and state who signs off.
Proposing a solution without stating the non-functional requirements it must satisfy, such as peak transaction volume, latency for integrations, availability targets, or data residency.
Case studies often bury these constraints in a paragraph about seasonal peaks or regulatory obligations. Candidates answer the functional question they see and skip the quantitative constraint, which is exactly what distinguishes an architect answer.
What to do instead
After reading the case study, write down every number and obligation you find (users, transactions per hour, countries, retention periods). For each, state the architectural implication, for example asynchronous integration via Azure Service Bus when volume exceeds synchronous API limits, or data residency driving region selection. Reference the numbers explicitly in your justification.
Treating the solution lifecycle as ending at go-live, with no plan for ALM, solution layering, environment promotion, or post-deployment support and adoption.
Candidates focus on build activities and neglect the manage-implementations domain, which tests whether you can run a delivery from design through hypercare. Solution segmentation and managed versus unmanaged solutions are frequently confused.
What to do instead
Outline the ALM approach: publisher and solution segmentation by module, unmanaged in development and managed in test and production, automated export and import via pipelines or Azure DevOps, and versioning conventions. Add a hypercare phase with defined exit criteria, a support model, and adoption metrics.
Ignoring the existing technology landscape and proposing a greenfield design that duplicates capabilities already provided by Microsoft 365, Azure, or an incumbent system named in the case study.
Candidates default to building custom components because that is what they know, rather than evaluating reuse first. The architect exam rewards recognizing when standard platform features or existing investments already satisfy a requirement.
What to do instead
For each requirement, run a build-versus-configure-versus-reuse check: can a standard Dynamics 365 feature do this, can an existing Azure or Microsoft 365 service do this, and only then should custom development be proposed. Document the decision and its cost or maintenance implication so the choice is auditable.
Describing security only as assigning security roles, without addressing business units, field-level security, hierarchy-based record visibility, teams, and the principle of least privilege across integrated systems.
Security is often reduced to a role list because that is the visible configuration step. The architect exam expects a model that explains how record ownership and organizational structure interact, and candidates frequently miss the interaction between business units and role privileges.
What to do instead
Draw the security model in layers: business unit structure, security roles and privileges, teams for cross-functional access, field security profiles for sensitive attributes, and record-level sharing rules. State how each layer maps to a named requirement, and describe how integrated systems authenticate and are authorized, for example via application users with scoped roles.
Presenting a recommendation without alternatives, trade-offs, or an explicit decision rationale, so the answer reads as an opinion rather than an architecture decision.
Candidates assume the exam wants the single correct product choice. In reality, architect questions reward defensible reasoning, and an answer that states why alternatives were rejected demonstrates the required judgment.
What to do instead
For each significant design decision, write a short architecture decision record: context, options considered, decision, rationale, and consequences. Even two sentences per decision is enough. This also protects against ambiguous questions, because a well-reasoned answer earns credit even when the preferred option differs.
Underestimating the effort and sequencing of a phased rollout, proposing a single big-bang go-live across all regions or business units without pilot scope, rollback, or dependency sequencing.
Candidates treat implementation planning as a scheduling exercise and overlook risk management, which the manage-implementations domain tests. Case studies that mention multiple geographies or legacy systems are signaling a phased approach.
What to do instead
Propose a phased plan with a pilot group, defined success criteria before expansion, dependency ordering (data, integrations, training, then cutover), and a rollback or contingency for each phase. State what would cause you to pause expansion and how you would measure readiness at each gate.