Reading Time: 31 minutes

In this blog post, I’ll explore why and how to extend Microsoft 365 Copilot with Microsoft Copilot Studio using declarative agents.

Microsoft 365 Copilot is already a powerful AI assistant that uses large language models (LLMs) and integrates with your data in the Microsoft Graph and Microsoft 365 apps and services. It’s designed to help users stay productive across the familiar Microsoft 365 experiences they use every day. However, out of the box, Microsoft 365 Copilot is designed to support a broad range of scenarios. Rather than being a single, standalone experience, it appears across multiple Microsoft 365 surfaces. You can access Microsoft 365 Copilot through several entry points, including:

• Copilot in Loop
• Microsoft 365 Copilot Chat – a central place where users can ask questions and reason over information across their organisation. Copilot Chat is grounded in Microsoft Graph and only has access to the data that the signed‑in user already has permission to access. Under the hood, Copilot uses an intelligence layer (often referred to as Work IQ) to understand context, relationships, and work patterns across your organisation, enabling more relevant and personalised responses.
• Copilot in Outlook
• Copilot in Teams
• Copilot in Word
• Copilot in PowerPoint
• Copilot in Excel
• Copilot in Whiteboard
• Copilot in OneNote

Using Microsoft 365 Copilot, organisations benefit from integration with their Microsoft 365 data, such as, SharePoint, email, OneDrive, Word files and more.

Microsoft 365 Copilot isn’t a single, standalone app; rather, it’s a collection of intelligent capabilities built directly into Microsoft 365 applications. These capabilities are powered by Microsoft Graph, an orchestration service, large language models (LLMs), and Work IQ, all working together to deliver context-aware assistance.

Microsoft Graph and Work IQ: How Copilot understands your work

Microsoft Graph is the foundation that gives Microsoft 365 Copilot access to your organisation’s data. It securely connects information from across Microsoft 365, such as emails, files, meetings, chats, and calendars. It understands how this information relates to people, teams, and projects. This allows Copilot to find the right information at the right time, while always respecting your existing permissions and security controls.

Work IQ builds on top of Microsoft Graph and focuses on understanding how work actually happens. Instead of treating emails, documents, meetings, and chats as separate items, Work IQ looks at patterns across your daily work, such as, who you collaborate with, what you’re working on, and how information flows through the organisation. Over time, this creates a shared work memory that helps Copilot provide more relevant, personalised responses without you needing to explain context every time.

Together, Microsoft Graph and Work IQ allow Copilot to move beyond simple search. Copilot can understand intent, not just keywords. For example, if you ask about “project delivery status,” Copilot can surface a document titled “Team Milestone Update” even if the wording doesn’t exactly match. If a manager asks for “team updates”, Copilot can understand who the people in the team are and pull together the most relevant recent activity.

The result is an experience where Copilot feels aware of your role, your work, and your organisation, delivering answers and suggestions that are grounded in real data, meaningful context, and the way you actually work.

The below diagram demonstrates how Copilot works under the hood.

As shown in the diagram above, Microsoft 365 Copilot has access to Microsoft 365 data through Microsoft Graph. This includes content such as emails, files, meetings, chats, and calendar data that users already have permission to access. However, many organisations rely on business-critical data that lives outside Microsoft 365. This raises an important question: how can Copilot work with third‑party systems such as Jira, ServiceNow, and other applications used daily across the organisation? In the remainder of this blog post, we’ll explore the options available for extending Microsoft 365 Copilot so it can incorporate and reason over both Microsoft 365 data and third‑party data.

As organisations look to apply Copilot to specific business processes, domains, or knowledge areas, the ability to extend and tailor Copilot becomes essential. One of the primary ways Microsoft enables this is through declarative agents. Before we continue, it’s important to first understand what declarative agents are and the role they play in extending Microsoft 365 Copilot.

What are Declarative Agents?

Declarative agents, also known as Copilot agents, extend the capabilities of Microsoft 365 Copilot. These agents use the same orchestrator and models as Microsoft 365 Copilot. By reusing the existing infrastructure and controls, they provide a consistent experience for end users, as shown in the image above, but are scoped to specific business needs or scenarios.

These agents act as subject matter experts by using defined instructions, knowledge, and actions, while still running inside the familiar Microsoft 365 Copilot chat experience. This allows users to interact through the same Copilot interface.

If you require custom orchestration or the use of a different large language model, a declarative agent isn’t suitable; in that case, you should consider building a custom agent instead.

Declarative agents work best when the information relevant to your scenario is already available within Microsoft 365. If you need to ingest data from an external system into Microsoft 365, you can use a Copilot connector. If you need to interact with external systems in real time, you can expose those systems through custom actions; however, the agent will still rely on Microsoft 365 Copilot’s built‑in orchestration.

Do I really need to create an agent?

Declarative agents, also known as Copilot agents, extend the capabilities of Microsoft 365 Copilot. These agents use the same orchestrator and models as Microsoft 365 Copilot. By reusing the existing infrastructure and controls, they provide a consistent experience for end users, as shown in the image above, while being scoped to specific business needs or scenarios.

These agents act as subject‑matter experts by using defined instructions, knowledge, and actions, while still running inside the familiar Microsoft 365 Copilot chat experience. This allows users to interact with them through the same Copilot interface.

