Insights & ideas

TL;DR

90% of organisations aren’t ready for agentic AI because their people, processes, and technology are still fragmented. Before building copilots or custom agents, companies must become data-first organisations: establishing strong governance, integrating foundational systems, and replacing manual processes with structured, interconnected workflows. With agentic blueprints and a proven methodology grounded in value, architecture, and design patterns, Microsoft-centric organisations can gain AI value faster and more safely.

90% of organisations aren’t AI-ready. Are you?

Everyone is talking about AI agents — or copilots — that summarise meetings, answer questions, trigger workflows, and automate the routine.

Most organisations believe they’re “ready for AI” because they use ChatGPT or Copilot. But agentic AI only becomes valuable when the foundations are in place — governed data, consistent processes, and interconnected systems.

In reality, around 90% of organisations aren’t there yet. Their data lives in silos, processes run on spreadsheets, and collaboration happens in unstructured ways that AI cannot interpret.

So before you rush to “add AI,” stop for a moment. Is your organisation truly ready for an agentic AI strategy, or are you still running on Excel?

From automation to augmentation

Many companies start here: Sales teams track opportunities in Excel. Documents live in personal folders. Collaboration happens over email or private Teams chats.

It works until it doesn’t. Because when you ask, “Can we plug AI into this?” the answer depends entirely on how your work is structured.

For AI to deliver value, your processes and data need to be consistent and governed. If information sits in silos or moves around without clear ownership, no Copilot will sort it out for you.

Step 0: Look at how you work

AI can only operate within the workspace it lives in. Before talking about technology, ask a simple question: How does your team actually get work done every day?

• Where do we keep track of our work, such as opportunities, sales/purchase orders, contacts, customers, and contracts?

• Who updates them?

• How are documents stored, shared, and versioned?

If the answer includes “Excel,” “someone keeps a list,” or any other manual step, that’s not AI-ready. Manual tracking makes automation impossible and governance invisible.

When we assess readiness, we start by examining your value patterns: how your teams create value across people, process, and technology. These patterns reveal which activities need to be structured into systems that log every action consistently. Only then can an agent analyse, predict, and assist.

Microsoft’s modern workspace is AI-ready by default

Microsoft’s modern workspace, including SharePoint, Teams, Loop, Dataverse, and Copilot, is already agent-ready by design.

Chat, files, and meeting notes create structured, secure data in the cloud. When your team works in this environment, an AI agent can see what’s happening, and safely answer questions like:

• “What was decided in the last project meeting?”

• “Show me invoices from vendors in Q3.”

• “Which opportunities need follow-up this week?”

With even basic tools, you can achieve impressive results. A simple SharePoint automation can pull in invoices, let AI read and structure them into columns (supplier, invoice number, amount), and feed the data into Power BI, all in an afternoon.

Step 1: governance first, AI second

When someone logs into Copilot and asks a question, Copilot will find everything they can access. That’s both the promise and the risk, without strong data loss prevention, AI may surface information you never intended to expose.

This is why governance is the first pillar of any AI readiness strategy, and it’s the foundation of our value–architecture–design pattern methodology. Without clear ownership, access, and data controls, no agent can operate safely.

When we run readiness audits, the first questions aren’t about models or copilots — they’re about access and accountability:

• Who owns each SharePoint site?

• Who has edit rights?

• Is sensitive data over-shared across Teams?

• What happens if a site owner leaves the company?

The good news is that Microsoft’s audit tools automatically flag ownership gaps, oversharing, and risky access patterns so you can act before an AI ever touches the data.

Step 2: structure your business data

Even with strong governance, your data still needs structure. AI can read unstructured notes and spreadsheets, but it can’t extract meaningful insights without a consistent data model.

This is where Microsoft's data ecosystem helps. Their tools connect sales, service, finance, and other processes into a single, governed data layer. Every record — contact, invoice, opportunity — sits in one place with shared logic.

Structuring business data turns your architecture patterns into reality. When CRM, ERP, SharePoint, and collaboration systems are interconnected, you create the unified backbone that agentic workflows rely on.

