Microsoft Graph Connectors - Simply Explained

Welcome to another episode of Microsoft Knowledge Nuggets here on M365. FM, I'm your host, Mirko Peters. So here's a question for you. What if Copilot could search across your entire company? Not just emails and files in SharePoint, but also your CRM, your ticketing system, your HR database, your project Wiki? What if you could ask one question and get an answer that pulls from all of those systems at once without ever leaving Microsoft 365? That's the promise, but here's the reality. Microsoft 365 Copilot out of the box only looks at content stored in SharePoint Online and OneDrive. That's it, your emails, your team's messages, your documents, those are all fair game. But the vast majority of your company's important business data lives somewhere else. Think about your CRM like Salesforce, your ticketing system like ServiceNow, your Wiki, like Confluence, maybe even a Google Drive you haven't migrated yet. Copilot can't see any of that, not by default. That's a huge blind spot, and it's exactly what Copilot connectors are designed to solve. So by the end of this episode, you'll understand what Graph Connectors are. They're now called Copilot Connectors, by the way. The two very different types. And which one you should use depending on your situation. Grab your coffee and let's dive in. The problem, your data is everywhere. Here's the thing, most companies don't store everything inside Microsoft 365. You might have a CRM like Salesforce for your customer data, a ticketing system like ServiceNow for IT support, a Wiki like Confluence for Documentation, or even a Google Drive or Dropbox that team started using before your company standardized on Microsoft. So when you ask Copilot a question like, "What's the status of the Contoso deal?" or, "Show me the latest support ticket from that customer." Copilot draws a blank. It can't see that data. It's like having a library card that only works for one shelf in a building with 50 rooms. You can access the books right in front of you, but everything else might as well not exist. Without Copilot, you'd have to contact Switch. Imagine searching for the customer in Salesforce, copying the account details. Next, your Open Service Now, search for the ticket, copy that too. After that, you go to Confluence to find the project notes. Finally, you paste it all into an email or a team's message. You're jumping between five different browser tabs, logging into each system separately and manually stitching the information together. That waste time breaks your flow and it's exactly the kind of busy work that Copilot was supposed to eliminate. But the real cost isn't just wasted time. When Copilot can't connect the dots across all your data, you get incomplete answers. You might make a decision based on the information you have in front of you, not realizing that the critical piece of data lives in a system Copilot can't see. That missed insight could be a customer complaint logged in your CRM, but never surfaced in your email or a contract renewal date sitting in your ERP system, but not in your calendar. These gaps add up and they can lead to real consequences. So Microsoft built a bridge. Let's look at what that bridge actually is. What is a Graph connector? A Graph connector is a piece of software that brings external data into the Microsoft Graph. Now, the Microsoft Graph is the same index that powers Microsoft Search, SharePoint Search, and now Copilot. Think of it as the central nervous system of Microsoft 365. It's the place where all your data lives and gets connected. So a Graph connector works like a conveyor belt. You load data from your external system onto the belt and it gets delivered into the Microsoft 365 index. Once the data is in there, Copilot can search it, summarize it, and answer questions about it, just like it does with your emails and files. That Salesforce account record, now Copilot can find it, that service no ticket, Copilot can summarize it, that confluence wiki page, Copilot can answer questions about it. Here's something that might surprise you. Graph connectors are not new. They've existed for years, powering SharePoint Search. You might have been using them without even knowing it. If you've ever searched in SharePoint and seen results from an external system appear in a separate vertical that was a Graph connector at work, what's new is that Copilot now uses them, and that changes everything because Copilot doesn't just find the data. It reasons over it, summarizes it, and answers questions about it in natural language. But there's a catch. Microsoft actually offers two very different types of connectors. They work in fundamentally different ways. Let me explain the difference. The two models synced versus federated. So here's where it gets interesting. Microsoft gives you two completely different ways to bring external data into Copilot. The choice between them comes down to one basic question. Do you want to copy the data or do you want to ask for it live? The first model is called a Syncid connector. With this approach, you copy the data from the external system into the Microsoft Graph. It gets indexed, stored, and semantically processed. Think of it like moving your filing cabinet into the same building as your desk. Instead of walking to another room every time you need a file, that cabinet is right there, organized, searchable, ready to use. The data becomes a permanent resident of your Microsoft 365 tenant. The second model is called a federated connector. It works completely differently. You don't copy anything. When a user asks a question, Copilot reaches out to the external system in real time, asks it for relevant information and brings back the answer. No data is stored in Microsoft 365. It's like asking a librarian in another building to look something up for you. They go find the book, read you the answer, and the book stays on their shelf. You never take possession of it. Why does Microsoft offer two models? Because different data has different needs. Some data changes rarely. Think HR policies, project wikis, archive contracts. That kind of data is fine to copy. You index it once, maybe refresh it daily, and you're good. But other data is live. Inventory levels, current support ticket status, real time pricing. If you copy that data, it's stale. The moment it arrives, you need the freshest answer every single time. There's another key difference. Sync connectors are set up by an admin for the whole organization. One person configures the connection and everyone who has permission can use it. Federated connectors require each user to authenticate individually. So if you're connecting to Salesforce, every person who wants to ask co-pilot about Salesforce data needs to log into Salesforce themselves. That's more set up per user, but it also means each person only sees what they're allowed to see. Let's dive deeper into each model so you know which one fits your situation. Sync connectors, the deep dive. Let's start with sync connectors because they're the more established model and the one you're most likely to encounter first. Here's how it works. An admin goes to the Microsoft 365 admin center, navigates to search and intelligence and opens the data sources section. You'll see a gallery of over a hundred pre-built connectors. You pick the one you need, say service now, JIRA or confluence, and authenticate using OOOH 2.0, which means no passwords are stored in plain text. Then you configure what data to pull, how often to sync in which fields to map. Once that's done, the connector starts pulling data into the Microsoft graph and here's what makes co-pilot powerful. The data gets a semantic index that means co-pilot doesn't just match keywords. It understands the meaning behind your question. So if you search for Q3 budget, co-pilot can find a document title 2025 financial review because it understands the relationship between the concepts. That's a big leap forward from traditional search where you'd need the exact title or keyword. Now security is baked into this model from the ground up. Every indexed item includes an access control list or ACL which tells Microsoft 365 who can see it. If a user doesn't have permission in the source system, they won't see it in co-pilot either. The permissions follow the data. So if your Salesforce account only allows your sales team to see certain records, those same restrictions apply inside co-pilot. There are some limitations worth knowing about. Each item can be up to four megabytes and the connector can handle up to 25 concurrent operations on a single connection. And if your data lives on premises like on a local file server or a SQL database in your own data center, you need to install the Microsoft Graph Connector agent. That agent reads your local data and sends only the text and metadata to the cloud while your actual files stay on your premises. But the good news is you don't have to build any of this from scratch. Microsoft and its partners offer over 100 pre-built connectors for Salesforce, ServiceNow, Jura, Confluence, Google Drive, GitHub, Box, Dropbox and many more. If your company uses a popular business application, there's probably already a connector for it but what if you need real-time data? That's where the second model comes in. Federated connectors, the deep dive. Now let's talk about the second model because it's the newer one and it works completely differently. With a federated connector, no data gets stored in Microsoft 365 at all. When a user asks co-pilot a question, co-pilot sends a request to the external system using the model context protocol or MCP. Think of it as a standard way for co-pilot to say, "Hey, I need information about this topic and for the external system to respond with what it's got." The external system does the searching, finds the relevant results and sends them back and co-pilot presents that answer to the user. The original data never leaves the source system. This model is great for live data. I'm talking about inventory levels that change by the minute. Support ticket status that updates every time an agent touches a case or real-time pricing that fluctuates. If you sync that kind of data, it's stale by the time it hits the index. But with a federated connector, you always get the freshest answer because every single query goes straight to the source. There's a trade-off though. User authentication works differently here. With a sync connector, an admin sets it up once and everyone can use it. With a federated connector, each person must log into the external service themselves. So if you want to ask co-pilot about a Salesforce record, you need to authenticate with Salesforce first. Co-pilot then respects whatever permissions you have in that system. If you can only see your own accounts in Salesforce, co-pilot will only return results for those accounts. It's per user and per session. Now, federated connectors are still rolling out. Right now, they're limited to the researcher experience in co-pilot chat, where you can ask deep research-oriented questions and co-pilot goes out to find answers across multiple sources. It's not yet available everywhere in co-pilot, not in Teams, not in Outlook, not in the side panel of Word or Excel, but Microsoft is expanding. The connector catalog is growing, and the expectation is that federated connectors will become available in more co-pilot experiences over time. One more thing to know. Federated connectors are read only by default. Co-pilot can search and fetch data, but it cannot write back to the external system. It can't create a new ticket in service now or update a contact record in Salesforce. That's by design to keep things safe. If you need co-pilot to take actions, that's a different extensibility model called plugins. But for search and retrieval, federated connectors do exactly what you need, so which one should you use? It depends on your scenario, sir. Which connector model should you use? So which connector model should you use? Let's make it practical. You want a synced connector when the data doesn't change often. Think HR policies that get updated once a quarter, or project weekies where the content is mostly stable, or archived contracts you need to reference but rarely modify. Synced connectors give you semantic search. Co-pilot understands the meaning of your question, not just the keywords. And the data becomes available everywhere in Microsoft 365, search co-pilot SharePoint, the whole platform, you index it once and it's there for everyone. Use a federated connector when the data changes constantly and you need the latest answer every single time. Live support tickets where the status might change while you're asking the question, inventory levels that fluctuate throughout the day, current project status that gets updated in real time. With federated connectors, you don't store a copy, so you never have to worry about stale data. You get the freshest answer straight from the source, but here's the thing, you don't have to pick just one. Many organizations use both. They use synced connectors for their static knowledge base, HR policies, onboarding docs, reference materials, and they use federated connectors for their dynamic operational data. Live tickets, current inventory, real time project status. It's not an either/or decision, it's a both in strategy. Now let's talk about cost. Synced connectors use storage and compute inside Microsoft 365. Every item you index takes up space and gets processed by the semantic index. That's included in your licensing, but there are limits depending on your plan. Federated connectors don't store data in Microsoft 365, so they don't consume that storage, but they do require the external system to handle every query in real time. If your salesforce instance is already struggling with performance, adding hundreds of co-pilot queries on top of that could cause issues, so keep that in mind when you're planning. Security and compliance. Before you set anything up, there's one thing you absolutely must get right, and that's security. Every single item that goes through a connector needs an access control list attached to it. That's an ACL. It tells Microsoft 365 who can see that piece of data. Forget to include one, and two things can happen. The data might become visible to everyone in your organization, or it might become invisible to everyone. Neither is good, so when you're configuring a connector, pay close attention to how permissions are mapped from the source system. All connectors use OAuth 2.0 for authentication. That's the modern standard. No passwords stored in plain text, no shared service accounts with weak credentials. It's the same protocol you use when you log into a website with your Google or Microsoft account. The connector authenticates securely, and then it pulls data based on the permissions you've granted. Data and transit is encrypted. When your connector moves data from Salesforce or Service now into Microsoft 365, that traffic is protected. For Syncad Connectors, data address is also encrypted inside Microsoft 365, so even if someone somehow accessed the storage layer, they couldn't read the data without the encryption keys. Now, what about data that lives on premises? Maybe you have a file server in your office or a SQL database running in your own data center? You don't want to move that data to the cloud, and you don't have to. You install the Microsoft Graph Connector agent on a machine inside your network. That agent reads your local data, and sends only the text and metadata to the cloud. Your actual data files stay on your premises. The only thing that travels over the internet is the content that needs to be indexed. Not the original files themselves. And here's something that matters if you're in a regulated industry. Microsoft Graph Connectors inherit Microsoft 365's compliance certifications ISO 27001, SOC2, HEAPA, FedRAMP. If your organization already uses Microsoft 365 for compliant workloads, the same certifications apply to the data you bring in through connectors. You don't need separate audits or additional certifications for the connector layer. Ready to try it? Here's how to get started. Getting started. So where do you actually start? The first place is the Microsoft 365 Admin Center, head over to search in Intelligence, then open data sources. That's where you'll find the connector gallery. It's a list of over 100 pre-built connectors ready to go. Pick one. Let's say ServiceNow. Click on it, and the setup wizard walks you through the whole thing. You authenticate to ServiceNow using OAuth 2.0, then you choose what data to sync, maybe just incidents and knowledge articles instead of the whole database. You map the fields from ServiceNow to the Microsoft Graph schema. And you configure the ACL's permissions carry over correctly. For a straightforward setup, the whole process takes maybe 30 minutes. Now, what if your data source doesn't have a pre-built connector? You can build your own. Use the Microsoft Graph Connectors API or the Microsoft 365 Agents Toolkit. You'll need to create three things. First, a connection that tells Microsoft 365 where the data lives. Second, a schema that defines what fields exist and how they map. Third, a way to manage the external items. Adding them, updating them, deleting them when they change in the source system. It's more work, but it gives you complete control over what gets indexed and how. Once your connector is set up, test it, ask co-pilot a question that should pull from your new data source. Something like, show me open incidents from ServiceNow or what's the latest contract in Salesforce. Check that the results appear. Then check that only authorized users see the right results. If someone in marketing asks about a sales-only account, they shouldn't see it. If they do, your ACLs need work. Let's wrap up with the big picture. So now you know what Graph Connectors are. They let you bring external data into Microsoft 365. Data that co-pilot can't see on its own. You have two models to choose from. Sync-it-connectors, copy, and index the data, giving you semantic search and broader availability. Federated connectors query the source in real-time, giving you fresh answers without storing a copy. Here's why this matters. Co-pilot becomes truly useful when it can see all your company data. Not just what's sitting in SharePoint in one drive. A co-pilot that only knows about your emails and documents is a limited assistant. A co-pilot that also knows about your CRM, your ticketing system, your HR database, your project wiki. That's a co-pilot that can actually transform how you work. Your next step is simple. Pick one external system that holds critical data for your team. Set up a connector for it this week. See how it changes your co-pilot experience. You might be surprised at how much more useful co-pilot becomes when it has access to the data that actually runs your business. This has been another episode of Microsoft Knowledge Nuggets here on M365. FM, I'm your host, Mirko Peters. If this helped you understand Graph Connectors a little better, subscribe on your favorite podcast platform. And share this episode with a colleague who's been wondering why co-pilot can't seem to find their salesforce data. Until next time.