Scaling your Power Platform usage is a good problem to have. It means your teams are building, automating, and delivering value.  

But unchecked growth comes with hidden costs. As Microsoft evolves its licensing models, small missteps can snowball into big expenses.

In this blog post, we discuss how to scale in a sustainable way, design cost-aware apps, and stay in control as pricing and features shift. Whether you’re running a Center of Excellence or simply supporting teams building apps, the goal is the same: grow smart, without overspending.

This is the fifth part of our Power Platform licensing series. In our previous articles, we covered

• Microsoft Power Platform licensing changes in 2025 and how they affect users,

• Power Platform Licensing Within M365 & D365 and what bundled access actually includes

• Standard vs. Premium Connectors in Power Platform and how to stay ahead of changes

• Request management in Power Platform and how to stay within limits and budget

Stay informed: Monitoring licensing and usage

One of the most important habits you can build is regular visibility into what you’re using and what it costs. Microsoft licensing isn’t static — new SKUs are introduced, entitlements change, and API pricing evolves behind the scenes. If you’re not watching, you’ll miss the early signs of budget creep.

Start by subscribing to Microsoft’s release notes and licensing update blogs. These updates often include connector reclassifications or entitlement adjustments that can quietly impact your costs. Set internal reminders to review licensing guidance at least once per quarter.

On the internal side, the Power Platform Admin Center provides recent usage data to help you:

• Track how many users are actively using licensed features

• Identify which apps or flows are consuming the most requests

• Flag spikes in usage that could trigger overages

While Azure Monitor doesn’t directly track Power Platform request usage, it can complement your monitoring strategy by alerting on related Azure services, such as API Management or custom connectors, based on available metrics and logs.

This isn’t just about control, but also about building confidence that your investments are being used effectively.

Build apps with the future in mind

Great app design doesn’t just improve performance, it also reduces risk when licensing rules change.

When building or reviewing solutions, favour modular architecture. Why?  

Modular apps are easier to adapt if Microsoft reclassifies a connector or changes how a feature is billed. For example, separating a high-volume automation into its own flow makes it easier to isolate and scale independently.

Be strategic about Premium connector usage. If your team already relies on connectors like Dataverse, SQL Server, or custom APIs, continue using them where they add value. But if you're considering Premium for the first time, evaluate whether the business impact justifies the added cost. Either way, design flows to avoid unnecessary steps or repetitive API calls that can drive up request consumption.

As part of your development standards, document each app’s licensing and connector dependencies. When it comes time to upgrade, scale, or refactor, this documentation will save time and prevent guesswork. If you're using the Center of Excellence Starter Kit, it automatically tracks which connectors each app and flow uses — and whether they’re Standard or Premium.

Run regular health checks for smarter spending

Apps and flows don’t stay static and neither should your approach to managing them.

Establish a regular cadence for cost and usage audits. Monthly or quarterly reviews can reveal:

• Licensed apps that haven’t been used in months (“zombie apps”)

• Flows that run frequently but no longer serve a real purpose

• License assignments that don’t match actual user activity

You’ll also want to conduct scaling impact reviews. What happens if app usage doubles next month? Or a department adopts Power Platform for the first time? Use Microsoft’s licensing calculators and cost simulators to predict these shifts before they happen. A little forecasting now can save you a budget surprise later.

Avoid lock-in while leveraging the ecosystem

When scaling on Power Platform, it’s tempting to take full advantage of every integration and customisation feature available. That’s the power of the platform, but it can also create hidden long-term costs.

There’s a difference between vendor alignment and vendor lock-in.

Alignment means taking advantage of Microsoft-native tools like Dataverse, Teams, and Azure for greater cohesion. Lock-in happens when your solution becomes so custom that migrating or adjusting becomes painful or expensive.

Whenever possible, keep business logic inside Power Platform, but design your data to be portable. Avoid overly rigid dependencies on proprietary formats or niche connectors unless they’re business critical.

Audit the tools you’re already paying for

Another source of cost creep is tool redundancy. Teams often spin up new software without realising that the same functionality exists within the Power Platform or adjacent Microsoft 365 tools.

