**Building Microsoft Copilot Agents

for Retail — From First Agent to Full Governance**

A practical implementation guide with real retail use case — Copilot Studio, connectors, extensibility, and governance from admin center to agent lifecycle

Building an Enterprise Store Operations Copilot with Microsoft Copilot Studio

A store manager at a 500-store retail chain started every morning the same way.

Before the store opened, she needed four pieces of information:

• The latest shelf layout for the grocery section
• The SOP for processing customer returns
• Current inventory for fast-moving products like Amul Milk, Aashirvaad Atta, and Fortune Sunflower Oil
• The promotional offers and discounts scheduled for the upcoming weekend

Individually, none of this information was hard to find.

The challenge was that it was stored in four different systems.

• The planogram was in SharePoint.
• The returns SOP was on a different SharePoint site.
• Inventory data came from Microsoft Dynamics 365.
• Promotional schedules arrived through email.

By the time she collected everything needed, about 35 minutes had passed before she could start her actual work.

Now multiply that across 500 stores, twice a day.

That adds up to over 580 employee hours lost every day, simply because operational knowledge was scattered across systems.

This wasn’t a data issue.

It also wasn’t an AI issue.

It was a problem with access to knowledge.

The organization already had everything in place.

• Microsoft 365
• Microsoft Teams
• SharePoint
• Dynamics 365
• Well-documented business processes

Employees struggled not because the information didn’t exist.

They struggled because they had to remember where to find it.

This led to a straightforward question:

Should we create a new AI application, or should we enhance the tools employees already use every day?

We chose the second option.

Instead of adding another application, another URL, another login process, and another training program, we built a Store Operations Copilot Agent using Microsoft Copilot Studio.

The assistant was integrated directly into Microsoft Teams, allowing store managers to interact with it as if it were a colleague.

They could simply ask:

• “Show me today’s shelf layout for the grocery section.”
• “What’s the SOP for customer returns?”
• “Do we have enough Amul Milk in stock?”
• “What offers start this weekend?”

Behind the scenes, the agent got information from SharePoint, queried Dynamics 365 for live inventory, and found operational documents from the returns management system — all while following existing Microsoft 365 permissions and rules.

There was:

• No new application to install
• No extra credentials to remember
• No separate knowledge base to maintain

Minimal user training beyond one simple instruction:

“Ask it in Teams the same way you’d ask another store manager.”

That small change changed how employees interacted with operational knowledge.

Instead of navigating multiple systems, they used a single conversational assistant that managed information retrieval across enterprise systems.

This article outlines the complete implementation journey — from designing the first Copilot Studio agent to connecting enterprise data sources, setting up security and rules, and managing the agent lifecycle using the Microsoft 365 Admin Center and Microsoft Purview.

What Microsoft Copilot Extensibility Actually Gives You

Before building, understand what the extensibility model offers. Microsoft provides three ways to extend what Copilot can do — and choosing the wrong one adds weeks of unnecessary complexity.

1. Declarative Agents — Customize Copilot’s Behaviour

A declarative agent is a customised version of Microsoft 365 Copilot. You define its persona, its scope, its knowledge sources, and its available actions — and Copilot’s underlying AI does the rest. No custom model. No custom inference. You are configuring Copilot’s behaviour, not replacing it.

Use a declarative agent when: your use case fits within Microsoft 365 Copilot’s existing capabilities, you want to restrict Copilot to a specific domain (store operations, HR queries, supplier communication), and you want to deploy quickly without building AI infrastructure.

**What we built: **A declarative agent called ‘Store Ops’ scoped specifically to store operations. It only had access to store operations SharePoint sites, D365 inventory data, and the returns management API. A store manager asking Store Ops about a competitor’s pricing strategy got a clean response: ‘I am scoped to store operations. For competitive intelligence, please contact the category management team.’ Scope enforcement is not a guardrail you add later. It is the first configuration decision.

2. Custom Engine Agents — Bring Your Own AI

