
Are you a maker, a low-code developer, a builder? Do you want to be ten times more productive when you build Canvas apps, model-driven apps, Power Automate flows, and Power Pages?
I’m going to show you a set of tools that will do exactly that. This is different from what you’re used to. But if you’ve already been building apps, you can figure this out.
The hub of everything we do here is Visual Studio Code. Some of you just flinched. “VS Code? That’s a developer tool! I’m just a maker!”
Stop right there. If you build applications, you’re as much a developer as anyone. And we’re going to use the best form of low-code there is: natural language. That’s what developers have chased for decades anyway, a way to describe what they want in plain language and have the machine build it, whether that’s an app, an agent, a website, an automation, or a report.
Let me walk you through the setup, then we’ll build a working Dataverse data model for an expense app from a single prompt. From here, you, as a maker, will be building flows, Power Apps, websites, and yes, even plug-ins and PCF controls!
Prefer to watch? Check out the YouTube version of this post here:
There are a few steps, and you make experience slight different paths, depending on the mood of the AI and what you may have already configured on your machine.
Nothing here replaces your Power Platform tenant. You still need an environment to connect to and build your solutions in. That part hasn’t changed. You will need a certain level of admin access to your tenant. These instructions will show you how to create an environment, just by asking the AI to do it for you. Remember: Tenant -> Environment -> Solution.
Beyond the tenant, you need an agentic coding tool. I use Claude Code, so that’s what you’ll see throughout this walkthrough. You can also use GitHub Copilot, or if you’re adventurous, Codex.

You can start Claude Code on the free tier, but you’ll burn through credits fast. I’m on the Max plan because I use Claude Code every day for a lot of things and I need the capacity. If you’re starting out, the Pro plan is a reasonable place to begin and work up from there.
Whichever agent you pick, get a GitHub account too. If you’re using GitHub Copilot you’ll want a subscription for the tokens and capacity. But even if you stick with Claude or Codex, you still want GitHub for source control. When you’re building apps and agents, you want to save your progress somewhere safe where you can track history. GitHub is a good place for that. Azure DevOps works too, but at the very least, sign up for a free GitHub account. We’ll use it in future videos.

Now the big one: download Visual Studio Code. Some of you may think of it as a developer tool, but really it’s a text editor. It’s the harness that holds the extensions we use for agentic development, and it’s the hub of all our activity. Think of it as a maker tool. It’s free from Microsoft and runs on Windows, Mac, and Linux. Get it installed!
Fire up Visual Studio Code and you’ll land on the welcome screen. You might see an update screen, Microsoft ships regular updates to Visual Studio Code.

The first thing to do is create a folder to hold your projects, then open it. I’ve created a development folder and a project folder inside it called expenseapp, (since that’s what we’re building) but call it whatever you want. I generally use one folder per environment, but it might depends on your project structure. Open that folder and it becomes your workspace in Visual Studio Code.

Look at the icons down the sidebar of Visual Studio Code and click on Extensions (the box of boxes). There are a few you’ll want at a bare minimum.

First, Power Platform Tools. This installs the PAC command-line utilities plus a lot of other tooling. We’ll only use a small subset today, but this is the fastest way to get everything in place. When you or your agents run PAC commands later, this is where they come from. You can install the PAC CLI separately, but if you’re just starting out, this is the best place to start.

Next, your agentic tool. I like Claude Code, so I install the Claude Code for VS Code extension.

You might also install GitHub Copilot Chat, specifically if you’re using Copilot, but it’s worth having anyway. You can run multiple agents side by side and have them check each other’s work.

There are usually two ways to interact with these agentic tools. The first is a side panel. Click the chat icon and you get GitHub Copilot Chat, Claude Code, or Codex right there in the editor. You can chat with it, point it at what you’re working on, and have it write code, review code, provide suggestions, or even explain what your weird co-worker did before he disappeared into the Yukon wilderness.

I find the side panel very helpful, especially when editing existing code, and we’ll explore that in future videos. Today we’re going to work from the terminal instead. That opens up a whole new world. Strap yourself in!
Close the side panel and launch a new terminal from the Terminal menu.

The terminal opens in your project directory. If command lines are new to you, don’t be startled. Ask your Dad about it. We’re just typing commands in plain language and letting the agent do the work.
These days, I use my microphone more than my keyboard, and talk more to my computer than type. This works great for talking to AI agents as well! I use Wisprflow, click here for a free month!
If you’re using GitHub Copilot, you’d type copilot. I’m using Claude, so I type claude. The first thing it asks is whether to trust this folder. Yes, we trust it, this is where we’re doing all our work.

Claude opens up in the terminal, and this is where most of the work happens today. Don’t be intimidated by it. You prompt it the same way you’d prompt ChatGPT or Copilot.

Before we build anything, we want a set of plugins that make talking to the Power Platform much easier. Today we’re installing the Dataverse skills from Microsoft.
They live on GitHub in the microsoft/Dataverse-skills repo. This is Microsoft’s set of Dataverse skills for AI coding agents, wrapping the Dataverse MCP server, the Dataverse CLI, and the PAC CLI.
The repo gives you install commands for both GitHub Copilot and Claude Code. We’re using Claude Code, so I’ll copy that command.

Back in the terminal, I run /plugin install dataverse@claude-plugins-official. I’d already installed it. You manage plugins with /plugin, and you can list what’s installed to confirm the Dataverse plugin is there and enabled.

That plugin brings skills. Type /skills and you can see the Dataverse skills that came with it: dv-admin, dv-connect, dv-data, dv-metadata, dv-overview, dv-query, dv-security, dv-solution, and more.

