Tag / Copilot

Simon looking for missing components in his agent.
by Simon Doy

Missing Topics And Agent Components in your Deployed Copilot Studio Solutions? Try This


Introduction

If you are being good, when building your Copilot Studio Agents, you’ll be using Solutions to deploy your agents. You’ll be deploying your agents from a development environment through your test and production environments.

If you are not, then take a look at my series of blog posts, which show you how to setup Dev Ops pipelinest which will get you up and running.

Solutions are great, but Copilot Studio does have a habit of not playing ball sometimes, and it’s not always solution-aware.

The issue

Let me tell you a story.

So, you build v1.0 of your Copilot for Finance.

You deploy the solution using an automated pipeline to move the solution from Development, Test to Production.

You publish your agent into Microsoft 365 Copilot and deliver it to your users.

They are super happy with it, and they use it to boost their business and team productivity. Finally, you are getting an ROI on Copilot!

Then they say

“Simon, it would be good if the Copilot for Finance would help us with our month-end tasks. Can you get the Agent to help us collate our reports and do the month end reconciliation tasks?”

You are excited to look at this new feature, and you, of course, agree to deliver this!

So, you start v2.0 of your Copilot Agent, and you add a new topic and a new AI Model to your Agent, and it’s all working in development.

Awesome!

You kick off your Azure DevOps pipeline to deploy v2.0 of your agent into testing. This allows the users to test it before it goes to production.

You fire up the Copilot in Test, but wait a minute, the topic isn’t there, and it’s not working.

What’s going on?

You go back to development and publish the Solution again. You start the deployment, but nothing changes its still the same.

What’s going on?

Well, it turns out that Copilot Agents, when new components are added, the agent doesn’t always add these components to your solution!

So what can you do?

Well, the easiest way is to remove the agent component from the solution. Don’t delete it from the environment!

This will take the agent and all components out of the solution.

Now simply add the agent back into the solution.

Next, run your pipeline to export the solution from Dev to Test.

Now you are all set; the solution includes your topic and its missing components.

The users are ecstatic and the agent is now helping them with their month-end tasks.

You push your agent to production, and you are done!

Excellent work.

Conclusion

Copilot Studio is not always aware of solutions and can miss adding components, such as newly added topics and AI models.

However, now you know, and hopefully this tip can save you time from diagnosing these deployment issues in the future.

Hope that helped ….

…. Then the phone rings and they are asking for a new feature, this time it’s to help with year-end…

… Good luck!

AI generated with the prompt please create an image which has the title "How to solve: Copilot Studio Agents, Managed Solutions, and Knowledge Sources that you cannot change" The image is for a blog post and is related to development, Copilot Studio, configuration that cannot be changed, frustration and then enlightenment for the developer. If you could feature me as a manga character that would be great. here is my photo.
by Simon Doy

How to solve: Copilot Studio Agents, Managed Solutions, and Knowledge Sources that cannot be changed


Introduction

When you build and deploy a Copilot Studio Agent with Knowledge as a managed solution, we have a problem.

The problem is that the Knowledge Source Url cannot be changed!

You see, when you configure a Knowledge Source to use information, for example, from SharePoint, you provide a URL for where that knowledge exists by pointing to a SharePoint site or document library.

Ideally, you are using different sources in Development, Testing and Production. When you deploy your Agent in a Managed Solution, the knowledge source is managed, and the URL cannot be changed.

Hopefully, the Copilot Studio product team will allow us to use Environment Variables to configure these URLs in the future, but until that happens, what options do we have?

We could use the same URL in all environments, but it’s not great if we want to do proper testing.

Also, if our development and test environments are built in separate tenants, then we have a problem. This is often the issue when building solutions for customers, where we deploy into our customer tenants.

A Solution

We can utilise DevOps and Build and Release Pipelines to export a solution, unpack it, modify the URL that the Knowledge Source uses, and then repackage the solution for deployment into the target environment.

To get started, read the article on the Power Platform Build and Deployment Pipelines that I built a few years ago. These have been extended to enable support for configuring Copilot Studio Knowledge Support Urls.

I have updated the Github Repo with the latest versions of the pipelines, so you can get access to all the code from there. If you use the instructions in my article above then will be able to get everything set up. However, there are some new parameters that I need to make you aware of.

New Tooling Overview

The pipelines are held in the dev-ops folder, and there is a new folder called tools, which has a PowerShell script called Update-PowerPlatformSolutionKnowledgeSite.ps1

This PowerShell script takes three parameters, and you will need your managed solution as a zip file that has been extracted into a subfolder to test.

The parameters are the following

  • DirectoryPath – this is the path to the extract solution zip.
  • KnowledgeSourceName – this is the name of the KnowledgeSource within the zip file.
  • SiteUrl – this is the URL that we should use for the new KnowledgeSource.

The script will look for an appropriately named folder which has the following naming convention

search value *[AgentName].knowledge.[KnowledgeSourceName]_*

e.g. cr633_copilotForHr.knowledge.HumanResources_XHInmH4G9R5qccpXQxHCs

Once it has found that folder, it will look inside for a data file.

The data file has the following structure, including a site: parameter. The script simply modifies that entry with the provided URL and saves the file.

Now, we simply pack the solution file back and deploy it.

Fortunately, for you, all the pipelines have been updated to do all this great work. You just need to configure them!

Configuring the Pipelines

I am going to presume that you have got the pipelines up and running using the other series of blog posts.

So, to get Pipelines configuring your Knowledge Sources, do the following:

  • open /dev-ops/i365-powerplatform-solution-release-pipeline.yml
  • Find the environment stages in the pipeline (see screenshot above). There are two. Change the parameters to the following
    • KnowledgeSourceUpdate: true
    • KnowledgeSourceName: [the name of your knowledge source, see above about the script to find out how to get that name]
    • KnowledgeSourceSiteUrl: [the URL to your SharePoint site that you wish to change it to for that environment]
  • Save your pipeline and commit changes to git.
  • Run the build pipeline to get all the tools into the assets for your release.
  • Run the release pipeline (the one we have just changed).

Now, when your Agent is deployed, your knowledge URL will be changed.

Here is an agent in Development.

Here is the agent being deployed by the pipeline.

Here is the agent deployed into Production

Conclusion

In this article, we discussed the challenge faced in configuring the knowledge sources when deploying Copilot Agents built on Copilot Studio with managed solutions.

I highlighted an approach for making changes to the URL of these knowledge sources.

I hope that it helps you and let me know how you get on!