- Start with a Dataverse table, correct column types, and relationships.
- A model-driven app builds forms and views from your tables fast.
- Security roles control who sees which rows, down to the column.
- A Power Automate flow adds the notifications a prototype skips.
This guide is for an operations or IT lead who needs a real internal tool, a request tracker, an asset log, a simple intake app, and wants it to last. By the end, you'll have a working app on Microsoft Power Apps and Dataverse with a proper data model, a form and views, role-based security so the right people see the right rows, and a notification when something happens. This is the durable alternative to an AI-generated prototype that looks great and quietly has no database underneath.
Before you start
You'll need a Power Apps license that includes Dataverse (many Microsoft 365 plans include limited Power Platform use; a Power Apps per-app or per-user plan gives you full Dataverse), and Maker access to a Power Platform environment. If you don't have an environment yet, ask your admin to create one (ideally with a Dataverse database) rather than building in the shared default environment. Sketch your data on paper first: what you're tracking and what fields it has.
Step 1: Create the Dataverse table
In the Power Apps maker portal (make.powerapps.com), confirm you're in the right environment (top-right switcher), then:
- Select Tables in the left nav, then New table > New table.
- Give it a clear display name (for example "Equipment Request") and let it set the plural automatically.
- Add your columns with the right data types: text for a description, Choice for a status (New, Approved, Done), Date for a due date, and a Lookup column to relate it to another table (like a Users or Departments table) if needed.
Getting the column types right now saves real pain later. A status that's a proper Choice column behaves far better than a free-text field someone fills three different ways.
Step 2: Add relationships
If your app touches more than one kind of thing (requests that belong to departments, assets assigned to people), set up the relationships so Dataverse keeps them connected.
- On your table, open the Relationships tab and add a relationship to the related table (for example, many requests to one department).
- This lets a form show a dropdown of valid departments instead of a typed-in guess, and it lets you filter and report across the connection.
Relationships are the part a flat spreadsheet can't do, and they're a big reason a real app beats a clever sheet.
Step 3: Build the app
You have two app styles. Pick based on who uses it and how.
- Model-driven app: Best for structured, data-heavy internal tools used on a desktop. It builds its forms and views from your Dataverse tables automatically, so it's fast to stand up. From your table, select Create an app, or go to Apps > New app > Model-driven.
- Canvas app: Best when you want a custom, mobile-friendly layout or a specific look. Go to Apps > New app > Canvas, connect to your Dataverse table, and design the screens.
For most internal trackers, start with a model-driven app; you get a usable tool in minutes and can add a canvas app later for mobile capture.
Step 4: Configure the form and views
Make the app match how people actually work:
- Edit the main form so it shows the fields people fill in, in a sensible order, and hides system fields they don't need.
- Set up views (saved lists) like "My open requests," "All approved," and "Overdue." Views are just filtered, sorted lists, and they're what make the app feel organized instead of like a raw database dump.
A good set of views ("mine," "open," "overdue") is the difference between a tool people use and a table they ignore. Spend ten minutes here; it's the highest-return polish in the whole build.
Step 5: Set role-based security
This is the part a prototype skips and a real system can't. Dataverse uses security roles to control who can see and do what, down to the table and even the column.
- In the Power Platform admin center, open your environment and go to Settings > Users + permissions > Security roles.
- Create or copy a role (for example "Request Submitter" who can create and read their own rows, and "Request Approver" who can read and edit all rows).
- Set the access level per table (User-level means "only your own rows," Organization-level means "all rows").
- Assign roles to the right users or Microsoft Entra groups.
Don't give everyone the System Administrator role to "make it work." That's how a small app becomes a data-exposure problem. Take the few minutes to define a submitter role and an approver role; it's the whole point of building on Dataverse instead of a shared spreadsheet.
Step 6: Add a notification flow
A real system tells people when something needs them. In Power Automate (make.powerautomate.com), create an automated cloud flow:
- Trigger: "When a row is added or modified" on your Dataverse table.
- Action: send an email or post a Teams message, for example notify the approver when a new request comes in, or notify the submitter when their status changes to Approved.
Keep it simple at first, one notification that matters, and add more later.
Step 7: Test with real users
Share the app with two or three real users (using the role assignments from Step 5) and have them run actual tasks: submit a request, approve one, check that they only see what they should. Confirm the data persists (refresh the page, sign out and back in, it's all still there, which is exactly what the prototype couldn't do), that views show the right rows, and that the notification fires. Fix what they find before you roll it out wider.
What to do next
Start with one table and a model-driven app; resist building five tables before the first one is in real use. Once people rely on it, add relationships, more views, and additional flows as needs become clear. If you've already built something with AI that looks finished but can't be trusted in production, rebuilding it on Power Apps and Dataverse is usually faster and far sturdier than bolting a backend onto the prototype. That's a conversation we're glad to have. Let's talk it through.