And that’s where agentic AI truly begins. You can build agents that review opportunities, identify risks, and recommend next steps based on the clean, consistent data flowing through Microsoft 365.

Step 3: from readiness to reality

Once the foundation is solid, the strategy becomes clear:

1. Audit your workspace and permissions.

2. Standardise how data is collected and stored.

3. Govern collaboration and access through Teams and SharePoint admins.

4. Enable your first agent — a Copilot, chatbot, or custom agent using Copilot Studio — to assist in everyday processes.

From there, you can start to ask more ambitious questions:

• Which of our processes could an agent safely automate?

• How do we combine Copilot with custom workflows to handle domain-specific tasks?

• What guardrails do we need so that AI doesn’t just act, but acts responsibly?
  

You also don’t have to start from scratch. Our proprietary baseline agents for Microsoft ecosystems cover common enterprise scenarios and act as accelerators, reducing implementation time and giving you a proven foundation to tailor AI behaviour to your organisation.

Want to learn more? Come to our free webinar.

The right question isn’t “how fast”, it’s “how ready”

Every organisation wants to move fast on AI. But the real differentiator isn’t how early you adopt, it’s how prepared you are when you do.

For small teams, AI readiness can be achieved in weeks. For large, established enterprises, it’s a transformation touching governance, data models, core systems and ways of working.

So before asking “How soon can we deploy an agent?” ask instead:

• “Would our current systems help or confuse the AI?”

• “Can we trust the AI to find, but not expose our data?”

• “Do our people know how to work with agents, not against them?”

That’s what an agentic AI strategy really is. Not just technology, but the deliberate design of trust, control, and collaboration between humans and AI.

Before you deploy agents, build the trust they need to work

AI adoption is no longer about experimentation. It’s about building the right foundations —  governance, structure, and readiness — so your first agents don’t just answer questions, but deliver real, secure value.

Agentic AI starts with readiness. Once your systems, data, and people are ready, intelligence follows naturally.

We help Microsoft-centric organisations move from AI-curiosity to real impact, creating environments where AI agents can operate safely, efficiently, and intelligent.

Join our free 45-minute webinar — we’ll walk you through how to get AI-ready in 90 days.

‍

TL;DR:

Microsoft Fabric doesn’t work like a simple “per-user licence”. Instead, you buy a capacity (a pool of compute called Capacity Units, or CUs) and share that across all resources (lakehouses, SQL servers, Notebooks, pipelienes, Power BI reports etc.) you use inside fabric for (data engineering, warehousing, dashboards, analytics). On the top of this, you separately pay for storage and certain user licences if you publish dashboards. The smart path: start small, track your actual consumption, align capacity size and purchasing model (pay-as-you-go vs reserved) with your usage pattern, so it becomes cost-efficient rather than a budget surprise.

What makes Fabric’s pricing model different

If you’re used to licencing models for analytics tools such as per-user dashboards or pay-per-app, Fabric introduces a different mindset. It’s no wonder many teams are confused and asking questions like:

“Will moving our Power BI set-up into Fabric make our costs spiral?”
“We’re licensing for many users. Do we now have to keep paying per user and capacity?”
“What happens when our workloads spike? Will we pay through the roof?”

Reddit users already ask:
“Can someone explain me the pricing model of Microsoft Fabric? It is very complicated …”

So yes, it’s new, it’s different, and you should understand the mechanics before you start using it.

The basics: what you must understand

Here are the key building blocks:

Availability of capacity = compute pool

Fabric uses “capacity” measured in CUs (Capacity Units). For example, an “F2” capacity gives you 2 CUs, “F4” gives 4 CUs, and so on up to F2048.

That pool is shared by all workloads in Fabric: data flows, notebooks, lakehouses, warehousing, and dashboards.

Important: you’re not buying a licence per user for most functionality, you’re buying compute capacity. It’s also important to note that if you are usign a Pay-as-You-Go model you’ll pay whenever the capacity is turned on (whether you are actively using it or not). You’ll be billed based on the time (minutes) the capacity was running and it doesn't matter if you were using all or none of your CU-s.

