Create a technical design
Design deliverables, not components
A technical design for a Power Platform solution is a package of artifacts someone else could build from: the data model (tables, keys, ownership, relationships), the app inventory (model-driven, canvas, Power Pages, code-first), the environment and ALM plan (dev to test to prod, managed solutions, pipelines), the security model (business units, teams, roles, field security profiles), and an integration contract per interface (endpoint, direction, trigger, payload, retry, idempotency).
Exam items rarely ask you to name a feature; they ask you to justify a choice. Typical decisions: model-driven app when the process is data-centric and should inherit the Dataverse security model; canvas when the UI must be pixel-controlled or run offline on a phone; Power Pages when external users need authenticated access without a per-user licence; virtual tables when the data must stay in the source system of record; dataflows or Azure Data Factory when data must be copied and transformed.
Traps
- 'Users must work offline' points to a canvas app with an offline profile, not a model-driven app.
- 'The data must remain in the external system' points to virtual tables or a gateway, not an import.
- 'Two systems must stay consistent in near real time' points to dual-write or event-driven integration, and you should expect a follow-up about conflict handling.
- Non-functional requirements usually decide the design more than features do. Service protection limits are enforced per user and per environment, so a design that issues thousands of API calls per user per hour is wrong before it is built.
- A design that skips solution layering cannot be promoted between environments.
Rule of thumb
Design for idempotency and retry from day one: any message that can arrive twice must be matched on an alternate key, never on the GUID the sender invented.