A custom engine agent replaces Copilot’s AI with your own model or orchestration logic. You control everything: the model, the reasoning, the tool selection, the response format. It surfaces in Teams or as a web app via Copilot Studio, but the intelligence is yours.

Use a custom engine agent when: you need a model fine-tuned on domain-specific data, your orchestration logic is complex enough to require Semantic Kernel or LangChain, or the use case requires capabilities beyond what Copilot’s underlying AI supports.

Custom engine agents require significantly more build time, ongoing model management, and Azure AI infrastructure. For most retail use cases — knowledge retrieval, process guidance, operational queries — a declarative agent with well-configured knowledge sources will outperform a custom engine agent built hastily. Start declarative. Move to custom engine only when you hit a specific capability wall.

3. Connectors and Plugins — Extend What Copilot Knows and Can Do

Connectors and plugins are how you connect Copilot to data and systems outside Microsoft 365.

• Microsoft Graph Connectors index external content — SharePoint on-premises, supplier portals, ServiceNow, Confluence, custom databases — into Microsoft Graph. Once indexed, that content is searchable by Copilot the same way Microsoft 365 content is. This is how you make Copilot aware of data that does not live in Teams or SharePoint Online.
• Power Platform Connectors connect Copilot agents to external APIs and systems via Power Automate. Used for write actions: creating records in D365, submitting orders, updating inventory flags.
• API Plugins give Copilot real-time access to external APIs. Unlike Graph connectors which index content, API plugins call live endpoints at query time. Used when the data changes too frequently to index — inventory levels, order status, live pricing.

Why We Chose Copilot Studio

When designing enterprise AI solutions, the first instinct is often to build a custom application using Azure AI Foundry, Azure OpenAI, or a web framework. While those approaches offer maximum flexibility, they also require you to build and maintain everything yourself — from the user interface and authentication to conversation orchestration and integrations.

For our retail operations assistant, that wasn’t the problem we were trying to solve.

Our users were already working in Microsoft Teams. Their documents lived in SharePoint. Business data was available through Dynamics 365, and user identities and permissions were already managed by Microsoft Entra ID.

Instead of creating another application, we wanted to bring AI into the workspace employees already used every day.

That made Microsoft Copilot Studio the natural choice.

Our Design Requirements

Before selecting a platform, we defined the capabilities the solution needed to provide.

Building the Store Operations Agent — Step by Step

Here is the exact sequence I followed to build the Store Ops agent. Prerequisites: Microsoft 365 Copilot licences assigned to the target users, Copilot Studio access enabled by the M365 Admin, and the SharePoint sites that will serve as knowledge sources already structured and populated.

STEP 1 — Create the Agent in Copilot Studio

Navigate to Copilot Studio (copilotstudio.microsoft.com). Select Create → New Agent. Give the agent a name, a description, and — critically — an instruction set. The instruction set is the agent’s operating brief: what it does, what it does not do, how it should respond when it cannot answer.

The instruction set I used for Store Ops:

You are Store Ops, a store operations assistant for [Retailer] store managers.
You help with: inventory queries, standard operating procedures, planogram
guidance, promotional calendar information, and supplier return processes.
You do not answer questions about: competitor pricing, HR personal data,
financial performance, or anything outside store operations scope.
Always cite the source document when providing SOP or planogram guidance.
If you cannot find a reliable answer, say so clearly and direct the user
to the relevant team rather than guessing.

The instruction set is your first governance control. It defines the agent’s boundaries before any technical control is applied. Write it precisely — the agent follows it literally.

STEP 2 — Add Knowledge Sources

Knowledge sources are the documents and sites the agent can read and reference when answering questions. In Copilot Studio, select the Knowledge tab and add sources.

For Store Ops, three knowledge source types:

