Slow and inefficient Power BI reports are a widespread cause of low customer satisfaction, bloated costs, wasted compute capacity, and increased total cost of ownership. Fixing these issues often requires a significant time investment and a high level of domain expertise in business intelligence data modeling, Power Query ETL design, and DAX runtime expression optimization.

But what if you could save thousands of dollars in person-hours (often spent on external consultants) by using Microsoft 365 Copilot to analyze your Power BI Desktop files and generate a step-by-step mitigation plan for slow and inefficient reports? What if optimization tasks that used to take days could now be completed in minutes or hours?

In this video, I’ll walk through my methodology for enabling M365 Copilot to read your Power BI Desktop files, produce a consultant-grade 20‑page assessment, and deliver a clear, actionable mitigation plan in less than 20 minutes. With this approach, a resource with intermediate Power BI skills can resolve issues in a few hours that previously required days or more of expert-level effort.

All you need to follow along today is M365 Copilot and Power BI Desktop. Everything described in this article is generally available now, and no additional licensing is required beyond M365 Copilot.

For the example in my video (embedded below), I created a very poorly architected Power BI solution and experienced the following improvements: 

• Semantic Model and Power Query refresh time reduced by 45%
• Semantic Model (Import Mode) size reduced by 79%
• Report visualization rendering times reduced by 25%
• Assessment and mitigation guide that would’ve taken 16-40 hours reduced to 15 minutes
• All changes made in two hours (may have taken an additional 16-40 hours without M365 Copilot guide)

Some of you might ask why I’m not using the new Power BI MCP server capabilities. While powerful, setting up an MCP server requires a high level of technical aptitude and dedicated infrastructure. These resources are simply not available to many Power BI developers.

In contrast, fixing slow Power BI reports using M365 Copilot requires no additional licensing beyond M365 Copilot itself. All sensitive metadata remains within the customer’s tenant, and no advanced coding skills are required beyond standard Power BI development. An organization with hundreds of Power BI developers can realistically ask each developer to apply this method to optimize their own reports.

For my end-to-end demo and tutorial on using M365 Copilot to fix a slow and inefficient Power BI report, you can view my video below:

Step-by-step instructions and copies of the prompts can be found at my blog: Use M365 Copilot to improve Power BI semantic models, power query, and report speed – Greg Beaumont's Data & Analytics Blog 

https://clearmeasure.com/developers/forums/

Richard Lander is a Principal Program Manager on the .NET team at Microsoft. He's been with Microsoft since 2000, and working on .NET since 2003! Currently, he's working on runtime features, docker container experience, blogging and customer engagement. He's also part of the design team that defines new .NET runtime capabilities and features.

Mentioned in This Episode

Episode 289 
Episode 148 
Episode 50  
DotNet Skills 

Suzanne Cook's Assembler Blog 
SourceLink
dnx dotnet-inspect

Want to Learn More?
Visit AzureDevOps.Show for show notes and additional episodes.

On this episode we wade through Apple’s drip‑fed “event week,” from the budget iPhone 17E to the new MacBook Neo/Air M5 and the pricey Studio Display, and argue who each device is really for. The big takeaway: 8GB of RAM is borderline unusable for modern web and dev workflows—buy up if you can—while the Air M5 looks like the sweet spot; plus a fun detour on using Copilot/Fleet to scaffold apps in minutes.

Follow Us

• Frank: Twitter, Blog, GitHub
• James: Twitter, Blog, GitHub
• Merge Conflict: Twitter, Facebook, Website, Chat on Discord
• Music : Amethyst Seer - Citrine by Adventureface

⭐⭐ Review Us ⭐⭐

Machine transcription available on http://mergeconflict.fm

Support Merge Conflict

This post looks at implementing a guest user invite in a cross tenant setup. This is useful when creating partner tenants using an Entra ID MAU license for all partner guests and members. This makes it possible to keep the home tenant separated for internal members.

Setup

The Partners or guest Entra ID tenant is setup to only contain identities and no applications. This is where all the guests are managed. The Entra ID tenant uses a MAU tenant. The application is hosted in the home tenant where all the applications are managed. This can be an App Service, Azure Container application or whatever. This setup is not required if the application is hosted in the same partner tenant.

In the example, the web application uses two Entra ID app registrations, one for the web application authentication and one to create the guest users using Microsoft Graph SDK5. The Graph Application User.Invite.All permission is used and this can be only used from a trusted backend. No delegated permission is used in this setup.

The Graph App registration uses an user assigned managed identity to create the federated credential to use the Enterprise application in the partner tenant. The user assigned managed identity can be used by any service or application inside the host tenant.

The Graph Enterprise application is created in the partner tenant for the home tenant App registration. This Enterprise application is created for only the home tenant and no other tenant. In the partner tenant, it is also possible to restrict the tenants that can use this.

With this setup, no secret is required to use the guest invite functionality.

Graph App registration on home tenant

For this setup, a multi-tenant App registration is created with the Microsoft Graph Application User.Invite.All permission. A federated credential is created using a user assigned managed identity.

Enterprise app on partner Entra ID tenant

An Enterprise application is created using the App registration on the home tenant. As this is a multi-tenant App registration, it can be created on any tenant. You MUST ensure that you use the correct App registration from your home tenant.