Make it part of your governance model to review the full ecosystem regularly. Ask:

• Are multiple analytics tools in use across the same team (e.g., Power BI and Tableau)?

• Are there legacy tools still active despite being replaced by Power Apps or Automate?

• Are business units buying new solutions instead of using licensed ones already available?

Encourage teams to maximise existing investments before expanding into new tools.

Assign ownership to stay ahead

One of the most effective things you can do to control costs is assign a cost and usage owner. Without clear ownership, monitoring tends to fall through the cracks, especially when budgets are shared across departments.

This person (or small team) doesn’t need to manage licenses day-to-day. But they should be responsible for:

• Tracking usage trends

• Monitoring request volumes and license consumption

• Preparing quarterly usage reports

• Advising on renewals, upgrades, or plan changes

Proactive cost management is only possible when someone is paying attention to the right data at the right time.

Final thoughts: Maximise value without overspending

Scaling Power Platform doesn’t have to mean growing your budget at the same pace. With the right practices in place, you can expand your impact while keeping costs predictable and controlled.

Keep these principles in mind:

• Monitor usage regularly and stay up to date with licensing changes

• Design apps with flexibility and long-term efficiency in mind

• Assign ownership so cost and usage insights turn into action

Smart scaling isn’t just about handling growth, it’s about making every cent you spend work harder.

We hope you’ve found our series on Microsoft Power Platform licensing helpful.

Looking to scale your Power Platform usage without overspending? Contact us to discuss your use case.

‍

If your apps or flows have ever stopped working without warning, there’s a good chance request limits were the culprit.

In Power Platform, every time a user saves a record, triggers a flow, or calls a connector, it counts as a request. Individually, these seem small. But as usage grows, so does the number of requests, and eventually, you’ll hit your limit.

As a result, bandwidth control kicks in, you get notified of failed runs or denied access that seem to come out of nowhere. And once again, it’s up to the operations team to figure out what happened and how to fix it.

In this post we’ll look at how request limits work in 2025, how Microsoft enforces them, and most importantly, how your team can stay compliant.

This is the fourth part of our Power Platform licensing series. In our previous articles, we covered

• Microsoft Power Platform licensing changes in 2025 and how they affect users,

• Power Platform Licensing Within M365 & D365 and what bundled access actually includes

• Standard vs. Premium Connectors in Power Platform and how to stay ahead of changes

Why request limits in Power Platform shouldn’t be taken lightly

In early versions of Power Platform, request limits were often overlooked. Enforcement was loose, and most apps never came close to hitting the thresholds.

That’s changed. Microsoft now treats request usage as a core part of license entitlement.  

Every license type includes a defined number of daily requests per user or flow, and enforcement is no longer optional. Whether you’re using Power Apps, Power Automate, or Dataverse, request volumes are tracked, monitored, and capped.

How Microsoft measures requests in 2025

Every interaction with the platform counts as a request. That includes:

• Saving or retrieving data from Dataverse, or any other data source

• Calling connectors (Standard or Premium)

• Each action step (which goes outside of your Power Automate) while running flows

• Triggering plug-ins or custom APIs

• Even system-level operations like lookups and validation

Microsoft provides a detailed breakdown of request capacity by license type. For example, users with a Power Apps Per User plan get a higher daily request limit than those using a Microsoft 365 license with Power Apps access. Background flows, unattended automation, and service accounts with Per Flow licenses have their own request pools.

What’s new in 2025 is how Microsoft surfaces this information

The Power Platform Admin Center now allows you to see request usage per user, environment, and app, but it takes a few steps to find the data. To check your request allocation, follow these steps:

1. Log in to the Power Platform Admin Center.

2. Navigate to the "Capacity" section in the left-hand navigation pane.

3. On the summary tab, look for the option to download reports (often found in an "Add-ons" or similar section).

4. Select "Download reports" and choose the type of report you want, such as "Microsoft Power Platform Requests."

5. Choose the scope for your report (e.g., Licensed User, Non-Licensed User, or Per Flow Licensed Flows).

6. Submit and download the report to view detailed usage data for each user or flow, including how many requests have been consumed.