• SharePoint sites the store operations SharePoint site (SOPs, planograms, training materials), the HR policy site (store-level policies only — not personal HR data), and the promotional calendar site. Added by URL directly in Copilot Studio. Copilot respects the permission model of the SharePoint site — a store manager can only get information from documents they already have permission to read.
• Uploaded files the current season’s planogram PDFs and the supplier return SOP, uploaded directly into the agent’s knowledge base for fast retrieval without navigating SharePoint.
• Public websites the supplier portal’s public product specification pages, added as a web URL knowledge source for product spec queries.

**Critical insight: **Copilot’s knowledge retrieval honours SharePoint permissions automatically. A store manager cannot use the agent to access documents their SharePoint permissions exclude them from. This is not an agent-level control you configure — it is inherited from the Microsoft 365 permission model. Govern your SharePoint permissions correctly and the agent’s knowledge access is governed correctly by extension. If your SharePoint permissions are messy, clean those up before you add them as knowledge sources.

STEP 3 — Connect to Live Data with Connectors

Knowledge sources cover static or slow-changing content. Live operational data — inventory levels, order status, current pricing — requires connectors that call systems at query time.

1. D365 Connector for Inventory

In Copilot Studio, select Actions → Add an Action → Choose a connector. The Microsoft Dynamics 365 connector is available natively. Configure it to call the inventory availability endpoint. Define the input parameters the agent should collect from the user (SKU ID or product name, store location) and the output fields to surface (available quantity, last updated timestamp, warehouse location).

Test the action in Copilot Studio’s test panel before publishing. Ask: ‘What is the current stock level for SKU 4821 in Store 042?’ The agent should collect the SKU and store identifier from the conversation, call the D365 connector, and return the live inventory figure with a timestamp.

2. API Plugin for Returns Management

The returns management system had no native Copilot connector, so I built an API plugin. In Copilot Studio, select Actions → Add an Action → Build a custom connector. Define the API endpoint, the authentication method (OAuth 2.0 for this system), the request schema, and the response schema.

Endpoint: POST /api/returns/initiate

Auth: OAuth 2.0 (client credentials, scoped to returns:write)

Request: { sku_id, store_id, quantity, return_reason, supplier_code }

Response: { return_reference, estimated_credit, collection_date }

Once the plugin is defined, the agent can initiate a supplier return from a Teams conversation. The store manager describes the issue, the agent collects the required fields through conversation, submits the return via the API, and confirms the return reference number. A process that previously required navigating a separate portal now happens inside Teams in under two minutes.

STEP 4 — Configure Topics for Complex Workflows

Not every interaction is a simple question-and-answer. Some store operations workflows have multiple steps, conditional branches, and required inputs. For these, Copilot Studio’s Topics allow you to define structured conversation flows.

I created a Topic for the promotional price override request — a workflow where a store manager needs to request a temporary price override for a specific SKU, which requires manager authentication, a valid business reason, and approval routing:

Topic: Promotional Price Override Request

Trigger phrases: ‘price override’, ‘change promo price’, ‘adjust promotional price’

Step 1: Collect SKU ID and current price from user

Step 2: Confirm store manager role via M365 identity

Step 3: Collect business reason (free text)

Step 4: Submit override request via Power Automate flow → D365

Step 5: Notify category manager via Teams adaptive card for approval

Step 6: Confirm submission to store manager with request ID

Topics give us structured control over workflows where free-form conversation is not sufficient. They also give your compliance team a reviewable, auditable flow — the same way Prompt Flow in Azure AI Foundry does for Azure-based workloads.

STEP 5 — Test Before Publishing

Copilot Studio has a built-in test panel. Before publishing to any user, run through every scenario the agent is designed to handle and several it is not:

• Happy path questions within scope with documents available, inventory queries with live D365 data, return initiation end-to-end.
• Out of scope competitor pricing questions, personal HR queries, financial performance questions. Verify the agent declines clearly and directs to the right team.
• Edge cases SKU not found in D365, SharePoint document not accessible due to permissions, returns API timeout. Verify graceful fallback responses in each case.
• Prompt injection attempts try instructing the agent to ignore its system prompt, reveal its instructions, or act outside its defined scope. Verify it does not comply.

