MB-700 cheat sheet

Environment strategy: a single production environment plus a tiered non-production chain (dev → build/integration → UAT/sandbox) is the baseline; every extra environment adds a full Dataverse capacity cost and a deployment path to maintain.

Environment types: Production and Sandbox are the only types; Sandbox copies can be reset from a backup, Production cannot be reset - use Sandbox for UAT, training, and pre-production validation.

Solution layering rule: one unmanaged solution per development environment is the source of truth; everything downstream is a managed solution. Never edit managed layers directly in a downstream environment - changes are lost on upgrade.

Deployment model choice: managed solutions via pipelines or Azure DevOps for ALM-controlled releases; Power Platform pipelines for maker-initiated promotions; package deployer for portal/configuration artifacts that are not solution-aware.

App type decision rule: model-driven apps for data-dense, role-based, Dataverse-centric processes; canvas apps for task-focused, connector-heavy, mobile-first surfaces; Power Pages for external/anonymous audiences.

Integration selection: Dataverse Web API or service client for synchronous real-time needs; virtual tables for read-only external data surfaced without replication; Azure Service Bus or webhooks for asynchronous event fan-out with retry semantics.

Capacity planning inputs: Dataverse database/file/log storage, per-environment API request entitlements, and Power Automate flow request limits all derive from license SKUs - validate against the tenant capacity report before go-live.

Security architecture: business units partition data ownership, security roles grant table/record privileges with access levels (User, Business Unit, Organization, Parent:Child), and teams (owner or Azure AD) grant cross-BU access without role duplication.

ALM artifacts to define up front: solution publisher prefix, versioning scheme, connection references vs environment variables (connection references for connectors, environment variables for environment-specific parameters).

Fit-gap framing: classify each requirement as out-of-the-box configuration, extension (code/plugin/PCF), or process change; extensions carry upgrade and testing cost, so prefer configuration unless a documented constraint blocks it.

Licensing decision rule: app access requires a per-user or per-app license; Power Pages uses authenticated vs anonymous user capacity; Dataverse capacity add-ons are separate from user licenses - confirm the licensing model before committing the architecture.

Data model rule: use standard tables and standard columns where semantics match; each custom table adds maintenance and reporting overhead. Choices vs lookup tables: choices for small static sets, tables when the set is administered or needs metadata.

Business process strategy: business process flows for guided stage progression on a table; classic workflows/cloud flows for automation. Do not encode enforcement in BPF alone - BPFs can be bypassed by API writes.

Extensibility strategy: synchronous plugins for validation and data integrity (fast, blocking); asynchronous plugins and flows for integrations and long-running work; avoid synchronous calls to external services in the save pipeline.

Reporting strategy: Dataverse views and dashboards for in-app operational reporting; Power BI with DirectQuery or import for analytical reporting; avoid building reports on top of canvas app internal collections.

Migration strategy: stage legacy data into staging tables, transform, then load with the Data Migration Utility or SSIS/KingswaySoft-style tooling; load before enabling plugins that enforce business rules, or disable them during the load window.

Non-functional requirements to capture: expected record volumes, peak concurrent users, data residency and compliance constraints, RTO/RPO for backup and restore, and offline requirements (mobile offline profiles).

Project governance: a RACI for solution ownership plus a change control board for scope changes; every approved change is a backlog item traceable to a requirement ID and a test case.

Work breakdown rule: decompose by solution component (tables, apps, flows, integrations, reports, security) rather than by phase alone, so parallel workstreams do not collide on the same solution.

Source control: store unpacked solutions (solution.zip extracted to XML) in Git; enable solution packager mapping; enforce a branch policy where main maps to the build environment's managed solution.

Deployment pipeline stages: dev (unmanaged) → build (managed, automated export) → test/UAT (managed, automated import) → production (managed, manual approval gate). Each stage has a pre-deployment backup for managed imports.

Environment variables and connection references must be resolved per environment at import time; an unresolved connection reference blocks flow activation - validate in the target environment before the deployment window.

Dependency management: solution layers stack in import order; a patch (child solution) can only be created from a managed parent in the same environment - plan whether to ship patches or full version upgrades.

Risk register entries specific to Power Platform: deprecated connectors, API request entitlement exhaustion, tenant-level DLP policy changes blocking a connector, and solution upgrade failures from unmanaged customization in target.

Handover artifacts: solution documentation, deployment runbook with rollback steps, admin roles and service principal registrations, and a support model defining who owns each environment.

Test pyramid for Power Platform: unit tests for plugin/PCF code (e.g., FakeXrmEasy or mocked context), integration tests for flows and APIs, and end-to-end UI tests for app scenarios; UI tests are slowest and fewest.

UAT entry criteria: managed solution deployed to a UAT environment refreshed from production-like data, all critical test cases passing in the test environment, and business sign-off on the test script set.

Regression scope rule: any change to a shared component (a table column used by multiple apps, a security role, a connection reference) triggers regression of every consumer, not only the changed app.

Test data strategy: use a data refresh from production with anonymization, or a seeded data package; do not run volume tests against a sandbox with production capacity limits shared with other environments.

Performance testing: measure form load, view load, and flow run duration against the documented API request entitlement; load tests consume API requests and can throttle the tenant - schedule them in a dedicated environment.

Security testing: verify each persona's security role set by impersonation or test users; check field-level security, business unit boundaries, and that flows run under the intended connection owner (not a departing employee's credentials).

Defect triage rule: severity is driven by business impact (blocker, critical, major, minor); a blocker in a critical test case blocks go-live regardless of open-count thresholds.

Go-live gate: exit criteria include zero open blockers, agreed deferral list for non-blockers, cutover rehearsal completed, and a signed rollback plan.