How to Connect ServiceNow Knowledge Base to Microsoft 365 Copilot

BLOG POST  ·  MARCH 2026 How to Connect ServiceNow Knowledge Base to Microsoft 365 Copilot A practical, no-fluff guide to deploying the ServiceNow Knowledge Connector — with every gotcha I hit along the way. Udayagiri Sreekanth Reddy   ·   10 min read

 

#MicrosoftCopilot  #ServiceNow  #Microsoft365  #GraphConnectors  #KnowledgeManagement

 https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/servicenow-knowledge-deployment

Your organisation has hundreds of ServiceNow KB articles. Helpful, well-written, accurate. But users don't read them — because searching ServiceNow is an extra step nobody wants to take.

 

What if those articles showed up automatically when someone asked Copilot a question in Teams or Outlook? That is exactly what the ServiceNow Knowledge Copilot Connector does — and this post shows you how to set it up.

 

💡  This is a hands-on walkthrough based on a real deployment. I'll show you every screen, every field, and every problem I hit — so you don't have to.

 

What Is This Connector, in Plain English?

Microsoft 365 Copilot is smart — but it can only answer questions based on content it knows about. By default it knows about your Teams messages, SharePoint files, Outlook emails, and so on.

 

The ServiceNow Knowledge Connector is a bridge that brings your ServiceNow KB articles into that same knowledge pool. After setup:

 

•        A user asks Copilot: "How do I fix a USB port issue?"

•        Copilot searches across SharePoint, emails, AND ServiceNow KB

•        It finds the relevant KB article and includes it in its answer — with a direct link

 

No one needs to open ServiceNow. No one needs to know which KB to look in. Copilot just surfaces the right answer.

 

🗣️  Real example from my deployment: I searched for 'Sales Force Automation is DOWN' and the connector returned KB article KB00000XX from ServiceNow directly in the results.

 

Before You Start — What You Need

What You Need	Where to Get It
ServiceNow admin access	Log in at https://yourinstance.service-now.com
Microsoft 365 Global Admin or Search Admin	Log in at https://admin.microsoft.com
ServiceNow instance URL	It's in your browser address bar when logged in
Azure Portal access	https://portal.azure.com (same M365 account)

 

✅  You do NOT need a Microsoft 365 Copilot license to deploy the connector or index content. You only need one to use Copilot chat. You can validate the connector works using the Index Browser in the admin centre — no Copilot license required.

 

Part 1 — Set Up ServiceNow (Done by ServiceNow Admin)

Think of this part as preparing ServiceNow to be readable by Microsoft. There are four things to do.

 

Step 1 — Check the REST API is On

The connector reads ServiceNow data using the REST API. On modern ServiceNow instances it is always on — but let's confirm.

 

1.      Click the ☰ All button (top-left)

2.      Search for: Application Manager

3.      In the search box, type: REST API

4.      Click the 'Installed' tab — if you see REST API entries here, you're good ✅

 

✅  On recent ServiceNow versions (Utah, Vancouver, Washington DC, Yokohama) REST API is built-in. If you see it under Installed — no action needed.

 

Step 2 — Create a Dedicated Service Account

The connector needs a ServiceNow account to log in with. Don't use your personal admin account — create a separate one just for this.

 

5.      Click ☰ All → search 'Users' → click Users

6.      Click the New button (top right)

7.      Fill in these details:

 

Field	What to Enter
User ID	svc_m365_connector
Email	Use a real email that matches your M365 domain (important — explained later)
Active	✅ Tick this
Password	Set a strong password and save it

 

8.      Click Submit

9.      Open the user → scroll to Roles tab → click Edit → add the 'knowledge' role → Save

 

⚠️  Why does the email matter? The connector matches ServiceNow users to Microsoft 365 users by email address. If they don't match, the user shows as 'Denied' in search results even though they have access in ServiceNow.

 

Step 3 — Check Access Control Rules (ACLs)

The connector needs read permission on these four ServiceNow tables. They're usually already set up correctly — just verify.

 

10.  Click ☰ All → search 'Access Control' → click Access Control (ACL)

11.  In the search box, type: kb_knowledge

12.  Check that these four ACLs exist with Operation = read and Active = true:

 

Table Name	Should Have Read ACL?
kb_knowledge	✅ Yes — main KB articles
kb_knowledge_base	✅ Yes — KB groups
kb_category	✅ Yes — categories
sys_attachment	✅ Yes — file attachments

 

Step 4 — Set Who Can Read Your Knowledge Base (Critical!)

This is the step most people miss — and it causes the most confusion later.

 

Each Knowledge Base in ServiceNow has a 'Can Read' list that controls who is allowed to read articles in it. If this list is empty, Microsoft cannot work out who should see the content in Copilot — so it shows articles to nobody.

 

⚠️  If a Knowledge Base has NO Can Read criteria, and ServiceNow's default property is set to block access (which it usually is), the connector will index the articles but Copilot will never show them to anyone.

 