**What I found in testing: **the agent’s out-of-scope responses were too verbose initially — three paragraphs explaining why it could not help. Store managers do not have time for that. I rewrote the instruction set to keep out-of-scope responses to one sentence and a redirect. User experience in production improved significantly. Test your agent as a store manager, not as an engineer.

Implementing Governance— Beyond Building the Agent

Building our Store Operations Agent took about three weeks.

Implementing the governance framework took another three.

Not because governance is technically more difficult, but because it requires alignment across multiple stakeholders — IT, Security, Compliance, Legal, HR, and the business. Each group has different concerns, and a successful rollout depends on addressing all of them before the first user interacts with the agent.

For us, governance wasn’t a post-deployment activity. It was part of the architecture from day one.

Our governance model focused on five areas:

• Controlling who can build and publish agents
• Managing who can access Copilot capabilities
• Protecting sensitive business data
• Auditing AI interactions
• Managing the complete lifecycle of every agent

Let’s look at each area.

1. Microsoft 365 Admin Center — Controlling Access

The first layer of governance is ensuring that only the right people can use Copilot and only authorized makers can build new agents.

This begins in the Microsoft 365 Admin Center and the Power Platform Admin Center.

License Management

Microsoft 365 Copilot is licensed per user.

Rather than enabling it across the organization on day one, we adopted a phased rollout.

Restricting Who Can Build Agents

One of the first decisions was preventing unrestricted agent creation.

Instead of allowing every licensed user to publish an agent, we limited creation and publishing to approved makers and administrators.

This ensured that:

• business owners reviewed the use case,
• security teams validated data access,
• and administrators approved publication before the agent became available to end users.

Think of this as the AI equivalent of a production deployment approval.

2. Agent Publishing and Catalog Management

Publishing an agent should be treated like releasing any other enterprise application.

Once approved, agents become discoverable through Microsoft 365 and can be assigned to specific user groups.

For every published agent we tracked:

• Business owner
• Technical owner
• Target audience
• Version
• Deployment date
• Usage metrics
• Retirement date

Maintaining an inventory of deployed agents becomes increasingly important as organizations move from one or two pilots to dozens of business-specific assistants.

3. Microsoft Purview — Governing Enterprise Data

If the Microsoft 365 Admin Center governs who can use AI, Microsoft Purview governs what AI can access and expose.

This is where enterprise data governance becomes critical.

Sensitivity Labels

Operational documents rarely have the same level of confidentiality.

A merchandising guide should be treated differently from an employee salary document or a legal investigation report.

We standardized document classification using sensitivity labels such as:

By classifying documents consistently, Copilot respects the organization’s existing governance policies rather than relying solely on folder structures or manual permissions.

Data Loss Prevention (DLP)

Not every piece of accessible information should appear in an AI response.

For example:

• Employee salary information
• National identification numbers
• Banking details
• Supplier commercial agreements
• Financial forecasts

Data Loss Prevention policies help reduce the risk of sensitive information being surfaced or shared inappropriately.

Typical policies included:

• Prevent responses containing personally identifiable information (PII)
• Restrict finance data to authorized finance roles
• Monitor interactions involving confidential business documents

4. Auditing Copilot Activity

Enterprise AI must be auditable.

Every production deployment should include a strategy for reviewing AI activity.

Using Microsoft Purview audit capabilities, administrators can investigate questions such as:

• Which users interacted with the Store Operations Agent?
• Which documents were referenced?
• Were confidential documents involved?
• When did a particular interaction occur?

These audit records become invaluable during security investigations, compliance reviews, and operational troubleshooting.

5. Managing the Agent Lifecycle

Deploying an agent is only the beginning.

Publishing Checklist

Before approving a production release, we validated:

• Business instructions accurately reflected the intended scope
• Knowledge sources were reviewed and current
• Sensitive documents were correctly classified
• Authentication for connectors followed least-privilege principles
• Data protection policies had been validated
• Target user groups and licensing were confirmed
• An ongoing business owner was assigned