You can also use Azure Monitor to set up alerts, but it does not natively track or alert on Power Platform request usage or allocation from the Power Platform Admin Center. Instead, it’s primarily built for observing Azure-native resources, such as virtual machines, databases, and Azure API Management, and can trigger alerts based on metrics or logs collected from those services.

What happens when you hit the limit

Request limits aren’t just theoretical. When usage exceeds your allocated capacity, Microsoft enforces throttling. Depending on the service and workload, this can mean:

• Flows that fail to trigger or complete

• Delays in data syncing or processing

• Errors when users try to save or update records

These disruptions can affect frontline business processes, like approvals, customer onboarding, or field updates, leaving teams confused about why things broke.

Most throttling surprises happen because teams aren’t actively tracking request consumption until it’s too late. To make matters worse, there's rarely a visible warning for end users. They just see errors. By the time IT gets involved, the platform may have already been throttled for hours.

How to manage requests proactively

The best way to manage request limits is to stop thinking of them as an afterthought. Request planning needs to be part of your architecture discussions from day one. Start by understanding your baseline. Use the Admin Center’s analytics to monitor which apps and flows are consuming the most requests.  

Look for patterns: Is usage spiking during certain times of day? Are a few apps responsible for the majority of consumption?

Once you have visibility, you can make smarter decisions, such as:

• Refactoring flows to reduce unnecessary steps or loops

• Offloading complex logic to Azure functions or other services where appropriate

• Consolidating data calls to reduce repetition

You don’t need to over-optimise from the start. But you do need to understand where your limits are and have a plan for what happens when you approach them.

How to plan for scale

As adoption grows, request volumes will too. But without a scaling strategy, your success can start to work against you, pushing you past request limits.

Microsoft offers a few options for scaling request capacity:

• Per App and Per User licenses each include defined request limits

• Pay-As-You-Go plans allow flexible scaling, with request overages billed through Azure

• Add-on request packs allow organisations purchase extra capacity without changing license types  

The right option depends on your usage profile. High-volume solutions used by a small group may benefit from Pay-As-You-Go. Department-wide apps might justify more robust licensing.  

(Note: Currently all organisations are in transition period with higher request limits. The transition period ends after Power Platform Admin Center reports are generally available. Organisations then have six months to analyse their usage and purchase licenses that are appropriate before strict enforcement on license limits begins. More info here.)

Don’t let service accounts become bottlenecks

A common pain point for many teams is the use of service accounts or shared automation users. These accounts often own high-volume flows or integrations, but they come with a fixed request limit, just like any other user.

When you hit those limits, automation fails, even if every individual user is well within their allowance.

The solution is to assign Per-Flow licenses to critical service flows. This plan reserves dedicated capacity for each licensed flow, regardless of who owns or triggers it, and does not consume from the tenant’s non-licensed user request limits.

It’s also a best practice for long-term maintainability, as it decouples business logic from individual users and ensures key automations remain stable over time.

Make request management part of governance

If you’re running a Center of Excellence or managing a large Power Platform deployment, request limits need to be part of your governance model.

That means:

• Including request tracking in solution review checklists

• Training makers to understand how their design choices affect request usage

• Defining escalation paths for throttling issues

• Monitoring usage trends and forecasting future needs

Build smart, scale smoothly

Request limits aren’t just technical constraints. They’re signals that your platform usage is growing and needs more intentional design. By understanding how requests work, monitoring them proactively, and scaling smartly, you can keep apps running smoothly and avoid the surprise of throttling.

Not sure what the right licensing setup is for you? Contact us to discuss your use case.

Up next in this series:

• Smarter spending with Power Platform — Managing costs for future scaling

‍

Why is understanding connectors critical?

Connectors are the silent enablers of every Power Platform solution. Whether you're automating approvals, syncing customer records, or generating reports, connectors are doing the heavy lifting in the background.

But here’s the catch: Not all connectors are created equal, and not all are included in your M365 license.

Understanding how your connector is licensed isn’t just a technical detail. It affects:

• Your cost model

• Your app’s scalability and maintainability

• And your ability to respond to Microsoft’s evolving licensing rules

