Blog

Insights & ideas

Stay ahead with expert articles, industry trends, and actionable insights to help you grow.

How to build, deploy, and share custom AI agents with Copilot Studio
10 mins read
October 15, 2025

How can I build, deploy, and share custom AI agents with Copilot Studio?

Learn how to build, deploy, and share your own AI agents in Copilot Studio, from defining purpose and prompts to connecting data and publishing for your team. A practical, step-by-step guide to turning ideas into working copilots.

Read more

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.

Soft blue and white gradient background with blurred smooth texture
Filter
Industry
Technology
Solution category
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Optimization from Top to Bottom: How We Structure Backlogs at Visual Labs, Part 2
June 3, 2024
2 min read
Optimization from Top to Bottom: How We Structure Backlogs at Visual Labs, Part 2
Read more

From Customer Needs to Implementation: The Journey of an Efficient Delivery Backlog

delivery backlog

In this hierarchical model, we start with epics, representing the overall project, and break down the development cycle through various levels right up to testing. This approach helps organize work, set priorities, and track progress. Let’s dive into each element and its significance:

Epic: At the highest level, the epic represents the project itself. This category encompasses the overarching goals and the project framework. Features and user stories under the epic serve to achieve specific objectives.

Feature: Within an epic, features reflect customer needs. These are concrete requirements and expectations expressed by customers that we aim to meet throughout the project.

PBI (Product Backlog Item): These are elements of the product backlog, which can be issues or user stories.

Action: Specific activities that need to be completed to achieve the project’s goals.

Issue: Problems or bugs identified during the project, as noticed by customers.

User Story (US): Detailed breakdowns of customer requirements. These are short, simple descriptions that outline the functionalities and benefits customers expect from the product. User stories help developers understand and accurately fulfill customer needs.

  • Task: Specific tasks derived from user stories and features that the project team must complete.Bug: Software defects identified during development. These can be issues found by either customers or developers.
  • Build: Development tasks aimed at creating a new version of the software.
  • Test Case: Test scenarios that specify what tests need to be executed to verify different aspects of the software.
  • Test Plan: A comprehensive plan that includes all available test cases and their results.
  • The process model illustrated here covers every step of the software development cycle, from requirement gathering to testing. This aids project teams in effectively managing development activities, improving software quality, and ensuring project success. This model not only organizes needs and work but also facilitates communication with customers.
  • By following this structure, Visual Labs ensures that all aspects of the project are covered comprehensively, promoting efficiency and clarity throughout the development process.
Optimization from Top to Bottom: How We Structure Backlogs at Visual Labs, Part 1
June 3, 2024
2 min read
Optimization from Top to Bottom: How We Structure Backlogs at Visual Labs, Part 1
Read more

At Visual Labs, we leverage Azure DevOps, a powerhouse tool in software development and project management. It empowers teams to efficiently manage their work from development to release. One critical element that can significantly influence project success is the structure of the backlog. A well-organized backlog not only ensures task and requirement transparency but also helps teams set priorities, respond effectively to changes, and closely monitor project progress.

In our upcoming blog series, we will showcase the backlog structures we use, highlight the differences between them, and discuss the typical work items in these backlogs.

In this blog post, we’ll delve into how we create and efficiently manage an Azure DevOps backlog. We’ll explore practices and tips to help teams maximize their backlog’s potential. We’ll cover how to handle requirements and tasks, and how to ensure the backlog reflects the current goals and challenges of the project. Join us to discover how we enhance project management efficiency with Azure DevOps!

At Visual Labs, we distinguish between two different backlog levels:

1. Delivery Backlog:

This type of backlog contains tasks related to project or product development. It includes software development, implementing new features, bug fixes, user stories related to customer needs, and any other activities that directly impact the product or project’s output. The goal is to support the continuous development and delivery of the product or service. Tasks in this backlog typically have higher priority as they directly contribute to customer value.

2. Admin Backlog:

The admin backlog encompasses tasks related to the project’s or team’s administrative, organizational, or internal operations. This includes updating internal documentation, ensuring regulatory compliance, training team members, or any activities that are not directly linked to product or service delivery but are essential for smooth operation. While these tasks might be less urgent or critical from a product perspective, they are vital for maintaining team efficiency and seamless project execution.

Summary:

The delivery backlog focuses on product development and delivery, while the admin backlog handles internal operations and administrative activities. Both are crucial for successful project management and teamwork but concentrate on different aspects.