If you require custom orchestration or the use of a different large language model, a declarative agent isn’t suitable; in that case, you should consider building a custom agent instead.

Declarative agents work best when the information relevant to your scenario is already available within Microsoft 365. If you need to ingest data from an external system into Microsoft 365, you can use a Copilot connector. If you need to interact with external systems in real time, you can expose those systems through custom actions; however, the agent will still rely on Microsoft 365 Copilot’s built‑in orchestration.

To understand this in more detail, it’s helpful to look at the two types of Copilot connectors available today: synced connectors and federated connectors.

Copilot Connectors: Synced vs Federated (Live)

Microsoft 365 Copilot supports two connector models for bringing third party data into Copilot experiences.

Synced connectors ingest external content into Microsoft Graph, where it is indexed and added to the semantic index. This allows Copilot to search and reason over that content in the same way it would with native Microsoft 365 data.

In contrast, federated connectors retrieve information in real time using Model Context Protocol (MCP) and do not index content into Microsoft Graph. This makes federated connectors useful for sensitive or fast changing data, while synced connectors are usually better for large knowledge bases where you want broad discovery and consistent answers across Copilot.

Note: Federated connectors are currently available in early access preview and may not appear in all Microsoft 365 tenants, depending on release ring and licensing.

Why would you want to extend Microsoft 365 Copilot?
As shown in the diagram above, Microsoft 365 Copilot has access to a number of your files by default and can reason over this data. However, it doesn’t have access to everything. Microsoft 365 Copilot does not have access by default to the rest of your organisational data, such as line‑of‑business applications like Salesforce, SAP, Jira, ServiceNow, and others. This is because Microsoft 365 Copilot Chat is primarily grounded in data available through Microsoft Graph, including Word, PowerPoint, email, SharePoint content, Teams conversations, and files stored in OneDrive.

Microsoft 365 Copilot supports multiple ways of bringing third‑party data into Copilot experiences. One approach is synced connectors, which ingest external data into Microsoft Graph and make it available through semantic indexing. Another approach is federated connectors, which retrieve data in real time without indexing it into Microsoft Graph. At the time of writing this post, federated connectors are available in.

However, we won’t be using either synced or federated connectors as we continue through this post.

Instead, we’ll focus on a declarative agent approach, where knowledge and connectors are added directly to the agent and scoped specifically to that agent. This method is commonly used when integrating systems such as ServiceNow, Jira, Monday.com, and more, where the agent retrieves or interacts with data at runtime under the user’s permissions, without making that data tenant‑wide or indexing it into Microsoft Graph.

This approach allows Copilot to reason over the information relevant to a specific business scenario, while keeping the knowledge controlled, targeted, and scoped to the agent itself.

How Copilot Understands Knowledge from External Systems

When you connect Microsoft 365 Copilot to external systems such as Salesforce, ServiceNow, or Confluence, simply retrieving data is not enough. Copilot needs to understand what that information means.

Traditional keyword‑based search looks for exact words or phrases. For example, if you searched for “holiday allowance policy”, you might miss a document titled “Annual Leave Guidelines” because the wording does not match exactly.

The semantic search built into Microsoft 365 Copilot works differently. Instead of relying only on keywords, it understands the meaning and context behind a question. This allows Copilot to surface relevant information even if the wording does not match.

For example:

User asks:
“What’s the policy for booking time off?”

Copilot might retrieve information from a document titled:
“Annual Leave Request Procedure”

even though the words “time off” were never used in the document.

In many scenarios, the knowledge required by Copilot may already exist within Microsoft 365, such as documents stored in SharePoint sites.

Scenario we will build:

Employees across your organisation regularly need to refer to internal policies and procedures to complete everyday tasks. These documents are stored in a SharePoint Online site, such as expense policies, dress code policy, onboarding guides, sick leave, return to work, training and flexible working policies and more. However, searching through multiple documents can be time consuming.

You want to create a declarative agent that allows users to ask questions in natural language and receive accurate answers based on the documentation stored within SharePoint.

Now that you have an idea of what declarative agents are, let’s build a declarative agent based on this scenario. We will also explore agent options as we go through the demo.

Create a declarative agent built specifically for Microsoft 365 Copilot

Prerequisites:
To follow along and build declarative agents that run inside Microsoft 365 Copilot using Copilot Studio, you must have a Microsoft 365 Copilot licence.

If you don’t have a Microsoft 365 Copilot licence, you can still build agents in Copilot Studio using a Copilot Studio Trial or pay‑as‑you‑go (Copilot Credits). However, without a Microsoft 365 Copilot licence, you won’t be able to run or test the agent within the Microsoft 365 Copilot experience demonstrated in this post.

Note: If you plan to run declarative agents at scale, enable actions, or publish agents beyond basic internal usage, it’s worth reviewing how Copilot Studio usage is measured and managed using Copilot Credits. For more details, see Billing rates and management in Microsoft Copilot Studio.

1. Visit https://copilotstudio.microsoft.com
   
   
2. Click agents

3. Select Microsoft 365 Copilot

4. Select Add or New Agent (label may vary depending on tenant and release)

5. Configure the agent:
– Agent language: English
– Agent name: Policy Advisor
– Agent image: Upload a custom image (optional but recommended)