Storage is separate

Storage (via OneLake) is billed separately per GB. The capacity you buy doesn’t include unlimited free storage.
There are additional rules e.g. free mirroring storage allowances depending on capacity tier.

User licences still matter, especially for dashboard publishing‍

If you use Fabric and you want to publish and share dashboards via Power BI, you’ll still need individual licences (for authors/publishers) and in certain cases viewers may need licences depending on capacity size.

So compute + storage + user licences = the full picture.

Purchasing models: pay-as-you-go (PAYG) vs reserved

• Pay-as-you-go: You pay for the capacity per hour (minimum one minute) as you run it, and you can scale up/down. Good if usage is variable.

• Reserved capacity: You commit to a capacity size for a year (or more) and get ~40% discount—but you pay whether it’s used or not. Good if your workloads are steady.
  

How to pick the right model and avoid common mistakes

1. Track your workload and consumption before committing

Because you’re buying a pool of compute rather than per-user seats, you need to know how many jobs, how many users, how many refreshes, how much concurrency you’ll have.

For example: if you pick a small capacity and your workloads goes beyond that, Fabric may apply “smoothing” or throttle. So start with PAYG or small capacity, track consumption for 60-90 days.

2. Ask the right questions up front

• “Will our usage spike at month-end or quarters?”

• “How many users are viewing dashboards vs authoring?”

• “How many data transformation jobs run concurrently?”

• “Can we pause capacity on nights/weekends or non-business hours?”
  If you don’t answer these, you risk buying too much (wasted spend) or too little (performance issues).
  

3. Beware the “viewer licence” threshold

There’s a key capacity size (F64) where things change: For capacities below F64, users may still need separate Power BI PRO licences for report or dashbaord consumption; at F64 and above, viewers may not need individual licences.
If you migrate from an older Power BI model into Fabric without checking this, you could pay more.

4. Storage charges can sneak in

Large datasets, duplicates, backup snapshots, and deleted workspaces (retention periods) all consume storage. Storage costs may be modest ($0.023 per GB/month as of November 2025) compared to compute, but with volumes they matter.

Also, networking fees (data transfer) are “coming soon” as a Fabric cost item.

5. Don’t treat capacity like a fixed server

Because Fabric allows bursting (temporarily going above your base capacity) and smoothing (spreading load) your cost isn’t purely linear with peak loads. But you still pay for what you consume, so design workloads with efficiency in mind (incremental refresh, partitioning, avoiding waste).

A simplified checklist for your team

• Audit actual workloads: data jobs, refreshes, user views.

• Choose initial capacity size: pick a modest SKU (F4, F8) for pilot.

• For smaller solutions (below F64) it might make sense to combine Fabric PAYG and Power BI PRO solutions to get the best performance and price.

• Run PAYG for 60-90 days: monitor CUs used, storage, spikes.

• Analyse when you hit steady-state usage (>60% utilisation) → consider reserved capacity.

• Map user roles: who authors dashboards (needs Pro/PPU licence), who views only (maybe Free licence depending on capacity).

• Optimise data architecture: incremental loads, partitioning, reuse instead of duplication.

• Monitor monthly: CUs consumed, storage growth, unused capacity, aborted jobs.

• Align purchase: Scale up/down capacity ahead of known events (e.g., month-end), pause non-prod when idle.  

Frequently-asked questions  

“Will moving our Power BI setup into Fabric make our costs spiral?”
Not necessarily — if you migrate smartly. If you move without revisiting capacity size/user licences you could pay more, but if you use this as an opportunity to right-size, share compute across workloads, optimise refreshes and storage, you might actually get better value.

“Do I need a user licence for every viewer now?”
It depends on your capacity size. If your capacity is below certain thresholds, viewers may still need licences. At F64+ capacities you may allow free viewers for published dashboards. Monitor your scenario.

“What happens if we only run analytics at month-end? Can we scale down otherwise?”
Yes, with PAYG you can scale down or pause capacity when idle, hence paying only when needed. With reserved you lock in purchase. Choose based on your workload patterns.