DOJO
June 2, 2024
3 min read
DOJO
Read more

Background

The forum for operational development at Visual Labs is called Dojo. These sessions are held every Tuesday morning for one and a half hours. Originally launched in January 2023, Dojo was a half-day event held every two weeks and could only be attended in person.Participation in Dojo sessions is optional, although certain colleagues are often expected to attend due to their expertise. The topics of Dojo are determined by quarterly goals, and the exact agenda is set by management. These topics cover a wide range of areas, aiming to contribute to organizational development.

Why is it necessary?

Despite being a small organization, we work in distinctly defined technological areas (ERP, CRM, BI) that often serve the same clients. It is essential to have a common forum where we can gain insights into each other’s work or the company’s operations (e.g., ERP or BI colleagues are welcome at a CRM hackathon). This allows for collective thinking about how Visual Labs can develop as an organization.

Topics Covered So Far

Among others, the following topics have been discussed in Dojo sessions:

  • Using Azure DevOps (see: Optimization from Top to Bottom: How We Structure Backlogs at Visual Labs, Part One)
    • Feature delivery process
    • Managing work items
    • Defining work items
    • Handling statuses
  • Refining financial planning and billing processes
  • Hackathon for improving our internal CRM
  • Brainstorming on the development of our increasingly cramped office
  • Solution-seeking:
    • For technical challenges
    • For broadly defined, exciting client needs
  • Power Platform Starter Kit
    • Launching the PowerPlatform Center of Excellence (CoE) Starter Kit
    • Agile sprint review and planning ceremonies for the Visual Labs enhancement of the PowerPlatform Starter Kit ([[CoE+]]), where we also tested our agile wings 🙂
  • Customer relationship and competency training for POs, conducted by our regular coach, Klára Sugta
  • Knowledge sharing on the following topics:
    • Customer visits
    • Project launches

What Has Dojo Given Us?

Key achievements:

  • Creation of a Dojo Handbook that defines our main processes and operations, which we keep up to date.
  • Further development of the Microsoft-developed Power Platform Center of Excellence Toolkit [[CoE+]], cataloging Azure resources, DevOps projects, and areas that can be assigned to teams and users.
  • Strengthening and integrating the competencies outlined in the Competency Matrix into our daily routines.
  • Introduction of monthly financial planning with weekly tracking.
  • Development of our own CRM system (based on Dynamics 365 Sales and Project Operations, in collaboration with CoE+).

Other Forums for Organizational Development

  • Team Retrospectives
    • While Dojo generally deals with cross-departmental or company-wide topics identified by management, retrospectives at the team level focus on system-level improvements in individual collaboration.
    • In the future, it will be important to create a development backlog (Kaizen) to provide an overarching view of areas needing improvement, to which initiatives can be assigned and receive the necessary buy-in and resources.
  • 1on1s
    • The most straightforward opportunity to foster bottom-up ideas is through 1on1s, where topics can ripple up to management level.

The Future of Dojo

Dojo will continue to be the main forum for organizational development and will remain optional. We aim to facilitate participation in organizational development asynchronously and ensure that more written records of Dojo discussions are kept. Often, colleagues cannot attend sessions on topics they find interesting or do not find it worthwhile to sit through the entire discussion but would find a "tl;dr" version useful.If you want more information about our Dojo sessions or the topics discussed, follow our blog, as new articles on these topics are continuously published. If you have any questions or comments, don't hesitate to contact us!

Dojo
May 22, 2024
3 min read
Dojo
Read more

Background

The forum for operational development at Visual Labs is called Dojo. These sessions are held every Tuesday morning for one and a half hours. Originally launched in January 2023, Dojo was a half-day event held every two weeks and could only be attended in person.

Participation in Dojo sessions is optional, although certain colleagues are often expected to attend due to their expertise. The topics of Dojo are determined by quarterly goals, and the exact agenda is set by management. These topics cover a wide range of areas, aiming to contribute to organizational development.

Why is it necessary?

Despite being a small organization, we work in distinctly defined technological areas (ERP, CRM, BI) that often serve the same clients. It is essential to have a common forum where we can gain insights into each other’s work or the company’s operations (e.g., ERP or BI colleagues are welcome at a CRM hackathon). This allows for collective thinking about how Visual Labs can develop as an organization.

Topics Covered So Far