Treat this checklist as a release gate rather than a documentation exercise.

Version Management

Business processes evolve continuously.

New SOPs are published.

Promotions change.

APIs are updated.

Rather than rebuilding the agent, we refreshed the underlying knowledge sources, validated the changes, and published a new version.

Maintaining version history provided traceability and simplified rollback if issues were discovered after deployment.

Monitoring Adoption

Governance doesn’t end once the agent is live.

We reviewed adoption metrics regularly, including:

• Active users
• Number of conversations
• Most common questions
• User feedback
• Escalation rates

One of the most valuable indicators was the trend in negative feedback.

In one deployment, a sudden increase in dissatisfaction around inventory queries led us to discover that a backend API response had changed. The agent itself hadn’t failed — the integration had drifted.

Monitoring user interactions allowed us to detect and resolve the issue before it became a widespread operational problem.

Decommissioning

Every enterprise AI solution eventually reaches the end of its lifecycle.

When an agent is retired:

• Unpublish the agent.
• Remove unnecessary connector credentials.
• Disable or remove associated service accounts.
• Archive configuration and documentation according to retention policies.
• Update the enterprise agent inventory.

An abandoned AI agent with outdated knowledge, excessive permissions, or forgotten service accounts presents the same governance risks as any unmanaged enterprise application.

Governance Is an Architectural Concern

The success of enterprise AI isn’t determined solely by how intelligently an agent answers questions.

It’s determined by whether the organization can trust it.

That trust comes from well-defined governance: controlled access, protected data, comprehensive auditing, structured lifecycle management, and clear ownership.

In our implementation, governance wasn’t a separate workstream — it was part of the solution architecture from the beginning. That’s what allowed us to scale the Store Operations Agent confidently across hundreds of stores while maintaining compliance and operational control.

What Surprised Me in Production

Shadow IT Agents Appeared Within Two Weeks

Two weeks after the Store Ops agent went live, the IT helpdesk received a report that another agent — not the one we had built — was appearing in Teams for a subset of users in the marketing team. A marketing analyst had discovered Copilot Studio, built an agent connected to their campaign documents, and shared it with their team. The agent had been published without IT review, without DLP policy alignment, and without sensitivity label verification on the campaign documents it referenced.

The agent was not malicious. It was enthusiastic. But it was accessing documents that included supplier commercial terms labelled Confidential, and surfacing that data to junior team members who did not have the permission level those labels required. The Power Platform Admin Center caught it during the weekly agent catalogue review — we had configured the review cadence after the first week specifically because we anticipated this.

The fix: restrict Copilot Studio environment creation to IT-managed environments, enforce admin approval before any agent reaches users, and communicate clearly to the organisation that building agents outside the approved process would result in the agent being immediately unpublished. The marketing agent was rebuilt properly within the governance framework and published two weeks later. The analyst became one of the most engaged participants in the Copilot governance working group.

Knowledge Source Freshness Was the Hardest Problem

The SOPs in SharePoint were supposed to be maintained by the operations team. Three months after launch, a store manager asked Store Ops about the returns procedure for a specific supplier category — and the agent returned guidance based on an SOP that had been superseded six weeks earlier. The updated SOP existed in SharePoint. It had not been indexed by Copilot because the SharePoint crawl schedule had not refreshed that site since the document was updated.

Two lessons from this. First: Copilot’s knowledge currency depends on SharePoint crawl schedules and indexing freshness — check the indexing configuration, not just the document existence. Second: governance of AI knowledge sources is governance of the documents themselves. If the organisation’s document management discipline is weak, the agent’s answer quality will reflect that weakness. We added a monthly knowledge source audit to the agent maintenance process: verify that every SharePoint site in the knowledge base is actively maintained, every document is within its review cycle, and every sensitivity label is current.

What I Got Wrong

Three mistakes that I made on this project and have since seen replicated in every Copilot implementation I have reviewed:

