Federated Search Architecture: ServiceNow, SharePoint & CMS

The Federated Search Architecture Problem in the Modern Workplace

Federated search architecture is the design pattern most enterprises now need — and the one most internal IT projects still get wrong. The reason is simple. The answer your employee wants does not live in one system anymore. It lives across ServiceNow tickets, SharePoint policies, the corporate CMS, and a handful of SaaS tools that nobody mapped on the IT diagram.

Each of those systems has its own search box. None of them talks to the others. Therefore, the employee opens five tabs, gives up, and pings a colleague. Multiply that across a 5,000-person workforce and you have a productivity cost that quietly rivals any other line item on the CIO’s plate.

However, the fix is not another portal. The fix is an architecture decision about where, and how, content is indexed, secured, and surfaced. That decision is what this article walks through.

What Federated Search Architecture Actually Means

A federated search architecture indexes content from many source systems into one unified, permission-aware retrieval layer. The source systems stay exactly where they are. Meanwhile, a single query reaches across all of them and returns a ranked, security-trimmed result set.

It is useful to separate three patterns that get conflated:

• True federation (query-time fan-out). The search layer broadcasts a query to each source system at request time and merges the results. Real-time, but slow and hard to rank consistently.
• Unified index (crawl-and-consolidate). Each source is crawled on a schedule, normalized into one index, and ranked with one relevance model. Fast at query time, but the index can lag the source.
• Hybrid. Most enterprise platforms — Coveo, Glean, Elastic Workplace Search — default to a unified index with selective live calls for fast-changing sources such as ServiceNow incidents.

In practice, when CIOs say “federated search architecture” they almost always mean the hybrid. That is the model the rest of this article assumes.

The Three Sources Every CIO Has to Federate: ServiceNow, SharePoint, and CMS

Almost every enterprise workplace-search project lands on the same three primary sources. They behave very differently, and the architecture has to respect that.

• ServiceNow holds knowledge articles, catalog items, and incident history. Permissions are scoped by table, ACL, and user role. The ServiceNow developer documentation explains the table and ACL model in detail. Content turns over quickly, so the index needs near-real-time refresh on KB tables.
• SharePoint Online stores policies, project sites, intranet pages, and shared documents, with permissions inherited from Microsoft Entra ID. The official Microsoft SharePoint documentation describes the site, library, and unique-permission model that the index has to mirror exactly.
• The intranet or corporate CMS (often WordPress, AEM, Sitecore, or a headless CMS) publishes communications, HR content, and curated landing pages. Permissions are usually public to authenticated employees, but draft and division-scoped content needs filtering.

Each source has its own schema, its own access model, and its own change-rate. As a result, the federation layer is not a single connector. It is a connector portfolio, glued together by one identity model.

Connectors, Crawlers, and the Federation Layer

A working federated search architecture has four moving parts:

1. Source connectors. One per system — ServiceNow, SharePoint, CMS, plus whatever else matters. Each connector authenticates, paginates, and incrementally syncs content.
2. A unified index. One physical index (or a logical one across shards) where every document, regardless of source, gets normalized fields: title, body, URL, source, last_modified, and security_identities.
3. A relevance and ranking layer. One model — not one per source — that ranks across all content. Machine-learned ranking is what stops SharePoint from drowning out ServiceNow.
4. A query API and UI layer. One endpoint that the intranet, the Teams plug-in, or a chatbot calls. Auth is forwarded so the layer below can apply security filtering.

Crucially, the federation layer is not where security gets enforced. That happens one layer down, inside the index itself. This is the part that breaks most homegrown federated search architectures.

Permission-Aware Indexing: Where Most Federated Search Architectures Fail

If a federated search architecture cannot prove, at query time, that a user sees only what they were already allowed to see, it should not ship. This is the single most common failure mode — and the one that gets projects vetoed by security and compliance teams.

The safe pattern is called early-binding security. At indexing time, the connector pulls each document’s full access-control list straight from the source system — Entra ID groups for SharePoint, role tables for ServiceNow, capability flags for the CMS. Those identities are stored alongside the document in the index. At query time, the search layer resolves the user’s effective identities and uses them as a filter against the index. The user is mathematically incapable of seeing a document they are not entitled to.