“Is storage included in capacity cost?”
No, storage is separate. You’ll pay for OneLake storage and other persistent data. If you have massive data volumes, this needs budgeting

Get Fabric licensing right from the start

While Microsoft Fabric’s licensing and pricing model may feel unfamiliar compared to traditional per-user or per-service models, it offers substantial flexibility and potential cost-efficiency if you approach it intentionally. Buy capacity, manage storage, plan user licences, and do the tracking in the early phase.  

Teams that treat this as an after-thought often get surprised by bills or performance constraints. Teams that design for efficiency from the start get a shared analytics and data-engineering platform that truly scales.

Licensing clarity is the first step to a smooth Fabric journey.
Our experts can assess your current environment, model different licensing scenarios, and build a right-sized plan that keeps costs predictable as you scale.

Book a free assessment.

‍

TL;DR

Use our step-by-step guide to start using Fabric safely and cost-effectively, from setting up your first workspace and trial capacity to choosing the right entry path for your organisation. Build a lakehouse, connect data, create Delta tables, and expand gradually with pipelines, Dataflows, and Power BI. Whether you’re starting from scratch or integrating existing systems, it shows how to explore, validate, and adopt Fabric in a structured, low-risk way.

How to start using Fabric safely and cost-effectively

Before committing to a full rollout, start small. Activate a Fabric trial or set up a pay-as-you-go capacity at a low tier (F2–F8). These are cost-effective ways to explore real workloads and governance models without long-term commitments.

Begin by creating a workspace. From here, you can take one of two paths: starting fresh or integrating with what you already have.

1. Starting fresh (greenfield)

If you don’t yet have a mature data warehouse or analytics layer, Fabric lets you build the essentials quickly with minimal infrastructure overhead.
You can:

• Create a lakehouse in your workspace
  Import sample data (e.g.: ready to use Contoso data) or upload Excel/CSV files

• Explore them with SQL or notebooks

This gives you a safe sandbox to understand how Fabric’s components interact and how data flows between them.

2. Integrating with what you already have

Most organisations already have data systems — SQL databases, BI tools, pipelines, or on-prem storage. Keep what works; Fabric can extend it.
You can:

• Use Dataflows Gen2 or pipelines to ingest and transform data from existing sources

• Create OneLake shortcuts to reference external storage

• Bring in exports or snapshots (for example, CRM tables or logs)

• Use Fabric as an analytical or orchestration layer on top of your current systems

This hybrid approach lets you test Fabric on real data without disrupting production systems, helping you identify where it delivers the most value before scaling further.

Next steps once you’re up and running

After choosing your entry path, expand iteratively. Fabric rewards structure, not speed.

Add ingestion and transformation

Continue shaping data with Notebooks, Dataflows Gen2 or pipelines, schedule refreshes, and test incremental updates to validate performance.

Expose for analysis

Create a warehouse or semantic model, connect Power BI, and check performance, permissions, and security. Involve your Power BI administrators early — Fabric changes how capacities, roles, and governance interact.

Introduce real-time scenarios

Connect streaming sources, create real-time tables or queries, and trigger alerts or automated actions using activators.

Advance to AI and custom workloads

Train and score models in notebooks, or use the Extensibility Toolkit to build custom solutions integrated with pipelines.

Govern, monitor, and iterate

Apply governance policies, monitor cost and performance, and use CI/CD with Git integration to manage promotion across environments and maintain auditability.

Core Fabric building blocks and how to use them

Lakehouses & delta tables

Lakehouses in Fabric combine data lake flexibility with analytic consistency. Under the hood, Fabric stores everything in Delta Lake tables, which handle updates and changes reliably without breaking data consistency.

You can ingest raw files into lakehouse storage, define structured tables, and then query them with SQL or Spark notebooks. Use delta features to handle changes and versioning.

Pipelines & Dataflows

Fabric includes pipeline orchestration similar to Azure Data Factory. Use pipelines (copy, transformation, scheduled) for heavier ETL/ELT workloads.  