If you don’t understand the connector landscape, you’re building on shaky ground. This blog post helps IT operations teams, platform admins, and Center of Excellence leaders make smart, future-proof decisions about connector use.  

This is the fourth part of our Power Platform licensing series. In our previous articles, we covered

• Microsoft Power Platform licensing changes in 2025 and how they affect users,

• Power Platform Licensing Within M365 & D365 and what bundled access actually includes

Standard vs. Premium connectors: What’s the difference and why does it matter?

Microsoft splits connectors into two main categories: Standard and Premium. Custom Connectors fall under Premium too. If neither Microsoft, a third party, nor the community has built a connector for your specific system, you can create your own to tailor integrations to your exact needs.  

Understanding the difference between Standard and Premium is critical to staying compliant and budgeting correctly. The type of connector you use directly impacts your licensing model. You might start with a simple app that uses SharePoint and suddenly need a premium licence just because you added a single connection to Dataverse or SQL Server.

Here’s what you need to know:

Standard connectors

These are included with most Microsoft 365 licenses and cover tools your team likely already uses:

• SharePoint

• Outlook

• Excel Online

• OneDrive

• Planner

Great for: internal, low-complexity apps that don’t require external system integration.

Premium connectors

These require additional licensing, either via Per App, Per User, or Pay-As-You-Go plans.

Examples include:

• Dataverse

• SQL Server

• Salesforce

• SAP

• HTTP, Azure DevOps, ServiceNow

Great for: unlocking richer integrations but come with licensing implications.  

Keep in mind that even a single Premium connector will upgrade the entire app’s license requirement.

Why this matters

Connector classifications aren’t static. We’ve seen connectors reclassified from Standard to Premium, but these changes are typically announced in advance, giving teams time to prepare.

Keep in mind that Premium connectors can significantly alter your app’s costs. Adding just one can shift a solution from being covered under a Microsoft 365 license to requiring a Premium license for every user.

Real-life example: The SQL connector shift

The SQL Server connector was originally classified as Standard, making it a go-to choice for internal apps connecting to on-prem databases or Azure SQL. Teams across industries built solutions under the assumption that they were operating within the boundaries of their Microsoft 365 licenses.

Then came the change. Microsoft reclassified the SQL connector as Premium. This meant that the connector that powered dozens of reliable business apps was no longer included in base licensing.  

Apps that had been running smoothly now required Power Apps Premium licenses or a Pay-As-You-Go model to stay compliant. IT teams scrambled to re-architect solutions, request unplanned budget approvals, or freeze deployments altogether.

The SQL connector shift is a reminder that connector classifications aren’t set in stone, and that licensing assumptions can quickly become liabilities.

Lessons learned

Don’t assume a connector’s classification is permanent. Instead, design apps with licensing flexibility in mind, avoiding hardcoded architectural decisions that rely solely on current connector classifications.

Microsoft is getting better at communicating connector changes, but surprises still happen

To their credit, Microsoft has made real progress in making things clearer:

• It’s now easier to find out which connectors are Standard vs. Premium in the official docs.

• Release Wave updates highlight what’s changing before it happens.

• Admin Center and Message Center posts give early warnings so you can plan ahead.

But there’s still a lag between policy updates and their impact in real-world apps. And some changes appear with little to no warning, especially for lesser-known connectors or third-party services.

What to keep in mind:

• Always double-check connector classification before starting a project, not just before deployment.

• Previously free connectors can be reclassified.

• New connectors may launch as Premium from day one.
  

How to manage connector risk proactively

If you're running a Power Platform environment at scale, connector governance is just as important as app governance.

Here’s how to get ahead of it:

1. Maintain an internal approved connector list

Track which connectors are Standard vs Premium, add usage notes, and include business owners for accountability.

2. Start with Standard connectors, upgrade to Premium when it’s necessary or adds value

Default to Standard connectors to control costs and streamline deployment. But don’t rule out Premium connectors as they can unlock valuable functionality. The key is alignment: choose Premium only when those extra features directly support your use case.

3. Monitor for classification changes

Set alerts from Microsoft’s Message Center and make sure someone regularly reviews Release Wave updates. Connector statuses can change.

4. Regularly audit apps