13.  Click ☰ All → search 'Knowledge Bases' → click Knowledge Bases

14.  Click on each Knowledge Base in your list (e.g. IT, General, HR)

15.  Scroll to the bottom — click the 'Can Read' tab

16.  Click the New button

17.  Set the Name to: Logged in users — leave ALL other fields empty — click Submit

 

✅  Leaving all fields empty means 'anyone who is logged in'. This is the easiest starting point. You can make it more specific later (by department, role, company, etc.).

 

 

Part 2 — Deploy the Connector (Done by M365 Admin)

With ServiceNow ready, it's time to set up the connector in Microsoft 365.

 

18.  Go to: https://admin.microsoft.com

19.  In the left sidebar, click Copilot

20.  Click Connectors

21.  Click Your Connections tab

22.  Click + Add Connection

23.  Search for: ServiceNow

24.  Click ServiceNow Knowledge (not ServiceNow Catalog)

25.  Click Add

 

The Setup Screen — Field by Field

You'll see a form with these sections:

 

① Display Name

This is the name users see when Copilot cites this source. Keep it clear.

Example: IT Knowledge Base  or  ServiceNow KB

 

② User Criteria Flow

Leave this on Simple — the default. Only change to Advanced if your KB uses custom scripts for permissions (most don't).

 

③ ServiceNow URL

Enter your ServiceNow instance URL exactly:

https://yourinstance.service-now.com

 

④ Authentication Type

You have four options. Here's a simple way to choose:

 

Option	Best For	Complexity
OAuth 2.0	Most organisations — quick to set up	⭐⭐ Medium
Federated Auth (Microsoft Entra ID OIDC)	Best long-term choice — no passwords to manage	⭐⭐⭐ Higher
Basic Auth	Quick testing only — not for production	⭐ Easy
Microsoft Entra ID OpenID Connect	Advanced Entra integration	⭐⭐⭐ Higher

 

💡  I used OAuth 2.0 first for quick testing, then switched to Federated Auth (Microsoft Entra ID OIDC) for the production setup. The UI shows it as 'Microsoft Entra ID OIDC' — same thing as 'Federated Auth' in the documentation.

 

If You Chose OAuth 2.0 — Enter These

Field	Value
Client ID	Your OAuth Client ID from ServiceNow Application Registry
Client Secret	Your OAuth Secret from ServiceNow Application Registry

 

Click Authorize → a ServiceNow login popup appears → log in with the svc_m365_connector account → click Allow.

 

If You Chose Federated Auth — Three Extra Steps in ServiceNow

✅  Federated Auth is more steps upfront but better long-term — no client secrets to rotate, no passwords stored in Microsoft.

 

Extra Step A — Get the Service Principal Object ID

Open PowerShell and run:

Get-AzADServicePrincipal -ApplicationId "933838e2-bec1-440f-a634-9363c82e5b6d"

Copy the Id value from the output. Save it — you'll need it in the next step.

 

✅  Can't run PowerShell? Go to Azure Portal → Enterprise Applications → search the App ID above → copy the Object ID from the Overview page. Same result.

 

Extra Step B — Create an OIDC Provider in ServiceNow

In ServiceNow: ☰ All → Application Registry → New → choose the OIDC provider option for your version → fill in:

 

Field	Value
Name	Microsoft Entra ID
Client ID	933838e2-bec1-440f-a634-9363c82e5b6d
OIDC Metadata URL	https://login.microsoftonline.com/YOUR-TENANT-ID/v2.0/.well-known/openid-configuration
User Claim	sub
Auth Scope	useraccount

 

💡  Replace YOUR-TENANT-ID with your actual Azure tenant ID. Find it at: Azure Portal → Microsoft Entra ID → Overview → Directory (tenant) ID.

 

Extra Step C — Create an Integration User in ServiceNow

Create a new user in ServiceNow (☰ All → Users → New) with:

 

Field	Value
User ID	Paste the Service Principal Object ID from Extra Step A
Identity Type	Machine
Active	✅ Checked

 

Then assign these three roles: catalog_admin, user_criteria_admin, user_admin

 

Complete the Rest of the Setup

After authentication, complete these three tabs:

 

Tab	What to Do
Users	Choose 'Only people with access to this data source' — this ensures users only see articles they're allowed to see in ServiceNow
Content	Leave the default query as-is: active=true^workflow_state=published — this indexes only published articles
Sync	Leave defaults: Full crawl daily, Incremental crawl every 15 minutes

 

Click Save on each tab. Then click Publish (or the connector auto-starts crawling). The first crawl takes 15–60 minutes depending on article count.

 

 

Part 3 — Problems I Hit (And How I Fixed Them)

The setup looks straightforward but there are a few things that will trip you up. Here's exactly what happened to me.

 

Problem 1: 'Users Indexed = 0' After First Crawl

After the first crawl completed I saw Items indexed: 42 — great! But Users indexed: 0 — not great.

 

What this means: The connector crawled the articles fine, but it couldn't find any Microsoft 365 users that matched the ServiceNow users. So it had no idea who should be allowed to see what.

 

Why it happened: My ServiceNow admin email was admin@yourcompany.com but my M365 account was admin@yourcompany.onmicrosoft.com. Different domains — no match.

 

Fix: In ServiceNow, I updated the admin user's email to match the M365 UPN (admin@yourcompany.onmicrosoft.com) → triggered a full re-crawl → Users indexed went from 0 to 1. ✅

 

⚠️  Rule of thumb: For every person who needs to see ServiceNow content in Copilot, their ServiceNow email must exactly match their Microsoft 365 login email.

 

Problem 2: Article Showing 'Denied Access' for My User

I used the Index Browser (more on this below) to check if a specific article was accessible to my user. It showed red 'Denied access'.

 

Why it happened: The 'IT' knowledge base had Can Read criteria that only allowed 'All ACME North America employees' and 'All ACME Corporation employees'. My test user wasn't in either of those groups.

 

Fix: I added 'Logged in users' as a new Can Read entry on the IT Knowledge Base (all fields left empty) → triggered full re-crawl → access changed to green 'Allowed access'. ✅

 

Problem 3: 'Something Went Wrong' When Searching

When I tried searching at office.com, I got the 'Something went wrong' error page instead of results.

 

Why it happened: My trial tenant didn't have an Exchange Online or Microsoft 365 Business license — so the search service wasn't fully available.

 

Solution: I used the Index Browser in the admin centre to validate the connector instead. This confirms everything is working without needing a full M365 license.

 

Part 4 — How to Confirm It's Working

The Index Browser — Your Best Validation Tool

The Index Browser lets you look up any specific KB article and see exactly what Microsoft has indexed and who has access. No Copilot license needed.

 

26.  Go to: https://admin.microsoft.com → Copilot → Connectors

27.  Click on your connector

28.  Click the 'Index browser' tab

29.  Enter three things from a KB article (all from the ServiceNow URL):

 

Field	Where to Find It
sys_id	In the KB article URL after ?sys_kb_id=
kb_number	Shown on the article page itself (e.g. KB00000XX)
knowledge_base_sys_id	In the Knowledge Base page URL after ?sysparm_kb=

 

30.  Press Enter

31.  You should see a green 'Indexed' badge — that means the article is in the Microsoft index ✅

32.  Click 'Check user access' tab → type a user's name → confirm it shows green 'Allowed access'

 

💡  If the Index Browser shows 'Item not found' — your crawl may not have run yet or the article doesn't match the query filter. Trigger a full crawl and wait 15–30 minutes.

 

Testing in Copilot or Search

Test Method	How	License Needed
Index Browser	Admin Centre → Connectors → Index browser	None ✅
Microsoft Search	https://www.office.com → search bar	M365 Business Basic
Copilot Chat	https://copilot.microsoft.com or Copilot in Teams	M365 Copilot license

 

 

Quick Cheat Sheet — Everything in One Place

Problem	Fix
Users indexed = 0	Update ServiceNow user emails to match M365 UPN format
User shows Denied access	Add 'Logged in users' (all fields empty) to Can Read tab of the Knowledge Base
Items indexed = 0	Check OAuth credentials are correct → re-authorize → full crawl
Articles visible to everyone even wrong users	Change connector Users tab from 'Everyone' to 'Only people with access'
'Something went wrong' in search	Check M365 license; validate using Index Browser instead
Can't find Federated Auth option	It's called 'Microsoft Entra ID OIDC' in the UI — same thing
Index browser shows 'Item not found'	Trigger full crawl and wait; or check if article is published and active in ServiceNow
Permissions changed in ServiceNow but not in Copilot	Wait for next daily Full Crawl — incremental crawls don't update permissions

 

 

Final Thoughts

The ServiceNow Knowledge Connector is genuinely powerful once it's running. Users stop hunting for KB articles and just ask Copilot — which finds the answer, cites the source, and links directly back to ServiceNow.

 

The setup has a few non-obvious gotchas — especially around email matching and user criteria — but nothing that can't be solved with a bit of systematic debugging. The Index Browser is your best friend throughout this process.

 

Total time for a clean deployment: about 2 to 3 hours, most of which is waiting for crawls to complete.

 

✅  If you're evaluating which auth method to use — start with OAuth 2.0 for speed. Switch to Federated Auth before going to production. It's more setup upfront but you'll thank yourself later when there are no secrets to rotate.

 

 

About the Author Udayagiri Sreekanth Reddy Senior Microsoft Power Platform & SharePoint Architect · 15+ years experience I write about real-world Microsoft 365, Power Platform, and Azure implementations — with the specific details that official docs often leave out. 🌐 udayagirisreekanthreddy.com   ·   LinkedIn: Udayagiri Sreekanth Reddy

 

Found this helpful? Share it →  #ServiceNow  #MicrosoftCopilot  #Microsoft365