Use Dataflows Gen2 (Power Query–style) for lighter transformations or data prep steps. These can be embedded or called from pipelines.  

If you prefer a pro-code/code-first solution you can use PySpark, SparkSQL or even a simple python code to transform and analyse your data in a Notebook.

Together, they let you build end-to-end ingestion workflows, from source systems into lakehouses or warehouses.

Warehouses & SQL query layer

Once data is structured, you may want to provide a SQL query surface. Fabric lets you spin up analytical warehouses (relational, MPP) to serve reporting workloads.

These warehouses can sit atop the same data in your lakehouse, leveraging delta storage and ensuring you don’t duplicate data.

Real-time intelligence

One of Fabric’s differentiators is built-in support for streaming and event-based patterns. You can ingest event streams, process them, store them in real-time tables, run KQL queries, and combine them with historical datasets.

You can also define activators or automated rules to trigger actions based on data changes (e.g. alerts, downstream writes).

Data science & AI

Fabric includes native support for notebooks, experiments (MLflow), model training, and scoring. You can ingest data from the lakehouse, run Python/Spark in notebooks, train models, register them, and score them at scale.

Because the same storage underlies all workloads, you don’t need to copy data between ETL, analytics, and AI layers.

Extensibility & workloads

For development teams or ISVs, Fabric supports custom workload items, manifest definitions, and a DevGateway. Microsoft provides a Starter-Kit that helps you scaffold a "HelloWorld" workload to test in your environment.

You can fork the repository, run local dev environments, enable Fabric developer mode, and build custom apps or tools that operate within Fabric’s UI.

Common scenarios and example workflows

Speeding up Power BI reports
Move slow or complex dataflows into a lakehouse, define delta tables, and connect Power BI directly for faster, incremental refreshes.

Real-time monitoring
Ingest IoT or application logs into real-time tables, run KQL queries to detect anomalies, and trigger automated alerts or actions as events occur.

Predictive analytics
Use lakehouse data to train and score models in notebooks, then surface results in Power BI for churn, demand, or risk forecasting — all within Fabric.

Custom extensions
Build domain-specific tools or visuals with the Extensibility toolkit and integrate them directly into Fabric’s workspace experience.

Best practices and things to watch out for

Data discipline matters — naming, ownership, and refresh planning remain essential. Start small and build confidence. Begin with one or two use cases before expanding.  

Treat migration as iterative; don’t aim to move everything at once. Sync with your BI and governance teams early, as changes in permission and capacity models affect all users.  

Use Microsoft’s Get started with Microsoft Fabric training. It walks you through each module step by step. And take advantage of the end-to-end tutorials covering ingestion, real-time, warehouse, and data science flows.

Fabric delivers the most value when aligned with your goals. Our team can help you plan, pilot, and scale it effectively — get in touch to get started.

Resources:

https://learn.microsoft.com/en-us/training/paths/get-started-fabric/

‍

TL;DR

Fabric is emerging as the next-generation data and AI platform in Microsoft’s ecosystem. For growing organisations, the real question isn’t if you’ll use it — it’s how to get ready so that the investment delivers value fast. Signs you’re ready to begin: if your reporting relies on too many Excel files, your Power BI dashboards are slowing down, or pulling consistent data from different tools has become time-consuming and expensive. It’s also time to explore Fabric if your infrastructure and maintenance costs keep rising while insights stay stuck in silos.

“Where should we begin if we’re new to Microsoft Fabric?”

Whether you’re at the start of your analytics journey or already running tools like Synapse, Databricks, or Data Factory, Fabric offers a unified, scalable platform that connects your data and prepares you for AI. Not every organisation will start from the same place, and that’s okay.

Start small. Use a trial or low-tier capacity, connect one key dataset, define clear goals of your POC and evaluate performance. Hold off only if your organisation lacks data discipline or governance maturity. The earlier you begin experimenting, the smoother your transition when Fabric becomes the foundation of enterprise data operations.