Identify apps using Premium connectors and regularly check whether the current licences still fit. Flag anything at risk if classifications shift again.

5. Educate makers

Many citizen developers don’t realise that using just one Premium connector upgrades the licence requirement for everyone. Share clear internal guidelines from the start.

Bonus tip: Don’t forget connectors in flows

It’s easy to focus on connectors in Power Apps, but don’t overlook Power Automate.

Flows using Premium connectors (e.g., Dataverse, SQL, custom APIs) follow the same licensing rules. If a flow triggers via a Premium connector, the user (or the flow owner) must have the proper license. This is one of the most common compliance gaps we see in audits.

Smart connector choices = Long-term app stability

Choosing connectors isn’t just about capability, but about sustainability too. You need to know exactly what you’re using, design apps that can adapt if licensing changes, and validate connector classifications early and often. This approach helps you build apps that are scalable, cost-effective, and resilient to change.  

If you’re not sure which license setup is best for your team, contact us to discuss your use case.

Up next in this series:

• Request management made easy — Staying within limits and budget

• Smarter spending with Power Platform — Managing costs for future scaling

‍

“I thought this was included with Dynamics 365. Why are we getting license errors?”

If you’re responsible for automating team processes, like building flows, setting up approvals, managing request, you’ve probably heard this more than once. Maybe you’ve said it yourself.

Let’s say you rolled out a Power App to streamline onboarding. It’s using SharePoint, Outlook, maybe even Teams. No problem so far. But the moment someone adds a Dataverse table or a Power Automate flow that hits a SQL database? It suddenly prompts you to start a trial or upgrade to a premium license. Now you’re faced with licensing decisions.

This confusion is one of the most common traps for operations teams using Power Platform in Microsoft 365 or Dynamics 365 environments. The tools look free. The makers assume they’re included. But under the hood? It’s more complicated.

This is the second part of our Power Platform licensing series. In our previous article, we covered Microsoft Power Platform licensing changes in 2025 and how they affect users.

Which Power Platform features are included in M365 and D365?

Bundled access comes with hidden limits. Let’s break it down.

M365: Good for standard connectors, but that’s it

Microsoft 365 plans (like E3 or E5) include:

• Power Apps with standard connectors (SharePoint, Excel, Outlook, and many more)

• Power Automate with standard connectors (triggers and actions)

• Canvas apps embedded in Teams
  ‍

But the moment your app or flow uses:

• Premium connectors (like SQL, Dataverse, Salesforce, or custom APIs)

• Model-driven apps with richer logic and relational data

• Standalone Power Apps portals (now Power Pages)

• AI capabilities or Copilot integrations

…you’ve left the “free with M365” zone. Even read-only access to premium data still requires a premium license — a common oversight that leads to compliance issues.

D365: More power, but only for licensed users — and only for the specific app

Dynamics 365 plans (like Sales, Customer Service, or Field Service) come with broader Power Platform entitlements — but there are two strict boundaries:

• Only licensed D365 users get the extra capabilities

• Only for scenarios tied to their specific D365 app
  ‍

So, if someone with a Dynamics 365 Sales license builds a Power Automate flow that connects SharePoint and Dataverse for a sales process?
Covered.

But if a non-Sales user tries to use that same app or flow?
They’ll need their own premium license.

And if the Sales-licensed user builds an app or flow for HR, Finance, or Operations?
That falls outside the licensed scope — even if it uses the same Power Platform components — and may not be compliant.

Bottom line: D365 licensing is generous within the app boundary, but it doesn’t transfer across departments, scenarios, or users.

Are hidden assumptions breaking your automations?

Let’s say your team builds a Power Automate flow to route vacation approvals. It uses SharePoint and Outlook, so you assume it’s covered under your M365 license.

But then someone quietly adds a premium connector to Entra ID or Dataverse. Nobody flags it. The flow still works, more or less. Then you start seeing:

• Flow throttling

• Unexpected errors

• Sudden license warnings
  ‍

Admins are confused. Users are frustrated. And now you’re chasing down compliance gaps and trying to keep things running, instead of focusing on scaling meaningful work.

