A sales director I worked with a couple of years ago put it better than any adoption survey ever could: “We only use five of these screens. Why are there forty?” His team was living in the Sales Hub app — forecasts, playbooks, competitors, goal metrics, the whole catalog — and using almost none of it. Reps were losing deals in the navigation before they ever lost them in the pipeline.
If that sounds familiar, this post is for you. We are going to build a small, focused model-driven app on top of the same Dynamics 365 Sales data — accounts, contacts, opportunities, nothing else — so your team gets a front door shaped like their job instead of a warehouse shaped like the product. No code, one afternoon, and nothing about Sales Hub itself changes.
Why the Obvious Approaches Fall Short
There are two tempting shortcuts, and I have watched both go wrong.
The first is editing Sales Hub’s own sitemap — hiding the areas your team ignores. It works, briefly. But Sales Hub is Microsoft’s app: release waves add and move things, your edits layer on top of theirs, and a year later nobody can say which parts of the navigation are yours. You are redecorating a rental.
The second is telling users to ignore the noise. That is not a solution; that is a coping strategy. Every unused area in an app is a small tax on attention, and taxes compound. Adoption problems are usually navigation problems wearing a costume.
The better path is the one model-driven apps were designed for. Think of a model-driven app as flat-pack furniture: Microsoft ships the parts — tables, forms, views, charts, all pre-built and sitting in Dataverse — and your job is not to manufacture anything, it is to decide which pieces belong in this room and how they fit together. Sales Hub is the showroom with everything assembled. You are about to build the one shelf your team actually needs.
Step 1 — Start in a Solution, Not the Default
Go to make.powerapps.com, pick your development environment, and open Solutions in the left navigation. Open your own unmanaged solution — or create one — rather than working in the Default Solution. I use a solution dedicated to the workload, with its own publisher and prefix.
This feels like ceremony when you just want to build an app, but it is the difference between an app you can transport to test and production as a managed solution later and an app welded to the environment it was born in. If you have read my earlier post on keeping solutions unmanaged in dev and managed everywhere else, this is that habit paying rent.
Step 2 — Create the App
Inside the solution, select New > App > Model-driven app. Give it a name that describes the job, not the technology — I am calling mine Deal Desk — and select Create.
The modern app designer opens with a pages pane on the left, a live preview in the middle, and a properties pane on the right. It is empty, and empty is exactly right. Every table you add from here on is a question your users did not ask — so we will add few.
Step 3 — Add Only the Tables That Earn Their Place
On the command bar, select Add page > Dataverse table. Pick Account, Contact, and Opportunity, then select Add. The designer builds the pages — views and forms included — and the preview fills in immediately with the same records your team sees in Sales Hub, because it is the same data. An app is a point of view, not a database browser; two apps looking at one Dataverse is the whole trick here.
Resist the urge to add “just in case” tables. Leads, quotes, products — if the team does not work them weekly, leave them out. You can add a table in five minutes the day it earns its place. Removing one after users have bookmarked it takes considerably longer, politically speaking.
Step 4 — Shape the Navigation Around the Working Day
In the pages pane, use Navigation to organize what you added: create a group — I named mine My Pipeline — and order the subareas the way the day actually runs: Opportunities first, then Accounts, then Contacts. Sales Hub orders navigation by product taxonomy; you get to order it by workflow. Put the thing people open every morning at the top, because they will tap the first item on muscle memory alone.
If the app will serve two audiences — say, reps and a deal-desk analyst — add a second area rather than cramming one list. Areas are the cheapest structure the designer gives you; use them before you reach for anything cleverer.
Step 5 — Trim the Forms and Views
Adding a table brings all of its public views and forms along, which quietly reintroduces the clutter you just escaped. In the pages pane, expand each table and untick the views your team does not use — keeping perhaps My Open Opportunities and Opportunities Closing This Month — and select the one main form they should see. The same principle as the tables themselves: opt in, do not opt out.
One pleasant surprise for the skeptics: the Opportunity form arrives with its business process flow intact, so stage gates and required fields behave exactly as they do in Sales Hub. Process logic travels with the table, not with the app.
Step 6 — Publish, Play, and Share
Select Save and Publish on the command bar, then Play to open the app as a user will see it. Click through a full loop before you show anyone: open an opportunity, advance a stage, check that the forms you chose are the forms that load.
⚠️ Important: publishing an app does not make it visible. Users need a security role with access to the app itself and Dataverse privileges on its tables — building a focused app grants nothing new, it only frames what the user’s roles already allow. Share deliberately: in the solution, select the app > Share, assign the role, and test with a real (non-admin) account before announcing anything.
Where This Approach Stops
Be honest with yourself about scope. This app does not replace Sales Hub for your admins and power users — product catalog maintenance, forecast configuration, and the settings areas still live there, and that is fine. Two doors into one building is an architecture; six is a maze, so resist the temptation to mint a bespoke app for every persona. And because the app definition lives in your solution, it rides your normal ALM pipeline: unmanaged in dev, managed everywhere else, like any other component.
Closing Thought
Nothing we built today added a single capability to Dynamics 365 — every table, form, and process was already there. What changed is the shape of the front door. Model-driven apps come flat-packed, and Microsoft will happily sell you the fully furnished showroom; the craft is in assembling only the room your team lives in. Build the small app. The forty screens will still be there for whoever needs them.