Late binding, by contrast, indexes content without permission metadata and re-checks each result against the source system at query time. It feels simpler. It also collapses under load, leaks results during outages, and is the architecture that most ends up rebuilt within a year. The Coveo platform documentation details how source permissions and security identities map into a unified, early-bound index.

That is also why a federated search architecture is a security project as much as a search project. We have written a deeper companion piece on permission-aware enterprise search that walks through the early-binding model in more detail.

Retrieval-Augmented Generation on Top of Federated Search Architecture

A federated search architecture is also the right foundation for a generative AI assistant — and the wrong place to skip steps. The pattern is called retrieval-augmented generation, or RAG. The model never answers from its own pre-training. Instead, it retrieves the most relevant, security-trimmed documents from the unified index and generates an answer grounded in that content, with citations.

Two architectural rules keep RAG safe inside the enterprise:

• The model only ever reads what the user could already open. The retrieval step runs through the same permission filter as the search UI. There is no separate, privileged “AI service account” reading everything.
• Every answer cites its sources. Citations are not a UX nicety — they are the audit trail that lets compliance approve the rollout in the first place.

In short, you do not bolt RAG onto a public LLM and hope. You build it on top of an already-secure federated search architecture, and you treat the LLM as a presentation layer over content the index has already vetted. For the broader CIO case, our AI-enabled intranet article frames the business value of this approach.

Coveo vs Microsoft 365 Copilot vs Glean vs Custom RAG: An Architectural View

Vendor choice in this space is mostly an architectural choice in disguise. Here is the honest map.

• Coveo is purpose-built for a unified, permission-aware index across Microsoft, ServiceNow, Salesforce, CMS, and file shares. It is the strongest fit when “true federation across non-Microsoft sources” is a hard requirement and when the company already runs Coveo on its public website.
• Microsoft 365 Copilot is exceptional inside the Microsoft 365 graph. Once an answer depends on ServiceNow, the corporate CMS, or third-party SaaS, however, it weakens. The official Microsoft 365 Copilot documentation is honest about which connectors are first-class and which are not.
• Glean is a focused workplace-search and RAG product. Strong out-of-the-box experience, but a net-new vendor with its own security review and procurement cycle.
• Custom RAG on a vector database (pgvector, Pinecone, Weaviate) gives maximum flexibility. It also makes you responsible for connectors, permission-aware retrieval, relevance tuning, and operations — work that takes most teams 18 months to get right.

There is no universal winner. The right architecture depends on where your content lives, what you already own, and whether security wants one vendor to certify or three.

A 90-Day Federated Search Architecture Rollout Plan

A federated search architecture does not need a multi-year program to deliver value. Based on enterprise search and discovery work in regulated sectors, this 90-day shape works:

1. Days 1–15 — Source and identity inventory. Enumerate every system, every permission model, and every identity provider. Decide what genuinely belongs in the index. Most projects discover that 30% of “important” content is duplicates or expired.
2. Days 16–45 — Pilot one source with early-binding security. Start with ServiceNow knowledge or one SharePoint library. Validate that the permission filter blocks what it should block, with security in the room.
3. Days 46–75 — Add the second and third sources. SharePoint and the CMS. Tune the relevance model now that there is content from multiple sources to compete.
4. Days 76–90 — Switch on the generative answer layer. Only after retrieval quality is solid. Ship citations from day one. Train search-quality reviewers, not just end users.

Most importantly, treat the launch as a product launch — not an IT project. Search quality decays without an owner, so name one before you go live.

How Sengo Designs Federated Search Architectures for Enterprises

Sengo designs federated search architectures the way the security team wants them built — early-binding, audit-friendly, and grounded in your existing identity provider. Our team includes a former Coveo backend developer, so we understand connectors, security identities, and relevance models at the level where most projects get stuck. We are an official Coveo implementation partner alongside the major CMS and DXP platforms, which lets us advise neutrally on whether a Coveo-based architecture, Microsoft 365 Copilot, Glean, or a custom RAG build is the right fit for your environment.

We have delivered enterprise search and digital platform work for organizations such as iA Financial Group, Cirque du Soleil, and LCI Education. Our bilingual team is based in Quebec, which removes friction for Canadian operations that need to serve employees in French and English from the same index.

If your enterprise already runs Coveo or Microsoft 365 on the public side, your federated search architecture is closer than you think. Let’s map the shortest path from the systems you already own to a workplace where every employee finds what they need — safely.