This is the risk of assumptions. Power Platform doesn't always block you upfront — it lets you build and run… until usage crosses an invisible line.

Does usage mean you're licensed?

Here’s the tricky part: Just because something runs doesn’t mean it’s licensed.

Power Platform often doesn’t block you at the start. Apps and flows may run smoothly at first. But that doesn’t mean you’re in the clear.

Problems tend to appear later, when:

• A new enforcement rule quietly kicks in

• A background API call exceeds your entitlements

• A usage audit flags non-compliance
  ‍

And by then, it's not just a licensing problem. It’s a business disruption.

If you're not proactively monitoring usage against entitlements, you're one policy change away from broken automation and user downtime.

How to stay in control before Microsoft starts monitoring your team

If you’re not monitoring entitlements proactively, you’re not in control — Microsoft is.

If you want to avoid surprises, you need a licensing-aware automation strategy. Here’s how:

1. Know what’s “premium”

Keep a cheat sheet of premium connectors, features, and app types. Share it with your makers and approvers so they understand when they’re entering license territory.

2. Map users to roles and needs

Who’s building? Who’s consuming? What data sources are in play? Don’t assign licenses blindly. Align them with usage patterns.

3. Monitor usage centrally

Use these tools to track and stay ahead:

• Power Platform Admin Center
  See request volumes, connector usage, and license assignment gaps across environments.

• Azure Monitor (optional)
  Set alerts when flows near usage limits or exceed thresholds — useful for high-scale environments.

4. Watch for “inherited” access

Just because someone is part of a Teams channel or D365 group doesn’t mean they’re licensed for the app or flow embedded there. Shared access ≠ shared entitlement.

Don’t assume, assess

If you’re building automation at scale, especially in hybrid M365 + D365 environments, licensing can’t be an afterthought.

• M365 gives you the basics but not the premium connectors most real-world apps need.

• D365 licenses go deeper but only within narrow boundaries.

• And enforcement is now active and automated.
  ‍

So, if you want to keep building without friction, make license visibility part of your ops playbook. Stay ahead of usage, keep your team up-to-date, and model costs before they spiral.
‍

If you’re not sure which license is best for your team, contact us to discuss your use cases.

Up next in our Power Platform licensing series:

• Staying ahead of connector changes in Power Platform

• Request management made easy: Staying within limits and budget

• Smarter spending in Power Platform — Managing costs for future scaling

‍

Imagine describing an app you need in your own words and getting a basic app framework in minutes. With Plan Designer in Power Apps, that’s already becoming possible.

What is the Plan Designer?

Plan Designer is a new Copilot experience within Power Apps. It allows users to describe their app in natural language and receive a structured starting point.  

This move is part of Microsoft’s broader move to bring generative AI into everyday business tools. While it doesn't yet deliver complete or production-ready applications, it offers a strong foundation that helps teams move faster, validate ideas earlier, and collaborate more effectively with dev teams when it’s time to build.

Important to know: It’s still in preview

Plan Designer is currently available as a public preview feature. That means it’s not production-ready yet, and it’s not recommended for complex or business-critical use cases.

It’s a promising direction, and there are many more improvements in the pipeline. But for now, think of it as a way to jumpstart your ideas, not as a full replacement for expert-built solutions. Let’s see how:  

From idea to app structure, without coding

Some of the best ideas for internal apps come from the people who work closest to the process.  

You’ve likely experienced it yourself: you know exactly what your team needs, whether it’s a simple PTO planning tool or a way to track field tasks. You understand the workflow, the challenges, and the users. But when it comes to turning that insight into a working app, you’re not sure how to get started.

That’s been the reality for many business users.

Historically, PowerApps has been aimed at non-developers, people in HR, customer service, field operations, and sales. These users know their business inside and out but often lack the technical or systems thinking skills to design a well-structured, scalable app. As a result, many apps were either overly simple or hard to maintain and improve.

That’s where Plan Designer comes in.

It offers a more guided way to get started. Instead of starting from scratch, you describe what you need in natural language, for example, “I need a tool to assign jobs to field technicians.” You can even upload visuals, like a screenshot of an old tool or a process diagram.  