6. Description – Use your own words to describe what your agent should help with, including the target audience and end goal.

Note: The description helps Microsoft 365 Copilot identify when your agent is relevant for a specific task or situation. Keep it short, precise, and simple. This description will also be made visible to users when they start to make use of your agent. Character limit at the time of writing this post: 1,000 characters.

Description
The Policy Advisor helps employees quickly find clear, accurate answers to Contoso Ltd. policies and procedures. Ask natural language questions about onboarding, benefits, leave, remote work, training, conduct, and more.

7. Instructions – below

Note: These instructions define how the agent should behave when extending Microsoft 365 Copilot. They control what the agent does, how it responds, and the boundaries it must follow. You can update and refine these instructions later as you test the agent. These instructions are not visible to end users.

---

Your goal is to make policies easy to understand, easy to navigate, and less intimidating.

You are Policy Advisor, an employee facing assistant for Contoso Ltd.

Your role is to help employees understand internal policies, procedures, and guidelines based only on the documents provided in SharePoint. These include, but are not limited to, onboarding guides, workplace policies, code of conduct, benefits, training requirements, remote working, career progression, and wellbeing resources.

How you should respond

• Answer questions clearly, calmly, and professionally
• Use plain, friendly language suitable for all employees
• Be supportive and reassuring, especially for new starters
• Summarise policies in an easy‑to‑understand way rather than repeating them word for word
• If appropriate, explain what employees can expect, do next, or who to contact

Grounding and accuracy

• Only answer based on the content available in the connected SharePoint documents
• Do not guess, invent, or assume information
• If the answer is not clearly covered in the documents, say so politely and suggest contacting HR or a manager. Do not make information up if it’s not documented.

Boundaries

• Do not provide legal advice
• Do not make decisions or approvals on behalf of Contoso Ltd.
• Do not speculate about disciplinary outcomes
• Never assist with any other queries unless they are related to internal contoso policies. You are strictly a policy advisor and that is it.

Tone and behaviour

• Be inclusive, neutral, and non‑judgmental
• Encourage employees to ask questions
• Reinforce that policies exist to support employees, not catch them out

When unsure

• Clearly state that the information may vary by role or location
• Recommend speaking with HR or a manager for confirmation

---

8. Click to Add suggested prompts. When done, click save.

I’ll be adding the starter prompts below.

Note: Suggested prompts are predefined example questions or actions that appear when a user opens a Copilot agent. They act as conversation starters and show users what the agent is capable of, especially when they don’t yet know what to ask.

Title: First day at Contoso
Prompt: What should I expect on my first day at Contoso Ltd?

Title: Mandatory training
Prompt: What mandatory training do I need to complete and by when?

Title: Remote or hybrid working
Prompt: How does remote or hybrid working work at Contoso?

Title: Booking time off
Prompt: How do I book annual leave or time off at Contoso?

Title: Dress code
Prompt: What is the dress code at Contoso, including for remote work?

9. Click Create. I’ll configure the agent further shortly.

10. Let’s test the agent. Click the Test button located at the top right, next to the Publish button, as shown in the image below. 

The test pane is a great way to test your agent, fine‑tune its behaviour, and test again.

11. In the test pane, the agent name and the icon you uploaded earlier appear, along with some of the starter prompts.

I’ll click the Mandatory training prompt. This is one of the suggested prompts created earlier and acts as a conversation starter in case users are unsure what to ask the agent.

The response from the agent indicates that it was unable to locate any relevant information.

This is expected behaviour at this stage. The agent does not yet have access to any knowledge sources, and it is not allowed to search the internet. At the moment, the agent can only respond based on the instructions provided, but no supporting content has been connected.

The policy documents the agent needs to answer these questions are stored in SharePoint, and we haven’t connected that SharePoint data to the agent yet. In the next step, we’ll add the required SharePoint content as a knowledge source so the agent can start answering questions accurately.

12. Note about web search

Copilot Studio also provides an option to enable web search, as shown in the diagram below.

For this scenario, web search remains disabled. The Policy Advisor agent is designed to answer questions based only on approved internal policy documents stored in SharePoint. Enabling web search could result in answers being grounded in public web content, which is not appropriate for an internal policy advisor.

Clear instructions help guide the agent’s behaviour, but best practice is to control grounding by enabling only the knowledge sources you intend the agent to use.

Before adding a knowledge source, let’s do some further testing to validate the agent’s behaviour and boundaries.

At this stage, the agent is operating only on the instructions we defined earlier, without access to any internal knowledge sources. This allows us to confirm that the agent responds appropriately to questions that fall outside its intended scope.

13. Click the + icon visible under the Publish button to start a new conversation

14. Let’s try a different prompt to test the agent’s boundaries.

I’ll ask the agent:

“Can you recommend a 22‑inch Dell monitor under £500?”

The agent is not able to help with this request. This is expected behaviour.

Although Copilot Studio provides an option to enable web search, web search remains disabled for this scenario. More importantly, the instructions provided earlier clearly define the agent’s role as a Policy Advisor for Contoso Ltd.

The agent is designed to answer employee questions about internal policies and procedures only. Recommending products or equipment falls outside that scope.

