SharePoint

SharePoint is good at files and permissions. It's less good at giving a communications team a fast, reviewed way to publish news and pages. You don't have to choose between them: keep SharePoint for documents, and let Agility run the content people read.

At a glance

• Documents stay in SharePoint. Agility stores a link to each one, so versions and permissions keep working as they do today.
• Agility content can appear inside SharePoint and Teams through a SharePoint Framework web part that reads the Agility Fetch API.
• Or move the front end. Replace SharePoint pages with Power Pages or your own site, and keep SharePoint for files.
• Editors sign in to Agility with their Microsoft work account.
• Moving content out of SharePoint? See Migrate from SharePoint or Power Pages to Agility.

The three patterns combine well:

Pattern	Use it when
Link to SharePoint documents from Agility	Documents, forms and handbooks should stay in SharePoint, with their versions and permissions
Show Agility content on SharePoint pages	People live in SharePoint or Teams, and you want Agility-managed news or links to appear there
Move the intranet front end off SharePoint	You are replacing SharePoint pages with Power Pages or a custom site, and keeping SharePoint for files

Link to SharePoint documents from Agility

This is the simplest pattern, and almost every intranet uses it.

Don't copy controlled documents (handbooks, benefits forms, policies) into Agility's media library. Files in the Agility media library are served from a public CDN URL and have no per-user permissions. Keep them in SharePoint and link to them.

Model a Document Link list:

Field	Type	Notes
Title	Text	What readers see
Description	Multi-Line Text
Document	URL	The SharePoint link to the file or folder
Category, Department	Drop-down List or Linked Content	For filtering

What this gives you:

• One current version. The link opens the file as it is in SharePoint now, so updating the document doesn't need a change in Agility.
• SharePoint still decides who can open it. A reader without access sees SharePoint's access message. Use a link type that matches the audience, such as "People in your organization".
• Editors curate, IT governs. Editors choose which documents appear where and how they are described; document owners keep the files.

If the file is renamed or moved, the link may break. Prefer links to stable locations, and check document links during content reviews.

Show Agility content on SharePoint pages

If your people spend their day in SharePoint or Teams, bring the content to them. A SharePoint Framework (SPFx) web part can read published content from the Agility Content Fetch API and render it on a modern SharePoint page or in Teams. Use SPFx's HttpClient, which is meant for APIs outside SharePoint. (SPHttpClient is for SharePoint's own APIs.)

import { HttpClient, HttpClientResponse } from '@microsoft/sp-http';

interface IAnnouncement {
  contentID: number;
  fields: { title: string; summary: string };
}

private async getAnnouncements(): Promise<IAnnouncement[]> {
  const { guid, fetchKey } = this.properties; // set in the web part's property pane
  const url = `https://api.aglty.io/${guid}/fetch/en-us/list/announcements?take=10`;
  const res: HttpClientResponse = await this.context.httpClient.get(
    url,
    HttpClient.configurations.v1,
    { headers: [['APIKey', fetchKey], ['accept', 'application/json']] }
  );
  if (!res.ok) {
    throw new Error(`Agility returned ${res.status}`);
  }
  const body = await res.json();
  return body.items as IAnnouncement[];
}

Use the Fetch API host for your instance's data region. See Content Security Policy and Network Allowlist.

Things to know:

• Use the Fetch key only. A web part runs in the browser, so its key is visible to anyone who can load the page. The Fetch key reads published content only. Never put the Preview key or a Management API token in a web part.
• The Fetch key reads everything published in the instance. If some content must stay restricted, keep it in a separate instance, or serve it through a server you control that checks who is asking. See Reference Architecture: Member Portal and Intranet.
• Publishing is enough. The web part reads live, so editors publish in Agility and the SharePoint page shows it on the next load. There's no sync to run.
• Agility's preview and Web Studio don't apply inside SharePoint. Editors preview on a site that supports Agility preview, or in Agility itself.

Move the intranet front end off SharePoint

Some teams outgrow SharePoint pages and want a site that looks and works exactly the way they need. Agility becomes the content source for the new front end, and SharePoint stays where the files are:

• Microsoft Power Pages keeps hosting and sign-in inside the Microsoft stack. See Microsoft Power Pages.
• A custom site (for example Next.js or ASP.NET Core) with Microsoft Entra ID sign-in gives you full control of the experience. See Reference Architecture: Member Portal and Intranet.

Either way, link to SharePoint documents as described above, or use the Secure Files apps for private files kept outside SharePoint.

Sign editors in with Microsoft

Editors can sign in to Agility with the same Microsoft work account they use for SharePoint:

• Sign in with Microsoft matches the user's Microsoft Entra ID account to an Agility user an administrator has added. See Authenticate with Microsoft or Azure AD/Entra.
• Enterprise SSO makes Entra ID the only way in and applies your MFA and conditional access policies. See Enterprise Single Sign-On with Agility.

Readers of your intranet sign in to the front end (SharePoint, Power Pages or your own site), not to Agility.

Related

• Microsoft Power Pages
• Migrate from SharePoint or Power Pages to Agility
• Building Integrations
• Secure Files - Azure and Secure Files - AWS
• Connect the Agility MCP Server to Microsoft 365 Copilot
• Nest, Link or Share? Choosing Linked Content Field Types
• Microsoft: Connect to anonymous APIs (SPFx)