Based on your input, Copilot generates a structured draft of your app.  

What you get is a smart skeleton, with suggested tables, screens, user roles, and basic logic. It proposes a data model and automation ideas using Power Automate, all based on what your prompts. You can then review, adjust, or approve what Copilot gives you before it builds out the logic.

It won’t give you a finished app, but it gives you a strong starting point, one that reflects your intent and helps you think through how your app should be structured. That’s a big step forward for anyone who understands the business problem but not the development process.

What can you currently do with Plan Designer?

To access the Plan Designer, you need a preview environment with early feature access enabled. Once set up, you can start designing solutions directly from the Power Apps homepage by toggling on the new experience.

It’s still the early days, so it’s important to set the right expectations. As of April 2025, Plan Designer has the following capabilities:  

Natural language input

Based on natural language input, the Plan Designer will generate a solution tailored to your needs. This includes creating user roles, user stories, and data schemas.

Solution generation

The tool can create basic end-to-end solutions, including:

• Dataverse tables

• Canvas apps

• Model-driven apps

Iterative development

You can refine your plans by providing feedback during the design process to make sure that the generated solution aligns with your specific needs.

Collaboration and documentation

The generated plan serves as both a blueprint for development and documentation for future reference to help teams align on business goals and technical execution.

Integration with Power Platform tools

While still in preview, the tool integrates with other Power Platform components like Dataverse and Power Apps. However, some features (e.g., Power Pages support and advanced data modeling) are not yet available.

Limitations in the preview

The tool currently does not support generating full Power Automate flows or using common data model tables like accounts or contacts. Features like analytics integration, Azure DevOps compatibility, and document uploads (e.g., RFPs) are not yet implemented.

The feature set is evolving rapidly, with updates rolling out every few days. One recent improvement: Copilot now explains which AI agents are working on different tasks, for example, the requirement agent, data agent, or solution agent.

‍

To sum up, Plan Designer helps you get the core pieces in place in just a few minutes. It’s especially useful for:

• Prototyping apps without waiting for a developer

• Practicing prompt-writing to refine app design

• Getting a better understanding of how systems and logic fit together

It’s great for playing around, testing out concepts, and learning how to approach app development with systems thinking. Let’s see how this might change in the coming years.  

How you’ll use Plan Designer in the near future

Let’s say there’s a process in your team that’s manual, slow, or inconsistent, and you know exactly how it should work. Maybe it’s tracking field work, collecting customer data, or planning PTO.  

You have the knowledge to solve it. What you don’t always have is the time, tools, or technical background to build the solution yourself.

That’s where Plan designer is moving toward. It will help you translate your ideas into something concrete: a data model, screens, and suggested relationships. It will give you a head start, so you won’t have to start from scratch.

Here’s what that might look like in practice:

• You’re a field manager who needs to track technician assignments and jobs.

You describe your idea to Copilot, and it creates basic tables like “Jobs” and “Technicians,” with suggested relationships between them. The logic and visuals still need work, but you now have a structure to build on.

Looking for inspiration to improve efficiency in Field Service? Check out our use cases here.

• You’re in sales and want to explore upsell recommendations for client visits.

Copilot sets up a rough draft with placeholders for customer info and past purchases. It doesn’t connect to CRM data yet, but it helps you map out the concept before looping in technical teams.

• You’re on a support team and want to build a customer intake form.

You describe the form and basic routing needs, and Copilot creates a simple layout with suggested fields and logic. You’ll need to tweak it, but it’s a much faster way to get started.

While these examples are simple, they give you an idea of where things are heading. Plan Designer isn't here to replace software engineers but to allow business teams to move faster and speak the same language as your dev team.

Turning your starting point into a real solution

At VisualLabs, we follow every development in the Microsoft ecosystem closely and we’re excited about Plan Designer’s progress. It’s already a powerful tool for creating skeleton apps, exploring ideas, and learning how data models and logic come together.

But when you need more than just a starting point, when performance, integration, scalability, and usability matter, our team is here to help. We bring the expertise to take your idea and turn it into a reliable, well-designed app that fits your organisation’s needs.

AI is changing how we build apps, but human insight still makes the difference.  