I’ll try another prompt:

“Can you recommend a desk for my home office

Again, the agent correctly explains that it cannot help with this request. This confirms that the instructions and boundaries are working as intended.

15. So what next? let’s add my SharePoint URL including all my policy documents.

When you build an agent in Copilot Studio, you’re not technically training the AI in the traditional sense.
Instead, you’re connecting it to trusted information sources that it can search when responding to users. This is done using the Add Knowledge feature.

Think of this as:

“Where should my agent look to find answers?”

When you select Add Knowledge, Copilot Studio allows you to connect your agent to different data sources across your organisation (or public web content). These are grouped under the Featured and Advanced tabs as I will demonstrate next.

Click Add knowledge

You’ll find that there are additional knowledge source options available.

Public websites
This allows your agent to answer questions using information from selected public websites, such as a company website or publicly available documentation.

Note: By default, Copilot Studio uses generative orchestration, which allows you to add up to 25 public website URLs per agent when using Public websites as a knowledge source. Generative orchestration is enabled automatically for new agents, but you can switch to classic orchestration if required. It’s important to note that classic orchestration supports fewer public website URLs and is typically used for more narrowly scoped or legacy scenarios.

SharePoint:
This allows your agent to retrieve answers from documents stored in SharePoint sites, including:

• Word documents
• PDFs
• Policy documents
• Standard Operating Procedures
• Internal guidance documentation

For SharePoint content, Copilot Studio uses Microsoft Graph and semantic search to retrieve relevant sections from documents in response to user questions. If this sounds familiar, that’s because we covered semantic search earlier in this post when explaining how Copilot understands and retrieves relevant information from connected data sources.

Dataverse:
Microsoft Dataverse is the secure data platform for Power Platform. It’s used to store and manage structured business data, such as customers, requests, or records, in a way that apps, automations, and Copilot agents can reliably read from and write to.

Data in Dataverse is stored in tables, similar to Excel tables, with rows and columns that represent business information. Dataverse includes built‑in tables for common business scenarios and also allows you to create custom tables tailored to your organisation’s needs.

Dataverse provides important capabilities such as security, relationships, business rules, validation, and auditing, which help ensure data remains consistent and trustworthy, regardless of which app, flow, or agent accesses it. For example, you can track changes to data, including who made the change and the previous and new values.

In Copilot Studio, Dataverse is typically used when an agent needs to work with structured business data, such as creating or updating records, tracking requests, or retrieving information in a consistent format.

If you already use another data source, such as SharePoint, Excel, or an external database, you can connect to those using connectors. However, if you need a native data source built into Power Platform, Dataverse is a good choice because it supports relationships between tables, rich security controls, and scalability without manual infrastructure management.

Dataverse integrates with Microsoft Entra ID (Microsoft’s Cloud Identity and Access Management Solution), allowing admins to control who can read, write, or modify data. It works across all Power Platform services, including Power Apps, Power Automate, and Copilot Studio.

Dynamics 365
When you add Dynamics 365 as knowledge, you’re allowing your Copilot agent to retrieve information directly from live CRM (Customer Relationship Management) or operational system used by these applications. Instead of answering questions based on documents, your agent can answer questions based on, customer case history, order records, account data, sales opportunities and more.

For example, an organisation uses Dynamics 365 Customer Service. A user asks, “What’s the latest update on my support case?”. The agent retrieves the relevant case record, including the latest status update and assigned support engineer, and then returns a real‑time response.

Under the hood, Dynamics 365 applications store their data in Microsoft Dataverse, so access to Dynamics 365 data in Copilot Studio is provided through Dataverse with the appropriate permissions applied.

Under the Advanced tab in Add knowledge, another option is available: Bing Custom Search.

Bing Custom Search:
Bing Custom Search allows you to control how your Copilot Studio agent retrieves information from the internet by limiting it to search only trusted public websites that that you explicitly approve. Rather than performing a broad web‑wide search, the agent uses Bing to retrieve information only from the domains, sub‑paths, or individual webpages you configure.

When a user asks a question, Copilot Studio generates an optimised search query and sends it to Bing Custom Search. The response is then grounded only in content from your approved sources, helping ensure accuracy and governance.

When adding websites directly using the Public websites knowledge option, there are platform limits:

• In classic orchestration, you can add up to 4 public website URLs
• In generative orchestration (enabled by default), this increases to 25 public website URLs

Bing Custom Search is useful when knowledge is spread across many trusted external domains, as it allows you to manage significantly more approved sources within a single custom search configuration, rather than adding each URL individually in Copilot Studio. A single Bing Custom Search instance can include up to 400 configured web slices, such as domains, sub‑paths, or individual pages.

To use Bing Custom Search, you first create a custom search instance by visiting https://customsearch.ai
and signing in with a Microsoft account (for example, @hotmail @outlook or another Microsoft backed account). After adding and publishing your approved websites, you copy the Custom Configuration ID from the Production tab and paste it into Copilot Studio when adding Bing Custom Search as a knowledge source.

Summary:

SharePoint = Internal documents such as policies, PDFs, or Word files.
Dataverse = Structured business data stored in tables (for example employee records or support cases)
Dynamics 365 = Business applications (such as CRM systems) that store ana manage their data in Dataverse
Public Websites = Specific websites your agent is allowed to access
Bing Custom Search = A controlled search across multiple approved websites. A controlled search across multiple approved websites

