Architect a solution
Design is a set of decisions, not a diagram
A solution architecture documents decisions across six pillars: apps, data model, security model, integrations, ALM and environment strategy, and licensing and capacity. Run design workshops, agree a minimum viable product scope, and record rationale, alternatives considered, and consequences for each decision.
Choose the app style from the audience and task: model-driven apps for Dataverse-centric, licensed internal processes; canvas apps for focused task experiences and offline needs; Power Pages for external or anonymous users. Design the data model before the apps: use choices for small stable sets, tables with relationships for evolving lists, and alternate keys for integration. Design security early - business units, hierarchies, teams, column security, and Microsoft Entra groups - because retrofitting it is expensive. Decide synchronous versus asynchronous integration, acknowledge API and request limits, and keep secrets in a vault rather than in flows. Plan separate development, test, UAT, and production environments, promote managed solutions downstream through pipelines, and define a business continuity and disaster recovery position.
Traps that appear in questions
- Picking a model-driven app for anonymous external users, or a canvas app for a large multi-entity transactional workload.
- Ignoring delegation and data volume limits in canvas apps.
- Designing the security model after the data model and app layer.
- Deploying unmanaged solutions to production, or working in a single environment.
- Assuming every user needs a premium license, or the reverse.
Rule of thumb
Decide the data model and security model first; apps, automation, and integrations hang off them. Worked example: field technicians need offline inspection checklists for a small set of entities. A canvas app with offline profile and Dataverse tables satisfies the need without a model-driven shell, and the security model is a single business unit with a team-based row scope.