Stop Using Power Platform Plugins One at a Time: Let GitHub Copilot Orchestrate the Whole Solution

TL;DR The real value of the Power Platform plugins is not using each one by itself. GitHub Copilot, or another capable coding assistant, can combine the Power Apps, Dataverse, and Power Automate plugins with one prompt to build an end-to-end solution. In my test, it created a document submission app, its data model, the cloud flow, and most of the connections in about 32 minutes of real time for roughly 1,200 credits, or about $12 in the environment I was using. That is kind of crazy!

Most plugin demos are intentionally small. You ask the Power Apps plugin to build a screen. You ask the Dataverse plugin to create a table. You ask the Power Automate plugin to build a flow. That is useful when you are learning what each tool can do, but it is not how real business solutions work.

Real solutions cross boundaries. The app needs data. The data needs automation. Files might belong in SharePoint while their metadata belongs in Dataverse. The user should not care which service is doing which part. They just need the whole thing to work.

That was the goal of this test: give GitHub Copilot App one business outcome, make the right Power Platform plugins available, and see whether it could assemble the pieces into a working solution. Spoiler alert, it did.

If you would rather watch the complete build and all the messy parts that came with it, check out the video here: One Prompt Built My Power App, Dataverse Table AND Cloud Flow

The Big Idea: Plugins Are Building Blocks, Not Separate Destinations

The Power Apps, Dataverse, and Power Automate plugins are impressive on their own, but thinking about them individually puts an artificial limit on what you can ask an AI coding tool to accomplish. The better question is not, “What can this plugin build?” It is, “Can the coding assistant choose and combine the right plugins to solve my problem?”

In this example, GitHub Copilot acted as the orchestrator. It interpreted the request, divided the work across the available plugins, asked a few useful questions, generated the components, and then brought those components together. The individual plugins did specialized work, while Copilot kept the overall solution in view.

The One Prompt That Defined the Whole Solution

I started with a single prompt that described the business outcome and the important constraints. Cleaned up slightly for readability, it looked something like this:

Build me a Power Apps canvas app for uploading files. Use the blank app I already created. The app should let a user enter a document title, category, notes, and upload a file. Create a Dataverse table called Doc Submission to store the information. Create a Power Automate flow that saves the file in the SharePoint document library I already built. Save the SharePoint file URL with the submission information in Dataverse. Show recent submissions in the app. Build and connect everything needed to make it work, but if you need anything done through the browser, ask me to do it. Do not use Playwright.

• The prompt names the user experience: a canvas app for document submissions.

• It defines the fields the user needs to enter.

• It says where the file should go: an existing SharePoint document library.

• It says where the submission metadata should go: a new Dataverse table.

• It explains that the SharePoint URL must be stored with the Dataverse record.

• It asks for recent submissions to appear in the app.

• It gives Copilot permission to build and connect the necessary pieces.

• It establishes a collaboration boundary by asking Copilot to hand browser-only steps back to me.

That last instruction mattered. GitHub Copilot can use browser automation for some tasks, but it can be slower, more expensive, and more fragile than simply asking a human to make a connection in Power Apps Studio. The goal was not to prove that AI could click every button. The goal was to finish the solution efficiently!

How Copilot Divided the Work Across the Plugins

Once the objective was clear, Copilot worked through the solution in layers. Each plugin handled the part of the problem it was designed for, but the output of one plugin became the input for the next.

1. The Dataverse Plugin Built the Data Foundation

The document submission process needed structured data, so Copilot used the Dataverse capabilities to create a Doc Submission table and its columns. That table became the source of truth for the document title, category, notes, SharePoint file URL, and other submission details.

This is an important distinction. The uploaded file itself went to SharePoint, but the business record went to Dataverse. That split is common in real solutions. SharePoint is a natural place for documents, while Dataverse gives the app a structured data layer for filtering, relationships, security, and future expansion.

About six minutes into the run, the Dataverse table was created and the existing SharePoint document library had been confirmed. Copilot also accounted for the 10 MB file-size choice it had asked about earlier.

2. The Power Automate Plugin Built the Integration Layer

The app needed more than a Patch operation. It needed to accept a file from Power Apps, create that file in SharePoint, retrieve the resulting file information, create the matching Dataverse record, and report back to the app. That is where the Power Automate plugin came in.

The generated cloud flow followed the basic pattern you would expect:

• Power Apps triggers the flow and sends the submission fields and file.

• The flow creates the file in the existing SharePoint document library.

