Managing Microsoft 365 Copilot Connector Connections - Monitoring, Crawls, Errors and Quotas

October 25, 2026•8 min read•Michael Ridland

Building a Copilot connector is the fun part. You define the schema, write the crawler or configure the Microsoft-built connector, watch the first items flow into the index, and then someone asks Copilot a question and it pulls an answer out of your ServiceNow knowledge base or your internal wiki. Everyone's happy.

Then three months later, someone notices Copilot is quoting a policy that was updated in August. The connector stopped syncing six weeks ago. Nobody noticed.

That's the part of the job Microsoft's doc on managing connections is about. It isn't glamorous, and it's where most of the long-term value of a connector is won or lost. For Australian organisations rolling out Copilot, where the business case often depends on Copilot knowing about content outside Microsoft 365, keeping connections healthy matters as much as building them.

A quick refresher on connections

A Copilot connector (previously called a Graph connector) brings external content into the Microsoft Graph index so it shows up in Microsoft Search and Copilot. Each connector instance is a connection. You might have one connection for your Confluence-style wiki, one for a file share, one for a custom line-of-business app, and two separate connections to the same ServiceNow tenant for different knowledge bases.

Each connection has:

A schema defining the properties of each item.
Items, each with content, properties and an access control list.
A crawl or ingestion process that keeps items current.
A state that tells you whether it's healthy.

There are two broad flavours. Microsoft-built and partner connectors are configured and managed through the Microsoft 365 admin centre. Custom connectors you build yourself using the Microsoft Graph connectors API, and you manage them partly through the admin centre and partly through your own code.

Where you manage them