This solutions work good and requires no secret or client certificate. No secret rotation is required. The user assigned managed identity can be used by any service or application on the home tenant. This is used in the federated credential flow to create the cross tenant access token. This is a possible security risk inside the home tenant, especially if multiple applications, services, agents, people with different levels of knowledge are using and accessing the Entra ID tenant.

Alternative solution

A client assertion can also be used instead of a user managed identity. The access to the client certificate is restricted to the Application and stored in an Azure Key vault. The access token can be created or accessed by less services or applications now compared to the user assigned managed identity. The certificate needs to be rotated, managed and deployed. Both App registrations are single tenants in this setup. The Application is hosted in the home tenant, but it can be hosted anywhere.

You can also deploy a key vault and the application to the partner tenant. With this setup, only single tenant app registrations are required and a system assigned managed identity can be used again.

Links

https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-howto-authorize-cross-tenant

Welcome to the first post in my series on getting the most out of GitHub Copilot in the terminal. We'll kick things off with one of the most important things to understand: the different modes Copilot CLI operates in, and when to reach for each one.

A quick intro to GitHub Copilot CLI

GitHub Copilot CLI is a terminal-native coding agent — not just a chat wrapper. It can plan complex tasks, edit files, run tests, and iterate autonomously, all without leaving your terminal. But to get the most out of it, you need to understand how to control how much autonomy you give it at any point in time. That's exactly what the different modes are for.

You cycle through the main modes using Shift+Tab. A mode indicator in the CLI's footer tells you which one you're currently in.

The three main modes

1. Standard Mode — The default

When you launch copilot, you start in standard (interactive) mode. This is the classic back-and-forth: you submit a prompt, Copilot responds or takes an action, and then waits for your next instruction. It will ask for your approval before executing any tool or shell command that requires permission.

This mode gives you the most control and is the right starting point for most tasks — especially exploratory ones where you want to stay hands-on and guide the work step by step.

Best for: open-ended exploration, iterative development, tasks where you want to review each step before moving on.

2. Plan Mode — Think before you build

Press Shift+Tab to cycle into plan mode. Instead of immediately starting to write code or execute commands, Copilot shifts into a collaborative planning phase. It asks you clarifying questions, confirms its understanding of scope and requirements, and builds a structured implementation plan before touching a single file.

Once you've reviewed and approved the plan — which appears in a dedicated panel in the UI — you can tell Copilot to start implementing. You can even hand off directly to autopilot mode from there with "Accept plan and build on autopilot."

Plan mode is particularly valuable for complex, multi-step tasks. Catching a misunderstanding at the planning stage is far cheaper than untangling a half-implemented feature.

Best for: new features, refactors, anything where getting the approach right upfront matters.

Pro tip: If you see that Copilot is going off rails, you can always interrupt and provide some input or feedback. Copilot will pick this up and change the plan accordingly.

3. Autopilot Mode — Hands-off execution

Keep pressing Shift+Tab to reach autopilot mode. In this mode, Copilot works autonomously through a task without pausing for your input at each step. It continues executing — editing files, running commands, calling tools — until it determines the task is complete, hits an error it can't resolve, or you press Ctrl+C to stop it.

Autopilot mode works best with explicit tool permissions. You can launch the CLI with --allow-all to grant full permissions upfront (or through the /allow-all slash command), or use --max-autopilot-continues to cap how many steps the agent can take before stopping — a good safety net for tasks you're less certain about.

Best for: well-defined tasks you trust Copilot to handle end-to-end — writing tests, fixing CI failures, applying a well-understood refactor across multiple files.

Pro tip: Autopilot is not ideal for open-ended or ambiguous tasks. If the goal isn't crystal clear, you risk getting a pile of changes that don't quite hit the mark. Use plan mode first to align on the approach, then hand off to autopilot.

Shell Mode — Bypassing the agent entirely

Shell mode is a bit different from the three above — it's not part of the Shift+Tab cycle. Instead, you access it by prefixing any prompt with !. This executes the command directly in your shell without making a call to the model at all.

! git status
! npm test
! ls -la src/

This is handy when you're mid-conversation with Copilot and want to quickly check something in your environment — run a test, inspect a file, check git status — without starting a new terminal or breaking your flow. Think of it as a built-in escape hatch to your shell.

Best for: quick environment checks, running commands mid-session, avoiding context switches to another terminal window.

Pro tip: Shell mode history navigation filters by prefix. Type !git and press the up arrow, and you'll cycle only through previous git commands — making it fast to find and reuse recent shell commands.

Putting it all together

A natural workflow for bigger tasks looks like this: start in plan mode to get aligned on the approach, then Shift+Tab through to autopilot to let Copilot run with it. Drop back into standard mode when you want to steer in real time, and use shell mode whenever you need to quickly check something in your environment without breaking your flow.

Wrapping up

Understanding these modes is the foundation for using Copilot CLI effectively. The right mode at the right time means you stay in control without becoming a bottleneck in your own workflow.

In the next post, we'll look at session management.

More information

GitHub Copilot CLI - GitHub Docs

Allowing GitHub Copilot CLI to work autonomously - GitHub Docs

Autopilot & Plan Modes | github/copilot-cli | DeepWiki