Browse all topics
SharePoint & OneDrive

SharePoint Framework (SPFx) overview

SPFx is Microsoft's modern client-side development model for extending SharePoint and Microsoft 365. Here's how it works.

The SharePoint Framework (SPFx) is the modern client-side development model for building extensions to SharePoint Online, Microsoft Teams, Outlook, and Microsoft 365 Copilot. It replaced the legacy server-side and full-trust development model with a clean Node.js / TypeScript stack that runs in the user's browser with the user's identity.

What SPFx is used for

Common SPFx artefacts:

  • Web parts — custom blocks that authors can drop into SharePoint pages alongside the built-in web parts (a customer dashboard, a survey, a CRM widget).
  • Extensions — Application Customizers (add header/footer to every page), Field Customizers (custom rendering for list columns), Command Sets (custom commands in list toolbars).
  • Teams tabs and personal apps — SPFx-built solutions can deploy as Teams apps.
  • Outlook and Microsoft 365 Copilot extensions — newer convergence with the Microsoft Teams app model.

The same code base, with the right manifest, can ship to multiple surfaces.

The development stack

  • Node.js LTS, Yeoman, gulp, TypeScript.
  • React is the default UI framework (other frameworks are possible but less idiomatic).
  • PnPjs — community library for Microsoft Graph and SharePoint REST work, much friendlier than raw fetches.
  • Microsoft Graph and SharePoint REST API for backend interaction.
  • App Catalog — tenant-wide or site-collection-level catalog where built .sppkg packages are deployed.

The default tooling produces a single .sppkg you upload to the catalog; from there the solution is available across sites or scoped to specific sites.

Authentication and permissions

SPFx solutions run as the signed-in user. To call Graph or other APIs, they use Microsoft Graph Toolkit components or MSGraphClient / AadHttpClient with permission scopes declared in the manifest. Tenant admins must approve those scopes in the SharePoint admin center's API access page before the solution can call the APIs.

Where SPFx fits today

  • Custom intranet experiences — branded landing pages with bespoke web parts.
  • Line-of-business integration — Teams tabs and SharePoint web parts that surface external systems.
  • Microsoft 365 Copilot extensions built using the Teams app SDK model.

Increasingly, the choice between SPFx and Power Apps / Power Pages / Copilot Studio depends on the audience: low-code for citizen-developer scenarios, SPFx for pro-developer customisation with full control and version-controlled source.

When to skip SPFx

  • For internal workflow automation, Power Automate is faster.
  • For custom data apps, Power Apps is faster.
  • For simple SharePoint customisation, list formatting JSON and modern page web parts often suffice.
  • For full custom applications, Azure App Service + Microsoft Graph is often cleaner than the SPFx hosting model.

SPFx remains the right answer when you specifically need the artefact to live inside a SharePoint page, a Teams tab embedded in Teams, or a Copilot agent extension built using the Microsoft 365 app SDK.