MB-700 key terms

A high-level design document that maps business capabilities to Dynamics 365 apps, integrations, and data flows so stakeholders agree on scope before build begins.

A structured comparison of required business processes against standard product capability, classifying each requirement as a fit, a configuration gap, or a custom development gap.

The agreed boundary of what the implementation will deliver, including in-scope entities, processes, geographies, and explicit exclusions used to control change requests.

An inventory of the organization's end-to-end processes, each with owners, inputs, outputs, and supporting applications, used to prioritize implementation work.

Documenting how work actually flows today and how it should flow in the target system, typically with swimlanes showing roles, decisions, and handoffs.

A table linking each requirement to its design element, build item, and test case so coverage and impact of changes can be verified throughout the project.

A formal record of a proposed modification to agreed scope, schedule, or budget, including impact assessment and approval decision, used to prevent uncontrolled scope growth.

The planned set of Microsoft Dataverse environments (development, test, UAT, production) with their purpose, ownership, data policies, and promotion path between them.

A packaged solution whose components cannot be modified in the target environment without uninstalling it, used for controlled promotion to test and production.

A solution container used in development environments where components remain editable and can be added to or removed freely before packaging.

The rule that multiple solutions affecting the same component are applied in order, with the most recently installed managed solution winning conflicts at runtime.

An automated sequence that exports a solution from source control and imports it through environments, running validation and tests at each stage.

A static analysis tool that reviews solution components against Microsoft's rules for performance, maintainability, and upgrade safety, returning prioritized findings.

Accumulated shortcuts such as unsupported customizations or duplicated logic that slow future changes and raise upgrade risk if not tracked and repaid.

Configuration uses built-in settings such as forms, views, and business rules; customization adds code or components, raising upgrade and support cost.

A recurring design for connecting systems, such as real-time request-reply, asynchronous messaging, or scheduled batch sync, chosen based on latency and volume needs.

A cloud messaging service used to decouple Dynamics 365 from external systems through queues and topics, supporting reliable asynchronous processing and retry.

A registration in Dataverse that posts event payloads to an HTTPS endpoint when records change, enabling near-real-time outbound notification to external services.

Server-side compiled code that runs synchronously or asynchronously in response to Dataverse pipeline events, used to enforce logic that configuration cannot express.

A Dataverse entity whose records are not stored locally but retrieved at query time from an external data source through a provider, avoiding data duplication.

The plan for extracting, cleansing, mapping, and loading legacy data into the new system, including cutover sequencing, validation, and reconciliation approach.

A specification linking each source field to its target field, with transformation rules, default values, and ownership of unresolved gaps.

The fitness of data for its intended use, assessed through completeness, accuracy, uniqueness, and timeliness, usually remediated before migration and monitored afterward.

A minute-level schedule for the transition from legacy to new system, covering freeze windows, data loads, validation checks, rollback triggers, and go-live sign-off.

A documented assessment confirming that scope, testing, training, data, support model, and rollback plans meet agreed exit criteria before production release.

A defined post-go-live period of elevated support with daily triage, faster response targets, and close monitoring to stabilize the new system.

The agreed tiers, roles, response targets, and escalation paths for handling incidents and service requests after the project team hands over.

The overall plan defining test levels, entry and exit criteria, environments, data, roles, and reporting used to verify the solution meets requirements.

A documented set of preconditions, steps, test data, and expected results that verifies one requirement or scenario and records pass or fail outcome.

Business-led validation in a production-like environment confirming that end-to-end processes work and users can perform their jobs with the new system.

Re-executing previously passed tests after changes to confirm existing functionality still works, typically automated and run at each deployment stage.

Planning, creating, masking, and refreshing data used for testing so scenarios are realistic, repeatable, and compliant with privacy obligations.

A maintained log of project risks with likelihood, impact, owner, mitigation, and status, reviewed at governance meetings to drive decisions.

The decision rights, forums, and escalation paths that determine who approves scope, design, and release decisions, and how conflicts are resolved.

Choosing between waterfall, agile, or hybrid delivery based on requirement stability, regulatory constraints, team distribution, and cadence of stakeholder availability.

Design of security roles, teams, business units, and field-level profiles that grant users the minimum access needed while supporting segregation of duties.

A structured review approach in which architecture, data, security, and deployment decisions are validated against proven practices before build and go-live.