Among others, the following topics have been discussed in Dojo sessions:

  • Using Azure DevOps (see: Optimization from Top to Bottom: How We Structure Backlogs at Visual Labs, Part One)
    • Feature delivery process
    • Managing work items
    • Defining work items
    • Handling statuses
  • Refining financial planning and billing processes
  • Hackathon for improving our internal CRM
  • Brainstorming on the development of our increasingly cramped office
  • Solution-seeking:
    • For technical challenges
    • For broadly defined, exciting client needs
  • Power Platform Starter Kit
    • Launching the PowerPlatform Center of Excellence (CoE) Starter Kit
    • Agile sprint review and planning ceremonies for the Visual Labs enhancement of the PowerPlatform Starter Kit ([[CoE+]]), where we also tested our agile wings 🙂
  • Customer relationship and competency training for POs, conducted by our regular coach, Klára Sugta
  • Knowledge sharing on the following topics:
    • Customer visits
    • Project launches

What Has Dojo Given Us?

Key achievements:

  • Creation of a Dojo Handbook that defines our main processes and operations, which we keep up to date.
  • Further development of the Microsoft-developed Power Platform Center of Excellence Toolkit [[CoE+]], cataloging Azure resources, DevOps projects, and areas that can be assigned to teams and users.
  • Strengthening and integrating the competencies outlined in the Competency Matrix into our daily routines.
  • Introduction of monthly financial planning with weekly tracking.
  • Development of our own CRM system (based on Dynamics 365 Sales and Project Operations, in collaboration with CoE+).

Other Forums for Organizational Development

  • Team Retrospectives
    • While Dojo generally deals with cross-departmental or company-wide topics identified by management, retrospectives at the team level focus on system-level improvements in individual collaboration.
    • In the future, it will be important to create a development backlog (Kaizen) to provide an overarching view of areas needing improvement, to which initiatives can be assigned and receive the necessary buy-in and resources.
  • 1on1s
    • The most straightforward opportunity to foster bottom-up ideas is through 1on1s, where topics can ripple up to management level.

The Future of Dojo

Dojo will continue to be the main forum for organizational development and will remain optional. We aim to facilitate participation in organizational development asynchronously and ensure that more written records of Dojo discussions are kept. Often, colleagues cannot attend sessions on topics they find interesting or do not find it worthwhile to sit through the entire discussion but would find a “tl;dr” version useful.

If you want more information about our Dojo sessions or the topics discussed, follow our blog, as new articles on these topics are continuously published. If you have any questions or comments, don’t hesitate to contact us!

My Journey with CI/CD in Power BI: A Personal Tale of Transformation Part 2
May 6, 2024
3 min read
My Journey with CI/CD in Power BI: A Personal Tale of Transformation Part 2
Read more

Implementing This Miracle: If I were to start all over again, I'd tell you this:

A) Get cozy with Git, simulate real-world scenarios as a team during a demo session, and document/record everything.

To better prepare for collaborative development, we crafted a scenario in which multiple developers would work simultaneously on the same file, aiming to rehearse a range of actions we had previously encountered. This included creating different measures at the same time and then merging these into a single file, adding, removing, or modifying visuals and integrating those changes, reverting to a previous version to serve as the basis for new features, and managing version transitions between DEV, TEST, and PROD branches. Through this exercise, we sought to simulate and navigate the complexities of real-world collaboration, enhancing our team's ability to handle various project management tasks efficiently.

  1. Commit early and often, and
  2. Treat your commit notes like a diary of your project's life. Writing comprehensive commit descriptions will enhance clarity and facilitates easier navigation through the project's history for both you and your teammates.
  3. Branch Carefully! Always verify you're working on the correct branch to avoid unintended changes in the wrong areas of your project.
  4. And never forget the power of communication. Despite the technical tools at your disposal, effective teamwork hinges on constant communication to ensure alignment and collaboration.

These practices didn't just make our projects better; they made us better developers and teammates.

B) Bumps Along the Way: Sure, we faced our fair share of surprises.

Challenges Encountered Since Adoption:

Despite the myriad benefits, several challenges have emerged since adopting source control in Power BI, particularly given the preview status of this feature. I'm going to highlight the few most common ones.

  1. Custom Visuals Compatibility: Custom visuals used in reports need to be installed separately by each collaborator. Don't forget to let your colleagues know which custom visual you added to your dashboard as its name won't show up only the following error message which is a bit hard to dechypre.