• It gets the newly created file properties so it can capture the file URL.

• It creates the Dataverse row with the submission details and SharePoint link.

• It responds to Power Apps when processing is complete.

When I inspected the flow, it was a little more complicated than I might have built by hand. I also questioned whether the success and failure responses were returning enough useful information. That did not invalidate the result, but it reinforced the same rule I use with any AI-generated solution: trust, but verify.

3. The Power Apps Plugin Built the User Experience

With the table and flow available, Copilot moved on to the canvas app. It planned a document submission screen with a soft, approachable style, a warm cream background, fields for the submission details, an upload experience, and a list of the newest submissions.

Copilot asked me to approve the screen plan before it built the interface. That checkpoint was useful because it let me validate the intended experience without watching every control get created. After approval, the canvas app work took the largest chunk of the run.

One build step alone took a little over eight minutes.

The finished app accepted a document title, category, notes, and file. Submitting the form called the cloud flow. The uploaded file appeared in SharePoint, the Dataverse row appeared with the submitted information, and the new submission showed up in the app gallery.

The Connections Were the Hand-Off Points

The most important parts of the build were not the isolated components. They were the hand-offs between them:

• The canvas app had to know about the Dataverse table.

• The canvas app had to call the generated Power Automate flow.

• The flow had to understand the payload coming from Power Apps.

• The flow had to connect the SharePoint file with the Dataverse record.

• The app had to refresh and display the resulting record.

Copilot asked me to add the Dataverse table and flow to the existing app in Power Apps Studio. I initially questioned the instructions, then realized they were correct. I added both connections manually in roughly 30 seconds to a minute, even with a few wrong clicks along the way. This was way faster and cheaper than letting GitHub Copilot App use browser control via Playwright to do it for its self.

That manual step was not a failure. It was efficient collaboration. In an earlier approach, browser automation spent seven or eight minutes trying to do work I could complete almost immediately. If your goal is a working solution, the best process may be AI-generated components plus a few quick human hand-offs.

Testing the Complete Solution

A multi-plugin build is only valuable if the complete chain works. Copilot asked permission to run an end-to-end backend test using a clearly labeled test file and an invalid submission. I appreciated that it asked before leaving test data behind. In an earlier run with a different model, the test data was created without the same warning.

The backend test passed. I then tested the app in preview mode by entering a title, category, and notes, choosing a file, and submitting it. The resulting record appeared in the recent submissions gallery, and the file could be opened from the application.

I also verified the individual systems:

• The Power Automate run completed successfully.

• The uploaded file existed in the SharePoint document library.

• The Dataverse table contained the matching submission record.

• The canvas app displayed the new submission and could open the file.

That is the real proof of orchestration. Three plugins did not merely create three disconnected artifacts. Together, they produced one working business process.

What Went Wrong, and Why It Matters

The build was not perfectly smooth, and that is worth talking about because the rough edges are part of the real story.

Browser Automation Was Not Always the Best Choice

Some Power Apps Studio tasks are still awkward to perform programmatically. Letting browser automation do everything can consume more time, tokens, and credits. For known, simple steps, it can be smarter to have Copilot pause and let you complete the action.

The Generated Flow Deserved Inspection

The flow worked, but parts of it felt more complicated than necessary, and the response handling deserved another look before production use. AI can get you to a working first version quickly, but “it ran once” is not the same as “it is production ready.”

Keep in mind, you can ask GitHub Copilot to help or tell it your concerns, you don' have to edit by hand BUT if editing by hand is easy or quicker then step away from the agent and do it yourself.

Saving the App Blew Up at the Finish Line

After the solution was working, Power Apps Studio returned a network error during save and told me to refresh. When the browser came back, the app appeared blank. Yikes.

Fortunately, Copilot still had a local copy of the generated YAML. I re-added the Dataverse source and flow, explained the save failure, and asked it to rescue the app. It verified the blank state and pushed the app content back. The controls reappeared, the second save succeeded, and I was able to publish the application.

That recovery was one of the strongest moments in the demo. The AI was not only useful for initial generation. It could also use its local working files to recover from a platform failure.

How Long Did It Take and What Did It Cost?

The complete run took about 32 minutes of real time, excluding the extra time spent reacting to the save failure. That was faster than the approximately 45 to 55 minutes I had seen with an earlier approach.

The run used about 1,200 credits, which was roughly $12 in the environment I was using. An earlier test showed around 1,900 credits, although that run included additional work, so it was not a clean comparison.

