App designer for model-driven apps

Every Dynamics 365 CRM-side product (Sales, Customer Service, Field Service, Project Operations) is a model-driven Power App — a curated experience over Dataverse with a site map, included tables, configured forms, views, dashboards, and process flows. Building your own model-driven app, or customising the standard Dynamics 365 ones, happens in the app designer.

What a model-driven app is. Where a canvas app is pixel-perfect drag-and-drop, a model-driven app is generated from configuration:

• Tables included — which Dataverse tables the app shows.
• Site map — the navigation structure (areas → groups → subareas).
• Forms — which forms are available for each table.
• Views — which views appear in each table's list.
• Charts and dashboards — analytical surfaces.
• Business process flows — staged processes embedded in forms.
• Components per table — fine-grained inclusion of business rules, security roles, scripts.

The platform renders the app — list pages, forms, command bar, navigation — automatically from the configuration. No layout drawing; consistent, responsive, mobile-aware UX out of the box.

The site map. The site map is the left-side navigation menu of the app. It has:

• Areas — top-level groupings (Sales, Service, Settings).
• Groups within areas — labelled subdivisions.
• Subareas within groups — the actual navigation items, each pointing to a table, a view, a dashboard, a URL, or a web resource.

A typical sales-oriented app has areas for Sales (with Leads, Opportunities, Accounts, Contacts subareas), Marketing (with Campaigns, Marketing Lists), and Reports / Dashboards.

App designer UI. Microsoft has been migrating from the older app designer (in the classic interface) to the modern app designer in the Power Apps maker portal. The modern designer offers:

• Visual editing of the site map with drag-and-drop.
• Side-pane lists of available tables, forms, views, business rules.
• Inline forms designer for the included forms.
• Live preview during editing.
• Solution-aware so the app deploys cleanly across environments.

Customising standard Dynamics 365 apps. The shipped Dynamics 365 apps (Sales Hub, Customer Service Hub, Field Service, etc.) can be customised — adding custom tables to the site map, removing tables not in use, adjusting which forms / views are shown. Customisations live in unmanaged solutions in dev, exported as managed for promotion.

Building a new app from scratch. Start in app designer:

1. Name the app.
2. Add tables — pick from Dataverse's existing tables.
3. Configure the site map — group tables logically, add labels, set icons.
4. Configure forms per table — which form is the default for each table.
5. Configure views per table — which views appear in the list selector.
6. Add dashboards and business process flows.
7. Save and publish.

The result is a new app accessible at /apps/<app-id> URL, with its own icon in the App selector.

Multi-app patterns. A single Dataverse environment can host many model-driven apps, each with different tables and configurations:

• Sales app — Sales-relevant tables and views.
• Service app — Cases, Knowledge, SLAs.
• Internal-tool app — Custom tables for internal processes, no Dynamics standard tables.
• Read-only viewer app — for executives or external auditors.

Each app respects its own security; users only see apps they have access to.

Theme and branding. App themes (colours, logos) are configured per app or per environment. The shipped Dynamics 365 apps have their own themes; custom apps can have bespoke branding.

Mobile. Every model-driven app renders on the Power Apps mobile app automatically. Configure mobile-specific form variants if the standard form is too dense for small screens.

Limits.

• Structure is constrained — model-driven apps don't support arbitrary layout. Pages are forms / lists / dashboards / business process flows. Anything else needs canvas pages embedded in the app.
• Performance — apps with many tables and many forms slow down. Audit included content.

Common patterns.

• One app per persona / role — Sales for sellers, Service for agents, Field Service for technicians. Each focused.
• One environment, many apps — share data, separate experiences.
• Custom page injection — when you need pixel-perfect UX for one screen, embed a custom canvas page in the model-driven app.

Operational reality. Apps are configuration, not code. Iterate them as the business learns what users actually need. Version them in solutions; promote through environments cleanly.