“Can Fabric live up to its ‘all-in-one’ claims? Is now the right time to jump in?”  

It’s a question many teams are asking as Microsoft pushes Fabric into mainstream adoption.  

You’ve seen the demos, read the roadmap, and perhaps even clicked that ‘Try Fabric’ button — but readiness is key.  

If you adopt it before your organisation is prepared, you’ll spend more time experimenting than gaining value. If you start using it too late, your competitors will already be using Fabric to run faster, cleaner, and more scalable data operations.

Why timing matters for Microsoft Fabric adoption

If your team already uses Microsoft 365, Power BI, or Azure SQL, Fabric is the natural next step. It brings all your data and analytics together in one secure, cloud-based platform, without adding another layer of complexity.

For many organisations, the real challenge isn’t collecting data — it’s connecting it. You might be pulling financials from SAP or Dynamics, customer data from an on-premises CRM, and operational data from a legacy ERP or manufacturing system. Each of those tools stores valuable information, but they rarely talk to each other in real time.  

Fabric bridges that gap by creating a single, governed layer where all your data can live, be analysed, and feed AI models, while still integrating smoothly with your existing Microsoft environment. It brings together what used to be separate worlds:  

• Synapse for warehousing,  

• Data Factory for pipelines,  

• Stream Analytics for real-time data, and  

• Power BI for reporting.  

Historically, these ran as siloed services with their own governance and performance quirks.  

Fabric replaces this patchwork with one SaaS platform, powered by OneLake as a shared data foundation. That means one copy of data, one security model, and one operational playbook. Less time reconciling permissions, fewer brittle integrations, and a unified line of sight on performance.

For IT Operations, this changes everything. Instead of maintaining scattered systems, teams move towards proactive enablement, governance, monitoring, and automation.  

The real challenge isn’t understanding what Fabric can do; it’s knowing when your environment and team are ready to make the move.

Questions like this keep surfacing across forums like Reddit:

“Do we actually have the right skills and governance in place to use Microsoft Fabric properly?”

Let’s see what readiness really looks like in practice.

Signs your organisation is ready for Microsoft Fabric

You don’t need a massive data team or an AI department to benefit from Fabric. What matters is recognising the early warning signs that your current setup is holding your business back.

You’re running the business from Excel (and everyone’s version is different)

If every department builds its own reports, and the CEO, finance, and sales teams are never looking at the same numbers, Fabric can unify your data sources so everyone works from one truth.

Your Power BI reports are slowing down or getting hard to maintain

When dashboards take too long to refresh or adding new data breaks existing reports, you’ve outgrown your current setup. Fabric helps you scale Power BI while keeping performance and governance under control.

Reporting takes days and still raises more questions than answers

If your analysts spend more time moving files than analysing data, you’re ready for a platform that automates data movement and standardises reporting.

Your IT costs are rising, but you’re still not getting better insights

Maintaining servers, SQL databases, or patchwork integrations adds cost without adding value. Fabric replaces multiple systems with one managed platform, reducing overhead while enabling modern analytics and AI.

You want to use AI responsibly, but don’t know where to start

Fabric integrates Microsoft’s Copilot and data governance tools natively. That means you can explore AI safely — with your data, under your security policies — and our team can help you get there, step by step.

When to wait before adopting Microsoft Fabric

There are good reasons to hold off, too. If your organisation still lacks basic data discipline — no clear ownership, inconsistent naming, or ungoverned refreshes — Fabric will only amplify those gaps. Similarly, if you rely heavily on on-premises systems that can’t yet integrate with Fabric, the return on investment will be limited.

And if your team has no Fabric champions or time for upskilling, start with a pilot. Microsoft’s learning paths and community are growing by the day, but this is a platform that rewards patience and structure, not a rush to go all-in at once.

Even if you’re not ready today, you can start preparing by defining who owns your key datasets, documenting where your data lives, and assigning a small internal champion for analytics.  

These are the first building blocks for a successful Fabric journey — and we can help you set them up before you invest in the platform itself.

Put real-time intelligence and AI agents to work  