I tested this run with the higher-end Astra 6 model. The earlier working example had been created with Sonnet 5, so the expensive model was not required. My result suggested that a stronger model might complete the work faster and with fewer detours, but that is anecdotal. Do not make a model or budget decision from one run.

Also, do not spend the whole run staring at the screen. Copilot can notify you when it needs a decision. The productivity gain comes from letting it work while you do something else, then stepping in at the checkpoints that actually require your judgment.

How to Write Better Multi-Plugin Prompts

You do not need to tell Copilot which plugin to call at every moment, but you do need to describe the outcome clearly. A strong orchestration prompt usually includes:

• The business problem and the person who will use the solution.

• The required user inputs and outputs.

• Where different types of data or files should be stored.

• The automation that should happen after the user acts.

• What should be visible in the finished app.

• Existing assets that should be reused instead of recreated.

• Constraints such as file size, naming, or browser automation preferences.

• The situations where Copilot should stop and ask you to take over.

The prompt should describe the finished system, not merely the first component. If you ask only for a form, you may get a form. If you describe the complete document submission process, Copilot can reason across the app, data, automation, and file storage layers.

What This Means for Power Platform Development

The lesson is bigger than this one document submission app. As plugin ecosystems improve, the unit of work changes. You are no longer limited to asking AI for a control, a formula, a table, or a flow. You can ask for a business capability and let the coding assistant assemble the necessary services.

That does not remove the need for Power Platform expertise. In fact, experience becomes more valuable in different ways. You need to recognize good architecture, spot unnecessary complexity, validate security and error handling, understand where the AI is likely to struggle, and decide when a 30-second manual step is better than eight minutes of automation.

This is why I think of Copilot as a teammate. It can do a lot of the building, but you still provide direction, judgment, testing, and the occasional rescue mission. When that partnership works, complete solutions become faster and less expensive to prototype.

FAQ

Can GitHub Copilot use more than one Power Platform plugin in the same request?

Yes. In this test, one prompt led GitHub Copilot to use Power Apps, Dataverse, and Power Automate capabilities to build different parts of the same solution.

What did each plugin do?

The Dataverse plugin created the data foundation, the Power Automate plugin created the file and record-processing flow, and the Power Apps plugin built the canvas app experience. Copilot coordinated the work between them.

Did Copilot build everything without human help?

No. I manually added the Dataverse table and generated flow to the existing canvas app, adjusted display settings, tested the app, and completed save and publish steps. Those interventions were faster than forcing browser automation to do everything.

Did the generated solution work?

Yes. The app uploaded a file, the flow stored it in SharePoint, Dataverse received the submission record and file URL, and the new record appeared in the app. The components were also checked individually.

Is an AI-generated solution ready for production?

Not automatically. You still need to inspect the app, flow, data model, responses, error handling, security, connections, and test data. The generated flow in this example worked, but parts of its structure and response handling deserved further review.

Do I have to let Copilot control the browser?

No. For simple browser-only steps, asking Copilot to pause can be faster and cheaper. Use browser automation where it adds value, not merely to prove that it can click the buttons.

Key Takeaways

• The biggest opportunity is not using Power Platform plugins individually. It is letting a coding assistant orchestrate them around a complete business outcome.

• One prompt produced a canvas app, Dataverse table, Power Automate flow, SharePoint integration, and recent-submissions experience.

• The hand-offs between Power Apps, Dataverse, Power Automate, and SharePoint were more important than any one generated component.

• Human intervention was valuable when a browser-only connection could be completed faster manually.

• The complete run took about 32 minutes and used roughly 1,200 credits in the tested environment.

• The save failure demonstrated that local generated files can also help recover work after a platform problem.

• AI-generated solutions still require inspection, testing, and production hardening. Trust, but verify.

  
  

Final Thoughts

Stop asking what each plugin can do by itself, they don't have to exist in a vacuum. Start asking what problem GitHub Copilot can solve when those plugins work together.

The Power Apps plugin can build the experience. The Dataverse plugin can create the data model or security roles or even a model-driven app. The Power Automate plugin can connect the process. Copilot can keep the full outcome in view and coordinate the work.

That is where these tools become much more interesting than a collection of isolated demos.

If you want help building solutions like this, training your team to work with AI-assisted Power Platform development, or figuring out where this approach fits in your organization, the team at PowerApps911 can help. Whether you need training, mentoring, or someone to build it with you, reach out and let’s build something awesome together. Click the Contact button and tell us how to help!