Interested in what use cases our customers are prioritising? Check out our case studies here.

‍

‍

I first joined VisualLabs in the summer of 2020 as a junior business analyst. As you can see from the timeline, I was part of the mass junior recruitment. With three of us, the company grew to 8 people at that time.

‍

In the more than 1 year I worked here from 2020-2021, I was involved in quite a variety of tasks: building and improving Power BI reports, working a lot on a contract management application I built using the Power Platform, and also gaining insight into the beauty of Business Central. The latter also gave rise to some comical memories, such as the painstaking work involved in recording and subtitling training videos for clients, and how I was then, as an undergraduate student, on 'duty' for Christmas because I had no more holidays left for the year. But I got a lot of support from my senior colleagues in these things, they didn't let me get lost in the shuffle.

3 years later, in the summer of 2024, I rejoined VL, but now I work specifically with ERP. One thing that was very nice and new to me in the company was the company timeline. Where last time I was one of the mass junior hires, I'm now a part of the company life.

‍

An amazing amount has happened in my time away, and it's great to see these events being shared by my colleagues, creating a stronger sense of belonging.

What has actually changed in these 3 years? I haven't had the chance to go through everything since I rejoined, and there's not enough space to go into it all here, so I'll just give you a few snippets.

Office

The first of these is probably the new office: the move from Zsigmond Square to Montevideo Street was already done when I was still here as a junior. But who I couldn't enjoy it then, and I wasn't part of the "moving in", but still, when I returned here 3 years later, I felt like I had shaped it. Interpret this to mean that the ethos that makes visuallabs to visuallabs, I think, changed very little, and the homeliness of the office reflected that.

Specialisation

The company has made huge progress in terms of specialisation and staff numbers while I was away: the team has grown to 35 people, and there are now separate business units for all the tasks I had the opportunity to join on a rotational basis as a junior. These are the CE team, who build business applications for clients, the data team, who deliver data analytics and visualisation solutions, and there's the ERP team - of which I became part - where we introduce Microsoft's enterprise management solutions (Dynamics 365 Finance and Operations and Business Central) to clients.What I would perhaps highlight from this is that even though these specialisations have evolved, it has not brought with it a siloed operation. To deliver work in our own area, we have access to the knowledge of other areas, and we mutually help each other across teams to deliver the highest quality service possible. From this perspective, what has changed in 3 years? I would say nothing; what worked then on a small scale, works now on a bigger scale.

Agile operation

We have had a solid vision of how we deliver solutions since I was a junior employee here: the agile methodology. What was in its infancy is now mature. If not fully agile, it uses the agile elements so well that it supports our work to a great extent on a day-to-day basis.It helps us communicate internally and to our customers by allowing them to post issues in DevOps that we help them resolve; we write features, user stories, test cases that help us with needs assessment and implementation. We have daily stand-up meetings with the team in the mornings where we discuss our stumbling blocks, at the end of the week we have sprint rounds where we always plan the next week's sprint, and monthly we have a retros where we pay special attention to feedback to each other, looking back on the past 1 month.

Team and all the fun

Unfortunately, during my first job, I didn't get much of that live because of Covid, but even then I had those short conversations at the beginning of a call or at the morning "all-people" DSMs that reinforced the sense of belonging to the team and the good atmosphere. Fortunately, we have kept this habit ever since, so no call is ever dull. And once the epidemic subsided, these community events only grew stronger, with regular team-building events, VL team-building retreats, co-hosted Christmas and Halloween parties.It's also a good day at the office. Although it varies from day to day, we have little rituals that colour the days and take the focus off work. For example, the daily lunch together in the office, chit-chat while making coffee, or just passing a funny comment to each other at the next desk, or the monthly office day when we all go in and look back over the past month. In short, you never get bored here. 😊

Coming back to a place where I've worked before is a special experience - especially when so much has changed in the meantime. VisualLabs has retained the supportive community and vibrancy that I grew to love, while reaching new levels of development and professionalism. This journey has been a learning experience not only for the company, but also for me, as the old and new experiences have given me a stronger, more mature perspective. I look forward to being a part of the next chapter and seeing where the company goes in the future!