CI/CD

2. Merge Conflicts and Code Loss: Situations have arisen where accepting both changes during a merge resulted in lost code, highlighting the need for careful conflict resolution (screenshot from another blogpost describing the issue).

blogpost

3. File Opening Issues After Merge: Conflicts within the data model, such as incorrect relationship settings, can prevent files from opening, necessitating reversion to previous versions.

unable to open

4. Infinite Semantic Model Refresh Loops in PBI Desktop: Unexplained delays in model refreshes post-merge, extending for hours, indicate potential issues with large semantic models.

+1) Data is not stored in repos: It’s good to keep in mind that data is not stored in the Repo, only semantic model and report related code is stored, you still need to refresh your data on Power BI Service.

Conclusion: This journey of integrating CI/CD and source control into our Power BI workflows has been one of the most rewarding experiences of my professional life. It wasn’t just about making our projects more efficient; it was about transforming our team into a more cohesive, capable, and confident unit. As we look to the future, I’m excited about the possibilities that lie ahead, ready to tackle whatever comes our way with a smile and a git commit.

My Journey with CI/CD in Power BI: A Personal Tale of Transformation Part 1
April 23, 2024
3 min read
My Journey with CI/CD in Power BI: A Personal Tale of Transformation Part 1
Read more

Hello, friends! Today, I'm diving deep into my own adventure with Continuous Integration (CI) and Continuous Deployment (CD) in the realm of Power BI—a journey marked by trials, triumphs, and a lot of learning along the way. For so long, CI/CD in Power BI felt like trying to fit a square peg in a round hole. With a mix of third-party tools and makeshift solutions, my team and I navigated through a maze of compliance and administrative hurdles, often feeling lost in a sea of approvals and support tickets to try introduce a potential CI/CD solution or workaround. Then came May 2023, and with it, a beacon of hope: Power BI project files. This was more than just a feature; it was a revolution that promised to redefine how we approached our projects.

The Before Times: Rewind to before this pivotal change. My team, like many others working in data analytics within complex, multinational landscapes, struggled immensely with the lack of source control in Power BI. Our attempts at version control felt archaic—think "save as" with date and version stamps—and far from agile (shared folders on SharePoints or OneDrive). We were a team longing for simplicity and efficiency but found ourselves bogged down by the limitations of our tools.

A Game Changer: Power BI Project Files: Then, the game changed. The introduction of project files (.PBIP) wasn't just an update; it was a lifeline. This wasn't about saving our projects as mere files; it was about evolving them into living, breathing entities, organized within folders that spoke the language of our data stories through JSON (not ideal, but still an enormous improvement) .

Getting Our Hands Dirty: Embracing this new world, we ventured into the depths of Git with VS Code and Azure DevOps.

Each Power BI file became its own project, its own repository. This structure, while logical, required us to rewire our brains, to rethink our approach to collaboration and version control. Our workflow transformed, becoming more streamlined yet demanding a new level of diligence and precision.

The Rocky Road: It wasn't all smooth sailing. Adopting Power BI project files and integrating Git introduced us to a host of challenges. Merge conflicts became our nemesis, and the occasional quirks of a preview feature tested our patience. But with every stumble, our resolve grew stronger. The benefits—oh, the benefits!—far outweighed the occasional headaches. We were building something resilient, transparent, and infinitely more manageable.

Looking Ahead with TMDL: The next big step ahead is the introduction of TMDL. Storing your semantic model in TMDL (preview feature since the March 2024 update) transforms the code into a format that's not only human-readable but also intuitively organized, making every element—be it measures, tables, or columns—distinctly easy to identify in separate blocks. This clarity significantly simplifies the process of resolving merge conflicts and tracking changes, making the whole experience more straightforward.

Looking Ahead with TMDL

Why This Matters: The move to source control in Power BI has been nothing short of transformative. It brought clarity to our development process, made our end products more reliable, and, most importantly, it strengthened our team's bond. We learned to communicate more effectively, to trust in our collective skills, and to embrace the inevitable learning curve together.

To be continued...

Sorry, no items found with this category

Ready to talk about your use cases?

Request your free audit by filling out this form. Our team will get back to you to discuss how we can support you.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Stay ahead with the latest insights
Subscribe to our newsletter for expert insights, industry updates, and exclusive content delivered straight to your inbox.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.