Model-Driven Apps: Forms, Views, Charts and Access
Composing a model-driven app from the data model — and the access-control decisions that determine who sees which form, which view, and which app.
Model-driven starts from the data
A model-driven app is an app that builds itself from your tables.
You do not draw the screens. You tell the app “include Depot Run, Depot and Account,” and it produces lists, record pages, and navigation using the forms and views you defined on those tables.
The trade-off is straightforward: you get a lot of app for very little effort, but you get less control over exactly where things sit on the screen. Canvas apps trade the other way.
Forms and views, revisited from the app side
You met forms and views as data-model artefacts. From the app side, two extra ideas matter.
| Artefact | Answers the question | Configured on |
|---|---|---|
| View | Which records, which columns, what order? | The table — then surfaced in apps |
| Main form | What does one record look like when opened? | The table — the primary form type in model-driven apps |
| Site map | How does a user navigate this app? | The app itself, in the app designer |
| Chart | What does this set of records look like visually? | The table — displayed against a view, but not welded to one |
| Dashboard | What do several charts and lists look like together? | The app or the system |
Charts read from a view — but they are not tied to one
A chart in a model-driven app does not query independently — it visualises the records in the view it is currently displayed with. Change the view’s filter and the chart changes with it.
That is why “the chart shows the wrong records” is usually a view problem, not a chart problem. The fix is upstream.
The nuance that catches people: the view you pick while building is a preview, not a permanent binding. Microsoft is explicit — “The view isn’t permanently associated with the chart. The next time you open the chart, the chart displays using the configured default view. You can change the view to display the chart for the data from a different view.”
So a user can point the same chart at a different view and get a different picture. If an answer option claims a chart is locked to the view it was authored against, that option is wrong.
One more checkable number while you are here: charts display views that return up to 50,000 records.
Access: three separate levers
This is where model-driven apps get genuinely testable, because Microsoft lists two distinct access objectives — access to forms and views, and access to model-driven apps — and neither is the same as record security.
| Lever | What it controls | What it does NOT control |
|---|---|---|
| Access to the app | Whether a user can open the app at all — you assign security roles, or share directly with individual users and teams from the People list | What data they see once inside. That is still the table's security roles |
| Access to forms | Which form layout a role sees when opening a record | Whether they can retrieve the underlying data by other means |
| Access to views | Which non-default public views a role sees in the table's view selector, once role-based view access is enabled for the environment | Which records those views return — that is record-level security |
| Table security roles | Which records a user can create, read, write, delete | Which app or form they use to do it |
The two-lock model
Think of it as two locks a user must pass:
- The app lock — has this app been shared with me, either through a security role or directly with me as a user or team from the People list? If neither, the app does not appear in my list at all.
- The data lock — does my security role let me read these records? If not, I open the app successfully and see an empty list.
The classic troubleshooting question describes exactly that second state: “the user can open the app but sees no records.” Granting more app access will not help. The problem is the table privileges.
Form access is not a security boundary for data
Restricting a role to a form that omits a sensitive column does not protect that column. The user can still reach the value through views, exports, search, or the API.
Form access is about giving each audience a sensible layout. If the requirement is genuine confidentiality, the answer is column-level security — as covered in Domain 1.
Composing the app
Composing is the act of choosing which components the app contains and how a user navigates them.
What 'compose' actually involves
- Pick the tables the app needs. Fewer is better — every table you add is another thing to secure and maintain.
- Choose which forms and views of those tables the app surfaces.
- Build the navigation — areas, groups and subareas in the site map.
- Add pages — including dashboards and, as of recent releases, generative pages (the next module).
- Publish, then share — by assigning security roles, or by adding individual users and teams from the People list.
An app that is published but not shared is invisible. An app that is shared but whose users lack table privileges is empty. Both states look like “it doesn’t work” to the user, and telling them apart is the skill.
Kite Freight’s dispatch app
Nadia composes a model-driven app called Depot Dispatch:
| Decision | Choice | Reasoning |
|---|---|---|
| Tables | Depot Run, Depot, Account | The minimum set that supports the dispatcher’s job |
| Views surfaced | Active Runs Today, Delayed Runs, All Runs | Dispatchers work by exception, so the delayed view is the landing point |
| Chart | Runs by status, shown against Active Runs Today by default | Ravi wants the shape of the day at a glance |
| Forms | Dispatcher form (operational columns) and Finance form (adds cost) | Two audiences, two layouts |
| Cost column | Column-level security, not form omission | The Dispatcher form hiding cost is convenience; the security is at column level |
| Sharing | Dispatcher and Finance security roles assigned to the app | Without this the app does not appear for anyone |
Two weeks later a new dispatcher reports the app is empty. Nadia checks the app sharing first — it is fine. The actual cause is that the new hire was never given the Dispatcher security role on the Depot Run table. The app lock was open; the data lock was not.
Quick recall
Check yourself
Kite Freight's finance team needs to open Depot Run records and see the cost column. Dispatchers must never be able to obtain the cost value. What is the correct configuration?
Nadia publishes a new model-driven app. She can use it, but no one else can even see it in their app list. What is the most likely cause?