Important clarification: “Add knowledge” vs “Copilot connectors”

The Add knowledge options in Copilot Studio refer to knowledge sources that an individual agent can use to ground its generative answers. These sources are configured directly within Copilot Studio and define where the agent is allowed to look for information when responding to users. Examples include SharePoint, Dataverse, Public websites, and Bing Custom Search.

Microsoft 365 Copilot connectors (such as Synced or Federated connectors) which I briefly mention earlier are a separate capability. They are used to extend Microsoft 365 Copilot and Microsoft Search across Microsoft 365 experiences and are configured centrally by administrators in the Microsoft 365 Admin Center (admin.microsoft.com → Copilot → Connectors), rather than within Copilot Studio.

Synced connectors ingest and index third‑party content into Microsoft Graph so that it can participate in semantic indexing and discovery across Microsoft 365 Copilot experiences. Microsoft describes synced connectors as crawling and indexing content from external sources into Microsoft Graph so the data becomes discoverable in Copilot and Microsoft Search experiences.

In contrast, federated connectors (Preview at the time of writing) retrieve information in real time using Model Context Protocol (MCP) without indexing external data into Microsoft Graph. This makes federated connectors useful for sensitive or fast‑changing data, while synced connectors are typically more suitable for large knowledge repositories where broad discovery and consistent grounding is required.

Note: Federated connectors are currently available in early access preview and may not appear in all Microsoft 365 tenants.

For more information, see Microsoft’s overview of Copilot connectors (synced vs federated):
https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/overview

16. I’ll now add documents from SharePoint. Click SharePoint.

17. From here, you can either browse for content or paste a SharePoint URL directly.

18. Browsing allows you to select individual files, folders, or document libraries from SharePoint, as shown in the image below.

19. I’ll add the SharePoint URL that contains all of the policy documents.

Note: SharePoint knowledge sources are only available to authenticated users. If a user interacting with the agent does not have permission to a specific file or location in SharePoint, the agent will not be able to access or use that content when generating a response.

After adding the URL, the SharePoint knowledge source displays an error:

Error details: No SharePoint connection was found in this environment. The knowledge source cannot access SharePoint content. Recommended action: Please add a SharePoint connection to this environment and re-authenticate.

This error indicates that no active SharePoint connection has been configured for the Copilot Studio environment yet. In other words, although the URL is valid, Copilot Studio cannot currently authenticate to SharePoint to retrieve the content.

This is expected behaviour if a SharePoint connection has not previously been set up or if the existing connection has expired. Once a SharePoint connection is added to the environment and authentication is completed, the knowledge source will be able to access the SharePoint content and move into a Ready state.

There are several ways to create the required SharePoint connection. In this example, I’ll create the connection using the Power Apps portal.

• Go to https://make.powerapps.com
• In the top‑right corner, make sure you select the same environment that your Copilot Studio agent is using
• From the left‑hand navigation, select Connections
• Click + New connection
• Choose SharePoint from the list
• Sign in using an appropriate account (for example, an admin or service account)

This creates a SharePoint connection within the selected environment. Copilot Studio automatically detects the new connection, typically within a minute, and the SharePoint knowledge source status updates to Ready, as shown in the image below.

20. Let’s test the agent again. Click the + icon in the test pane to start a new conversation.

I’ll run the same prompt as before:

“What mandatory training do I need to complete and by when?”

This time, the agent is able to respond successfully. Because the SharePoint knowledge source is now connected and in a Ready state, the agent retrieves the required information from the policy document stored in SharePoint and uses it to generate an accurate, grounded response.

It also includes clear attribution, showing which SharePoint document the information was retrieved from. This helps users understand where the answer came from, reinforces trust in the response, and makes it easy to verify or follow up by opening the source document directly.

21. Next, let’s explore the tools available under the Knowledge section. Click Add tool.

22. Here are the tools available to me.

I’ll briefly explain what each tool does.

Agent Flow

Agent flows are structured, deterministic (meaning they follow a fixed, predefined set of steps and produce the same outcome every time given the same input), step‑by‑step automations that an agent can run to complete tasks reliably. They follow a defined sequence of actions and rules, ensuring consistency and predictability rather than generative reasoning. Agent flows can be triggered on demand by an agent, on a schedule, or in response to specific events.

Agent flows are typically used when a business process must be handled consistently and predictably, rather than relying on generative AI behaviour alone.

Use case 1:
HR policy advisor agent

When a user asks, “How do I request parental leave?”, an agent flow can be triggered to collect the required details (such as dates and type of leave) and then submit the request by creating a ticket, starting an approval process, or sending a notification email.

Use case 2:
Operations/administration 

Agent flows can automate repeatable operational processes, such as creating a case, notifying a team in Microsoft Teams, and logging the interaction. This ensures the same steps are followed every time, improving reliability, auditability, and governance.

Note:
Agent flows can also make use of hundreds of built‑in actions and connectors available through Power Automate. This allows an agent to interact with both Microsoft and third‑party services as part of a structured workflow.