For admins, connections live in the Microsoft 365 admin centre under the Copilot and search settings (Microsoft has moved this around a few times, so if you can't find it, search the admin centre for "connectors"). From there you can see every connection in the tenant, its state, item counts, last crawl time and errors.

The things you can do there:

View connection details, including the schema, the number of indexed items and crawl history.
Edit settings for Microsoft-built connectors, such as the crawl schedule, credentials and which content is included.
Trigger a crawl on demand, either a full crawl or an incremental one.
Pause and resume crawling for some connector types.
Review errors item by item.
Delete a connection, which removes its items from the index.

For custom connectors, you'll also work with the Graph API directly. The externalConnection resource has a state property with values like draft, ready, obsolete and limitExceeded. If you're building a custom connector, that state should be part of your monitoring, not something you look at once during setup.

Connection states and what they mean in practice

In the admin centre you'll see states along these lines:

Ready. Healthy. Items are indexed and searchable.
Syncing or crawling. A crawl is in progress. Normal, unless it stays there for days.
Paused. Crawling has been stopped manually. Content is still searchable, but it's going stale.
Failed. Something broke. Often credentials.
Limit exceeded. You've hit an index quota. New items won't go in.
Delete failed. A deletion didn't complete. Rare, but annoying, and usually needs a retry or a support ticket.

The dangerous one isn't Failed. Failed is loud. The dangerous one is a connection that says Ready but hasn't successfully crawled anything new in weeks because the source system changed its API, or a service account lost access to half the content. The state looks fine. The data is stale. That's why item counts and last successful crawl time matter more than the status icon.

Crawl schedules - get them right for each source

For Microsoft-built connectors, you'll generally set two schedules:

Incremental crawls pick up changes since the last crawl. These should run frequently, from every 15 minutes to every few hours depending on how fast the content changes.
Full crawls reprocess everything, which also catches deletions and permission changes that incremental crawls can miss. These run less often, daily or weekly.

Our rough guidance from projects:

Knowledge bases and policy content change slowly but the cost of stale content is high. Incremental every hour or two, full crawl weekly.
Ticketing systems and CRM data change constantly. Incremental as often as the source system's API rate limits allow.
File shares with large volumes are expensive to crawl. Be careful with full crawl frequency, and check the load on the source server. One client's file server team was not impressed when our first full crawl ran at 10am on a Monday.

The point people miss is permissions. If someone loses access to a document in the source system, you want that reflected in the index quickly, otherwise Copilot might surface content they shouldn't see any more. Not every connector picks up ACL changes in incremental crawls. Read the docs for your specific connector and set the full crawl schedule with that in mind.

Triaging errors

The error view in the admin centre lists items that failed to index with an error code and a description. Common causes we see:

Content too large. Items over the size limit are rejected or truncated. Usually big PDFs or attachments.
Unsupported content type. The connector can't extract text from a particular file format.
Authentication failures. The service account password expired, an OAuth app's secret expired, or someone tidied up an "unused" account. This is the number one cause of failed connections in our experience. Put credential expiry dates in a calendar. Better yet, use certificates or managed identities where the connector supports them.
Permission mapping problems. The connector can't resolve a source user or group to an Entra ID identity, so the item's ACL doesn't map. Depending on configuration, that item may be invisible to everyone, or worse, visible to everyone.
Throttling from the source system. The source API rate limits the crawler, crawls slow down, and the connection looks stuck.

A few errors on a large connection are normal. A sudden jump is a signal. We tell clients to set a baseline in the first month, then flag anything well above it.

Index quotas

There's a limit on how many items you can index across your tenant, and it scales with your licensing. Microsoft has adjusted the numbers more than once as Copilot licensing has changed, so check the current figures for your tenant rather than relying on a number from a blog post (including this one). There are also limits on the number of connections per tenant.

What matters in practice:

Plan your item budget before connecting everything. We've seen teams connect an entire file share with millions of files, most of them old or irrelevant, and hit quota before they connected the systems that mattered.
Filter at the source. Most connectors let you include or exclude content by path, date or type. Use it. Indexing every version of every spreadsheet from 2011 helps nobody.
Watch for limitExceeded. When you hit it, new content stops going in, but existing content stays. The connection looks partly healthy, which is the worst kind of broken.

Custom connectors need more care

If you've built a custom connector with the Graph API, the admin centre only gives you part of the picture. You also own:

Your own crawler's health. Whether it's an Azure Function, a container or a scheduled job, it needs logging and alerting.
Schema changes. You can add properties to a schema, but changing or removing existing properties is restricted, and some changes mean recreating the connection and re-ingesting everything. Think about the schema properly up front. We've covered that in our post on managing connector schemas.
Connection IDs. They're short alphanumeric identifiers you choose at creation time and can't change. Use a naming convention, because "test2" in production is a sad thing to explain.
Deletion and recreation. Deleting a connection and recreating it with the same ID isn't instant. Plan for a gap.
Long-running operations. Creating a schema is asynchronous. Your deployment pipeline needs to poll the operation until it completes rather than assuming it's done.

Who should own this

This is the question I push clients on most. Connectors sit between teams: the Microsoft 365 admins own the tenant, the application team owns the source system, and the Copilot rollout team owns the outcome. When a connector breaks, each group assumes one of the others is watching.

What works:

One named owner per connection, written down, usually from the team that owns the source system.
A weekly check of state, item count, last successful crawl and error count. Ten minutes per connection, or automate it with the Graph API and post a summary to a Teams channel.
Credential expiry tracking for every service account and app registration a connector depends on.
A test question per connection. Something you can ask Copilot that should be answered from that source. If the answer is wrong or missing, something's off. It's a crude smoke test, but it catches problems the admin centre doesn't.

Where we help

We build and run Copilot connectors for Australian organisations, and the operational side is often what clients ask us to take on after the build. If you're planning a Copilot rollout that depends on external content, our Microsoft AI consultants can help design the connector approach, and our AI managed services cover the ongoing monitoring so connectors don't quietly rot. If you're building agents on top of that content, have a look at our Copilot Studio consulting too.

A connector that worked on launch day and stopped in week six is worse than no connector, because people stop trusting Copilot's answers. Give each connection an owner, check it weekly, and track every credential expiry date.