Once you’ve built a foundation of data discipline and readiness, Fabric starts to show its real power.  

Fabric enables real-time visibility into your operations, whether that means tracking inventory levels, monitoring production metrics, or getting alerts when something in your system changes unexpectedly. Instead of waiting for a daily report, you can see what’s happening as it happens.

And AI capabilities go far beyond Copilot. Fabric introduces data agents: role-aware assistants that enable business users to explore and query data safely, without adding reporting overhead for IT. The result is true self-service intelligence, where operations teams can focus on governance, performance, and optimisation instead of ad-hoc report requests.

Start before you need it, but not before you’re ready

Teams that start experimenting with Fabric now will be the ones setting best practices later. Microsoft’s development pace is relentless, and Fabric’s roadmap is closing the gaps between data, analytics, and AI at speed.

Fabric adoption isn’t a switch-on event. It comes with a learning curve. The earlier you begin, the easier it becomes to standardise governance, establish naming conventions, and embed Fabric into CI/CD and monitoring pipelines.

If your analytics stack feels stretched, your infrastructure spend is rising, or your governance model needs a reset, it’s time to start testing Fabric. Do it deliberately, in small steps, and you’ll enter the next generation of Microsoft’s data platform on your own terms.

Ready to see how Microsoft Fabric could work for your organisation?
Whether you’re just exploring or planning a full modernisation, our team can help you map your current data landscape and guide you step-by-step through a safe, structured adoption.

Book a free Fabric readiness assessment.

‍

TL;DR

You don’t always need Copilot Studio to use Copilot in Power Platform. Microsoft is weaving generative features directly into tools like Power Apps and Power Automate. With generative pages, you can use natural language to build pages into your model-driven apps with unique functionality, skipping dozens of manual steps. It’s still early days but it already shows how Copilot is moving from optional add-on to everyday productivity layer inside the platform.

Ever wished Copilot could build your Power Platform pages for you?

Model-driven apps have always been structured and corporate, designed for consistency rather than flexibility. Custom pages (similarly to canvas apps) gave makers some creative freedom but building them often meant lengthy workarounds.  

Generative pages change that balance. You can now describe what you need in plain English, and Copilot generates the page for you inside your model-driven app. What once required dozens of steps or complex canvas app design can now be spun up in minutes.

This is more than a convenience feature. It marks the way Copilot is flowing into the Power Platform ecosystem — not as a knowledge base lookup tool, but as a practical, embedded capability for app creation.

How to build your first app with Copilot in Power Platform

If you want to explore generative pages today, you’ll need to set up a US developer environment. The preview was announced on 21 July and, at the time of writing, is only available in the United States.  

European users can experiment by creating a US environment, but they should only use data that is safe to leave EU boundaries. A full general availability release in Europe is expected in 2026, though dates are not yet confirmed in Microsoft’s release plans.

How to get started:

• Start with a model-driven app (see Microsoft’s step-by-step guide). Generative pages sit inside these apps, giving you a natural language way to add new functionality.

• Describe what you need in plain language — for example, “a form to capture customer onboarding details” or “a dashboard showing open cases by priority.” Copilot generates the layout, controls, and data bindings automatically.

• Refine and customise the page by adjusting fields, tweaking the layout, or modifying logic as you would with any other app component.

• Embed the page into your app by adding it to navigation, combining it with existing model-driven pages.  

Think of the PCF as the “3D printer” for your LEGO set. Power Platform already gives you plenty of building blocks (low-code components you can drag and drop). If something is missing, PCF lets you design and build your own bespoke block, then slot it neatly into your app.

• Start using it. The output isn’t a mock-up or placeholder; it’s a functional page connected to your data model and ready to support your process.

Copilot for Power Automate

Copilot isn’t only helping with app building. In Power Automate, you can now create flows just by describing what you want in plain English.  

Instead of adding every step manually, Copilot builds the flow for you. This makes it easier for newcomers to get started and saves time for experienced makers. You can find examples and details on Microsoft Learn.

What to keep in mind