Common examples include adding data to an Excel file, creating or updating records in third‑party applications, sending emails via Outlook, posting messages to Microsoft Teams, copying files from one folder to another in SharePoint or OneDrive, starting and managing approval processes, creating or updating tasks in tools such as Planner, and generating documents from templates and storing them in SharePoint or OneDrive. Because these actions can be executed as part of an agent flow, they run in a predefined, deterministic sequence, ensuring the process is carried out consistently every time.

Prompt

This concept is easiest to understand with an example.

Example 1 – Prompt Tool:
An employee asks the HR Policy Advisor agent:

“Can I book more than 3 weeks leave?”

The agent identifies the user by retrieving their profile from Microsoft Entra ID (via the Office 365 Users connector), including details such as their location and manager.

Next, the agent checks the HR leave policy using a knowledge source, such as SharePoint, where the organisation’s policy documents are stored.

In this scenario:

• Their manager is David Smith
• The employee is based in the UK

Based on the policy, the agent responds:

“Hi Imran, I can see you’re based in the UK and are entitled to a maximum of 3 weeks’ annual leave. Anything beyond this requires manager approval. Would you like me to draft an email to David Smith requesting approval?”

If the employee agrees, the agent asks for additional details, such as the requested leave dates and the reason for the extended leave.

How the Prompt Tool is used

The Prompt Tool takes the structured information gathered during the conversation, for example:

• Employee name
• Manager name
• Leave dates
• Reason for the request

and transforms it into a consistent, well‑written output based on predefined instructions.

For example, the following prompt could be added to the agent using the Prompt Tool in Copilot Studio:

“Write a professional email from the employee to their manager requesting approval for extended annual leave. Include the employee name, manager name, leave dates, and reason. Address the manager appropriately and sign off from the employee.”

The Prompt Tool is used to transform structured data gathered during the interaction into a consistent, well‑written output, such as an email, message, or document, based on predefined instructions.

Example 2 – Prompt tool

Prompt Tools can also be used when an agent needs to understand, analyse, or extract information from documents, such as invoices, receipts, or reports.

For example, a user uploads an invoice and asks:

“Can you extract the supplier name, invoice number, total cost and due date from this document?”

The agent receives the uploaded file and passes the contents of the invoice to a Prompt Tool for processing.

The Prompt Tool analyses the document and extracts the required information based on predefined instructions, returning the results in a structured format.

For example, the Prompt Tool could be configured with the following instructions:

“You are an accounts assistant.
From the uploaded invoice document, extract the following information:
– Supplier name
– Invoice number
– Invoice date
– Total amount
– Due date
Return the information in a clear and structured format.
If a value cannot be found, state this explicitly.”

The agent can then return a response such as:

• Supplier Name: Contoso Ltd
• Invoice Number: INV‑10421
• Invoice Date: 28/03/2026
• Total Amount: £2,450
• Due Date: 28/12/2026

Prompt Tools – Other Common Use Cases

Prompt Tools can be used across a wide range of business scenarios where an agent needs to generate, interpret, transform, or structure content. Common examples include:

• Custom summarisation – summarising a policy document into plain English for an employee
• Image description – explaining what a user has uploaded (for example, identifying that an image is a receipt)
• Information extraction – extracting key details such as supplier name, invoice number, or due date from a document
• Document creation – generating a report, letter, or approval email based on user‑provided information
• Chart generation – turning extracted sales or performance data into a simple chart‑ready format
• Email replies – drafting responses to customer or internal enquiries in a consistent tone
• Content classification – identifying whether a document is, for example, a contract, invoice, or policy
• Data reshaping – converting unstructured or extracted data into a structured format such as a table or list
• and many more.

In each of the scenarios above, the Prompt Tool allows you to define a prompt that the agent runs to transform information into a clear and usable output.

The image below shows an example of a Prompt Tool configured to analyse an uploaded image and generate an output in a humorous and poetic style. The Prompt Tool also allows you to upload sample data, enabling you to test whether the prompt produces the expected result before deploying it as part of your agent.

In this example, a sample image has been uploaded to validate that the prompt correctly analyses the uploaded file and generates a creative description based on the predefined instructions provided by the maker.

Sample image of rabbit below

It is also possible to configure which AI model is used by a Prompt Tool. This allows you to experiment with different models and select the one most suitable for your scenario, such as optimising for creativity, accuracy, or reasoning capability.

As shown in the image below, the maker can choose the model to be used by the Prompt Tool and test the prompt against sample input. This makes it easy to compare outputs across models and validate that the selected model produces the desired result before the Prompt Tool is used within the agent.

Model Context Protocol (MCP)

Model Context Protocol (MCP) is an open standard introduced by Anthropic in November 2024 to help AI agents connect to external business systems such as databases, ticketing platforms, and collaboration tools.

A simple way to understand MCP is to think of it as a USB‑C connector for AI. Just as USB‑C provides a single, standard way to connect different devices, MCP provides a standard way for AI applications such as Microsoft Copilot to connect to business systems, access their data, or perform tasks, without requiring a completely bespoke integration for each system.

AI agents are good at conversation, but they don’t automatically know how to interact with your business applications (such as HR systems, Jira, or service desks). MCP (Model Context Protocol) was introduced as a standard way for AI tools to connect to those systems, rather than needing a custom integration every time.