Now we can start working. I prompt: create a new Dataverse environment.
Claude loads the Dataverse overview skill and starts running the PAC commands, the same Power Platform tooling from earlier. It asks for approval before it runs things. Early on, you want to see what the agents are doing so you learn the process. Eventually you can let more of it run automatically.
Because I’ve connected to several tenants before, it asks which admin tenant to create the environment on.

Then it asks for the environment type. I could have specified sandbox, developer, or trial right in my prompt. Since I didn’t, it asks.

Same with the region. I’ll choose Canada.

Review the answers and submit.

Claude goes through, and after a few minutes the environment is created. We get the name, the sandbox type, the environment ID, organization ID, and tenant ID, everything you’d expect from creating an environment the usual way.

Have we saved much time versus the maker portal? Probably not yet. But everything is happening in one place, inside Visual Studio Code, in the Claude terminal, step by step from a single prompt. And once you can do this from the command line, you can begin to automate it and fold it into your ALM process.
Next, Claude suggests creating an auth profile and a workspace. We want both. I prompt: create the auth profile and connect the workspace.

An auth profile is the set of credentials that connect your user, and Visual Studio Code, to your Power Platform environment. You need it for a lot of things. If I weren’t already connected, this is where the Windows sign-in would pop up. If you’re working in a client’s environment, you’ll likely go through that here.
Part of this process runs Python scripts. When you install the Dataverse connector, it can pull in some Python tooling too. It uses the Dataverse CLI, part of the Dataverse tools, and you’ll see it work through quite a few steps as it wires everything together. This is the brilliance of these skills, they do the heavy lifting for you.
Sometimes it needs to connect using a device code. Grab the code, copy it, and go to microsoft.com/devicelogin.

Paste the code, sign in, and confirm you’re signing into the Dataverse CLI.

Behind the scenes it sets up the refresh token and configures a couple of MCP servers, the Microsoft Learn MCP server and the Dataverse MCP server. It also creates an .env file in your project holding the environment URL, tenant ID, and the MCP client ID it enabled for you, so you don’t have to go into the admin center to turn that on.

A quick note: while recording, I saw an auto-update failed message because I had Claude running in another place. Nothing to worry about.
With the workspace created, we restart the session so the new MCP server can come online. Type claude --continue to pick up where we left off, and approve the new MCP server when prompted.

Let’s confirm the MCP server works. I prompt: list the Dataverse tables in the environment. It reports no custom tables yet, the common ones like account and contact, and around 800 system tables. That’s a stock Dataverse environment, exactly right.

Before building tables, we need a solution and publisher. I prompt: create a new solution and a publisher with the prefix exp. Again, things we’d normally do in the maker portal, now done inside Visual Studio Code.
Claude loads the Dataverse solution skill, asks to proceed with PAC, and creates the publisher with exp as the prefix along with an unmanaged solution in the environment.

We’re staying in one context and using natural language, so there’s no memorizing PAC commands and no hunting through portal screens. We can wrap scripts around this and make it consistent.
This is where we start saving real time. Normally, once the environment, solution, and publisher are set up, you’d go into the maker portal and click through building tables and columns. Instead, here’s the prompt:
I want to build a Dataverse data model for an expense app. The tables should include expense header and expense lines. The expense header should have an auto number, date, description, total amount, and a lookup to the system table contact. It should have status reasons of open, submitted, approved, paid, and closed. The expense line should have a date, amount, description, and a file field for the receipt.
That’s the kind of thing you’d have in your spec. The old way, you’d type it all into the maker portal, which takes a while.

After a few minutes, the tables are built. It even caught its own mistake: it first created decimal fields where I wanted currency fields, recognized the issue, and went back to fix it. That’s the kind of detail worth specifying in your prompt up front so the agent doesn’t have to rework it. We end up with the expense header and expense line tables, the contact lookup, and the relationship, all published as part of the solution.

Most of you, when you need dev data, have typed in the Simpsons, Chuck Norris, and whatever else just to have something to work with. The agents can do that for us. I ask it to add sample data, it uses the Dataverse data skill, and it loads sample contacts, expense headers, and expense lines that are internally consistent.

This is exactly the repetitive, tedious work we all do as developers, and it’s a good fit for an agent.
Over in the maker portal, the expense and expense line tables are there, with the sample data populated.


And in the project folder, you can see everything the process set up: the .claude configuration, the plugins, the Python scripts, the solution broken down into its entities, the .env file, and more.

From here you can keep going, build a model-driven app, a Canvas app, a Power Pages site, Power Automate flows, plugins, generative pages, or client-side scripting, all from the same place. You can be ten times more productive because the agent does the heavy lifting.
One caveat. You still need to understand how Dataverse works and how these apps fit together to build this out well and be a good solution architect. This is a tool, not a replacement for knowing your craft. Could I have created the environment, solution, and tables by hand in the maker portal? Absolutely. But with everything in one spot, I can start building agents to do the repetitive work so I can focus on the creative parts.
Next up, we’ll put this project into source control so you can track every change.
As a maker, this can feel like a lot at first. Its definitely a paradigm shift. Once you start using these tools, you’ll see how quickly they save time and let you use pro-code methods to build powerful Power Platform solutions.
What will you build?
Nick Doelman is a Microsoft MVP (8x), podcaster, trainer, public speaker, and competitive Powerlifter. Follow Nick on X at @readyxrm, Instagram, LinkedIN, and Bluesky.
Need Power Platform expertise, training or implementation help? Check out Nick’s website for more details.
Listen or watch the the Power Platform Boost podcast with Nick and co-host Ulrikke Akerbæk every second week for news and updates from the Power Platform community!
Original Post https://readyxrm.blog/2026/07/16/ditch-the-power-apps-maker-portal/