Model-driven app designer

What it does

The modern app designer is the WYSIWYG surface where you assemble a model-driven app — pick the tables, forms, views and dashboards it contains, build the navigation, attach business process flows, then save and publish. Changes show in a live preview of the app as users will see it.

Key facts

Three panes on the left: Pages (the navigation structure of areas, groups and subareas, plus all other components), Data (tables in the app and tables available in the environment), Automation (business process flows in the app).
The command bar carries Add page, Settings, Edit form, Comments, Save, Publish and Play. Play opens the app in run mode in a new tab.
Save and Publish are separate. Publish is what makes changes visible to users.
Navigation settings, reached from ... next to Navigation, include Show Home, Show Recent and Show Pinned (all on by default), Enable collapsible groups (off by default) and Enable Areas (off by default, on automatically for apps that already have multiple areas, and not disableable while multiple areas exist).
The designer has a preview size switcher, a zoom slider and fit-to-screen, so you can check how a form behaves at different widths without leaving it.
Documented limitation: the app's URL can't be specified.
The classic app, form and view designers were deprecated from October 2023, and the Switch to classic command is no longer available by default.
Apps must be created inside a solution. Prerequisites are a Dataverse database in the environment and an Environment Maker, System Customizer or System Administrator role — or the equivalent privileges: create/read/write on App, read/write on Customizations, read on Solution.
The unique name and app URL suffix can't be changed after creation.

When to use / skip

Use the modern designer for everything — the classic one is deprecated and the escape hatch is gone. The real judgement call isn't which designer, it's how many apps. One big app with several areas is easier to maintain and easier to license, and it's what most clients actually want when they say "one system". Separate apps earn their keep when different audiences need genuinely different navigation and you want the app-level security boundary. Anything more than about three or four apps over the same tables and you're maintaining site maps for a living.

Configuration decisions

How many apps, and where the boundary sits — by audience, by business function, or by security role.
Whether areas are enabled, which is effectively a one-way door once you have more than one.
Which forms and views are included per table, since including all of them is the default and gives users a cluttered form selector and view picker.
Whether business process flows are attached at the app level and which ones.
Whether Home, Recent and Pinned stay on, and whether groups collapse.
The app name, unique name and URL suffix, all of which you're stuck with.

Gotchas

The unique name and URL suffix are permanent. Get them right at creation or rebuild the app.
You can't set the app's URL, which matters when the client wants a tidy bookmark or a link in an intranet page.
Enabling areas can't be undone while the app still has multiple areas, so the setting quietly commits you.
Everything the app touches has to be in the solution. Forget a view or a web resource and it works in dev and breaks in test.
The live preview shows the app's chrome and the default form, which is not the same as playing the app with real data and real security roles. Always Play with a test account.
Saving isn't publishing. An unpublished model-driven app change is invisible to users, and it's invisible to your own testing if you play the app from a different session.

Consultant notes

Do the app-boundary design on a whiteboard before touching the designer. Splitting or merging apps later means rebuilding site maps and re-doing sharing.
Sharing a model-driven app is separate from Dataverse security. Users need both the app shared to them and the security role that grants table access; clients conflate the two constantly.
Prune the included forms and views per table. It costs ten minutes and it's the difference between an app that looks designed and one that looks like a default install.
Keep the classic-designer deprecation in mind when reviewing an inherited estate. Anything that still depends on classic-only behaviour is technical debt with a clock on it.
Comments in the designer are genuinely useful on a multi-maker build. Nobody uses them. Make them part of the working agreement.

Worth another look when the app designer picks up more of the classic-only capabilities, or if URL configuration ever ships.