In Copilot Studio, you can connect to apps using built‑in connectors or APIs, but MCP is useful when you want a more “plug‑and‑play” approach where an MCP server publishes a set of tools the agent can use, and Copilot Studio can automatically discover and use those tools over time. As those tools evolve, the MCP server can surface changes centrally, without requiring you to manually rebuild integrations for each agent over time.

Example: Jira MCP Server

Jira is a widely used work management and issue‑tracking system. Atlassian (the company behind Jira) has released an official Jira MCP Server, which allows AI assistants to securely access Jira data and create or update issues on behalf of users.

Although Copilot Studio provides built‑in connectors for Jira, these typically require you to manually configure individual actions—for example:

• Create an issue
• Update a ticket
• Check issue status

Each action also needs to be configured with specific inputs such as issue title, description, priority, or assignee. If Jira introduces new capabilities, these changes must be manually configured for each agent.

With MCP, the agent connects instead to a central Jira MCP Server. This server publishes Jira’s available capabilities as tools that Copilot Studio can automatically discover and use. If new Jira capabilities are added in the future, the MCP server can expose them centrally, allowing multiple agents to benefit without manual reconfiguration.

In short, with MCP, you connect once to a Jira MCP Server and gain access to multiple Jira tools (such as searching, creating, or updating issues), rather than configuring each action individually inside every agent.

In simple terms, an MCP server doesn’t just list what actions are available. It also handles the hard work behind the scenes, such as finding the right data, checking permissions, and applying rules. This lets the agent focus on using the tools, without needing complex configuration or prompts.

The screenshot below shows several Jira tools available in Copilot Studio that can be added manually. It also shows that you can connect to the Jira MCP Server instead. After connecting, specific tools exposed by the MCP server can be enabled or disabled based on your requirements.

Example: Microsoft Learn MCP Server

Another example is Microsoft Learn, which also provides an MCP Server.

If I added the public Microsoft Learn website address as a knowledge source, the agent would rely on indexed or stored copies of documentation. This means responses could be based on information that is slightly out of date.

By connecting to the Microsoft Learn MCP Server instead, the agent can query Microsoft’s documentation live, at runtime, using a structured interface. This allows the agent to retrieve the latest guidance directly from Microsoft Learn whenever a user asks a question.

As a result, the agent can provide:

• more up‑to‑date information
• more accurate answers
• responses that reflect the current state of Microsoft documentation

rather than relying on pre‑indexed content or the model’s existing knowledge.

Connect to your own MCP Server

You can also create your own MCP Server for internal systems or products and connect it to Copilot Studio. This allows your organisation to publish custom tools that agents can use securely, without having to build or configure separate integrations for each agent.

Rest API

Let’s move on to the Rest API tool

You may wonder why you would choose to use a REST API Tool if built‑in connectors or MCP Servers are available.

In many cases, these pre‑built or simplified integrations may not exist yet for the system you want to connect to. However, the system may still expose a REST API, which allows external applications to communicate with it securely.

For example, your organisation may have an internal HR system, customer booking platform, or finance application which provides API access but does not have a built‑in connector or MCP Server available. REST APIs act as a standard interface between applications, allowing systems to exchange data and trigger actions.

By using the REST API Tool in Copilot Studio, you can configure your agent to:

• Retrieve data from external systems
• Submit or update information
• Trigger processes within another application

without manual intervention.

Use Case Rest API Copilot Studio – Example 1 (Internal System)

For example, your organisation may use an internal equipment booking system that allows employees to reserve laptops or meeting rooms. While this system might not have a Copilot Studio connector or an MCP Server available, it may still expose a REST API endpoint.

Using the REST API Tool in Copilot Studio, the agent can call this API to:

• check equipment or room availability
• create a new booking
• retrieve existing reservations

on behalf of the employee.

This allows the agent to interact with internal systems that already expose APIs, even when no pre‑built integration is available.

Use Case Rest API Copilot Studio Example 2 (Third‑Party Application)

Similarly, your organisation may use a third‑party e‑commerce platform to track customer orders. If this platform provides API access, the agent can use the REST API Tool to retrieve information such as order status or update delivery details.

For example, a user could ask:

“What is the status of my order?”
or
“Can you update the delivery address for my order?”

API integrations like this allow organisations to connect systems and automate processes in near real‑time, helping to reduce manual effort and improve operational efficiency.

When REST APIs are typically used:

• a built‑in connector is not available
• an MCP Server has not been provided
• an internal or third‑party system exposes API access

Custom Connector

While the REST API Tool allows your agent to connect directly to an external system, a Custom Connector is useful when you want to create a reusable integration that can be used across multiple agents or solutions within your organisation.

A Custom Connector acts as a wrapper around a REST API and allows Microsoft Power Platform services such as Copilot Studio, Power Apps, Power Automate and Power Pages to securely communicate with internal or external systems using a shared set of actions and authentication rules.

Instead of configuring the same REST API calls separately in each agent or application, a Custom Connector lets you define the integration once. This includes:

• expected outputs
• available actions
• required inputs
• authentication methods

That connection can then be reused across multiple solutions.

For example, Imran works in HR and frequently needs to retrieve payroll information when employees ask questions about salary adjustments or overtime payments. The organisation’s internal payroll system exposes a REST API which does not have a built‑in Copilot Studio connector or an MCP Server.