1. I treated the instruction set as an afterthought. The first version of the Store Ops instruction set was two sentences. It defined what the agent did but not what it explicitly would not do, how it should respond when it could not answer, or what it should do when a user tried to push it outside its scope. The instruction set is the agent’s operating contract — it deserves the same care as an SOP or a compliance policy. Write it before you add a single knowledge source.
2. I configured Purview after the agent was live. DLP policies were applied to Copilot interactions in week three, after the agent had already been in production for two weeks. During those two weeks, there was no DLP enforcement on what Copilot could surface — only the SharePoint permission model. For the pilot group of 20 store managers, the risk was manageable. For a 500-store rollout, two weeks without DLP would have been an unacceptable governance gap. Purview configuration is a pre-launch requirement, not a post-launch improvement.
3. I did not define a named agent owner. The Store Ops agent was built by the IT team and then handed to ‘the business.’ Nobody owned the knowledge source review cycle. Nobody owned the usage analytics review. Nobody owned the decision about when to update the instruction set when a business process changed. Three months in, the agent was degrading silently — outdated SOPs, an API plugin response schema that had drifted, a new product category that the agent had no knowledge of. Define a named agent owner before you publish. That owner is accountable for the agent the way a product manager is accountable for a product.

Implementation Checklist — Before We Publish

Use this before publishing any Copilot agent to production users:

Agent Build

• Instruction set written: scope defined, out-of-scope responses specified, citation behaviour configured
• Knowledge sources added: SharePoint permissions verified, sensitivity labels applied to all documents
• Connectors configured: authentication scoped minimally (least privilege), API schemas validated
• Topics created for multi-step workflows: each step tested end-to-end
• Happy path tested: all in-scope scenarios covered
• Out-of-scope tested: sensitive category refusals verified
• Edge case tested: API timeout, document not found, permission denied — all return graceful responses
• Prompt injection tested: agent does not comply with attempts to override instruction set

Governance — Pre-Launch

• M365 Admin Center: Copilot licences assigned to target user group only
• Power Platform Admin Center: environment creation restricted to IT-managed environments
• Power Platform Admin Center: admin approval required before agent publishing — confirmed active
• Purview: sensitivity labels applied to all knowledge source documents
• Purview: DLP policies scoped to Copilot — blocking personal data and Confidential content from unauthorised roles
• Purview: audit logging confirmed active for Copilot workload
• Agent catalogue: agent registered in admin catalogue with owner, purpose, and review date

Lifecycle — Post-Launch

• Named agent owner assigned and briefed on maintenance responsibilities
• Usage analytics review scheduled: weekly for first month, monthly thereafter
• Knowledge source review cycle defined: monthly for high-change documents, quarterly for stable documents
• Version change process documented: who approves knowledge source updates, how new versions are communicated to users
• Decommission plan documented: what happens when this agent is no longer needed

The Right Question to Ask Before Build

Every Copilot agent project I have worked on started with a variation of the same question: ‘Can we build an AI assistant for this?’ That is the wrong question to start with.

The right questions are: What does the user need to do that they cannot do efficiently today? Where does the data and knowledge to support them already exist? What governance controls need to be in place before that data is accessible through a conversational interface? And who is accountable for maintaining the agent after it is live?

For the store operations project, the answers were clear. Store managers needed operational information that existed across four systems and SharePoint sites. The data and knowledge were already there — in M365, in D365, in the returns system. The governance controls were Purview sensitivity labels, DLP policies, and admin-approved publishing. The agent owner was the Head of Store Operations, who had a direct business interest in keeping it accurate and current.

Those four answers, arrived at before a single line of configuration in Copilot Studio, determined everything that came after. The agent works not because the technology is sophisticated. It works because the problem was clear, the data was governed, and the ownership was defined.

Conclusion

Microsoft Copilot extensibility does not give you an AI strategy. It gives you an AI capability within the Microsoft 365 boundary your organisation already operates in. The strategy — which problems to solve, which data to make accessible, which governance controls to apply, which workflows to augment — is yours to define. Get that right, and the technical implementation is the straightforward part.