• Early wave: These features are still in preview. Expect limitations, and don’t base production apps on them yet.

• Data residency: If you’re in Europe and experimenting with a US environment, only use non-sensitive data.

• Future availability: European general availability is expected in 2026, but plans are not final. Check the release plan site for updates.

• Governance still matters: Copilot may reduce effort, but it doesn’t remove the need for data quality, licensing checks, and proper lifecycle management.

What’s next in AI-assisted app design

We’re still at the start of the wave, but even now, you can create polished, functional applications in a fraction of the time and embed them directly into model-driven apps.  Copilot will soon become part of everyday app-building in the Power Platform — no separate studio required.

Copilot isn’t just about generating text. It makes us rethink how enterprise applications are designed and automated. And as these previews mature into general availability, the difference between long, complex builds and quick, AI-assisted development will only widen.

Curious how to adopt Copilot in your Power Platform environment today and prepare for what’s coming next? Get in touch with our experts and start shaping your roadmap.

‍

TL;DR

Copilot Studio makes it possible for IT Ops and business teams to create custom AI agents that can answer questions, run processes, and even automate workflows across Microsoft 365. We recommend a structured approach: define the use case, create the agent, set knowledge sources, add tools and actions, then shape its topics and triggers. But before you dive into building, check your data quality, define a clear purpose, and configure the right policies.  

Before you start setting anything up, stop

It’s tempting to open Copilot Studio and start dragging in tools, uploading files, and typing instructions. But an agent without a plan is just noise.

• Get your data in order first. Bad data means bad answers, and no amount of clever configuration can save it.

• Define the “why” before the “how.” Build around a specific use case. For example, sales support, finance queries, service troubleshooting.

• Don’t build for the sake of building. Just because you can spin up a chatbot doesn’t mean you should. The best agents are purposeful, not experimental toys.  

Think of your agent as a new team member. Would you hire someone without a role description? Exactly.

Building your first Copilot: practical steps

Once you know the “why”, here’s how to get your first custom agent working.

1. Author clear instructions

Clear instructions are the foundation of your agent. Keep them simple, unambiguous, and aligned to the tools and data you’ve connected. Microsoft even provides guidance on how to write effective instructions.

2. Configure your agent

• Content moderation: In the Agent → Generative AI menu, set rules for what your Copilot should (and shouldn’t) say. For example, if it can’t answer “XY”, define a safer fallback response.

• Knowledge sources: You can upload multiple knowledge sources, or add trusted public websites so the agent uses those instead of a blind web search.

• Add tools: Agents/Tools/Add a tool lets you extend functionality. For instance, connect a Meeting Management MCP server so your Copilot inherits scheduling skills without rebuilding them.

You’re not just configuring settings — you’re composing a system that reflects how your organisation works.

3. Validate your agent’s behaviour

As of now, there’s no automated testing of agents, but that doesn’t mean you should skip this step. You can manually test your agent as the author. The Copilot Studio test panel allows you to simulate conversations, trace which topics and nodes are activated, and identify unexpected behaviours. The panel is there to help you spot gaps, so take the time to run realistic scenarios before publishing.

4. Pick the right model

Copilot Studio now offers GPT-5 Auto (Experimental) alongside GPT-4.0 (default). The experimental model can feel sharper, but it may not reliably follow instructions. If stability matters more than novelty — and for most IT Ops rollouts it does — stick with 4.0 until you’re confident.  
(As of 15th October, 2025. Note that model availability and behaviour may change over time).

The difference between noise and value

Rolling out a custom agent isn’t about dropping a chatbot into Teams. Done right, it’s about embedding AI into workflows where it drives real value — answering finance queries with authority, guiding service agents through processes, or combining AI with agent flows for end-to-end automation.

The difference between a useless bot and a trusted agent is preparation. Build with intent, configure with care, and test until you're sure it works properly.

You wouldn’t give a new hire access to your systems without training, policies, and supervision. Treat your AI agents the same way.

Need help automating workflows with Copilot Studio? Get in touch with our experts to discuss your use case.

‍