Initially, this integration could be set up using the REST API Tool inside a single HR agent. However, other solutions, such as a Payroll Advisor agent, an internal Power App, or an external Power Pages website may also need access to the same payroll system.

If the REST API Tool were used directly, each solution would need its own copy of the same API configuration. Instead, a Custom Connector can be created to define this integration once and store it centrally within the Power Platform environment.

Where Custom Connectors are created

When selecting the Custom Connector option within Copilot Studio, you may notice that you are redirected to the Power Apps Maker Portal. This is expected, because Custom Connectors are not created directly inside Copilot Studio. They are part of the wider Microsoft Power Platform and are managed at the environment level.

Once created, the same Custom Connector can be reused by:

• Copilot Studio agents
• Internal Power Apps
• External Power Pages websites
• Power Automate workflows
• Logic Apps

without needing to configure the REST API integration separately within each solution.

Computer Use

Next, let’s move on to Computer use, as shown in the images below.

So far, we’ve seen how agents can use tools to send emails, retrieve data, or integrate with third-party applications such as ServiceNow using connectors, REST APIs, or MCP. However, many organisations still rely on legacy systems which do not support modern integrations. These may include older desktop applications or internal web based systems that are too costly or complex to redesign and do not expose APIs or MCP servers.

For example, employees might currently need to manually copy invoice details from a Word or PDF document into a legacy invoice management system, such as the one shown below. (Image source: Microsoft Events)

In many organisations, this type of manual process could involve processing hundreds or even thousands of invoices every month.

With the Computer Use in Copilot Studio, an agent can interact directly with applications in the same way a human would, by using a virtual keyboard and mouse to control what appears on screen. This allows agents to automate tasks even when no API integration exists.

Example: Automating invoice entry in a legacy system

Using Computer use, you could configure your agent to monitor a shared mailbox for incoming invoices. When a new invoice arrives, the agent can:

• open a legacy desktop application or browser‑based system
• sign in using securely stored credentials (for example, via a secure credential store or Azure Key Vault)
• copy invoice details from the uploaded document
• enter the information into the system
• save the record and move on to the next invoice

The agent navigates the application by clicking buttons, entering text, and interacting with the user interface exactly as a person would. If required information is missing or unclear, the agent can pause the process and notify a human by sending an email or message, supporting human‑in‑the‑loop supervision.

Copilot Studio: Where Computer use can run

Computer use can run on different machine types, including:

• a hosted browser environment
• a Windows machine registered for Computer use
• a Windows 365 Cloud PC

This flexibility allows organisations to automate legacy processes without modifying their existing applications.

Publish agent to Microsoft 365 Chat and Teams

Finally, let’s look at how to make your agent available to users in Microsoft 365 Copilot chat and Microsoft Teams.

Once you’ve configured your agent’s instructions, knowledge sources, and tools, the next step is to publish it. Publishing applies the latest version of your agent and makes it ready to be used in Microsoft 365 Copilot experiences and other supported channels.

Think of Publish as deploying the agent so it can be accessed outside of Copilot Studio. Users will only see the most recently published version of your agent.

To publish your agent:

1. In Copilot Studio, open your agent
   
2. Select Publish
   
3. Confirm to make the latest version available.

4. After clicking Publish, you’ll be prompted to add some additional details, such as:

• the developer name
• a short description of the agent

5. Once completed, click Publish.
The publishing process usually completes in under a minute.

6. Configure user access
After publishing, you’ll need to decide who can access the agent. At this stage, you can either grant access to specific users or groups or click Copy link to test the agent yourself.

Note: To make an agent available to the entire organisation, an administrator must approve the request in the Microsoft 365 admin centre: admin.microsoft.com → Agents (left navigation) → Requests

Granting permissions to individual users or groups does not require admin approval. Admin approval is only required when making the agent available to the entire organisation, as shown in the image below.

The owner or maker of the agent is automatically granted full control. If I were to select a different user or group, I could configure specific permissions, such as whether they are allowed to view, edit, configure, share, publish, or delete the agent.

7. Click Copy

8. Open a web browser and paste the link.
Sign in using an account that has permissions to access the agent.

After a few seconds, you’ll be prompted to add the agent as shown in the image below.

Success. The agent has now been added to my Microsoft 365 Copilot Chat.

The agent is also visible in the agent store, making it easy for authorised users to find and access it.

Note: If you make any changes to the agent in Copilot Studio, you must publish again. After publishing, updates can take 5–15 minutes to appear consistently across Microsoft 365 Copilot experiences.

9. You can optionally pin the agent, so it appears in the left‑hand navigation for quick access. Alternatively, you can invoke the agent directly within Microsoft 365 Copilot Chat by typing the @ symbol followed by the agent’s name, and selecting it from the list.

To validate the behaviour, I asked the agent an off‑topic question, such as:

“Can you help me bake a chocolate cake?”

Result: The Policy Advisor agent correctly declined to help, as expected, in line with the instructions and scope defined earlier.

When asked questions related to internal policies, the agent responds correctly.

I hope you found this post useful.

If you have any feedback or questions, please feel free to leave a comment below.

See you in the next post