Skip to content

SharePoint Framework (SPFx)

Build, integrate, deploy and modernize SharePoint solutions using SPFx, React, PnPjs, Microsoft Graph and modern Microsoft 365 development patterns.

Architecture

The SharePoint Framework (SPFx) is Microsoft’s client-side extensibility model for building supported custom experiences for SharePoint and related Microsoft 365 scenarios — web parts, extensions, and integrations with Microsoft Graph and SharePoint data using React and TypeScript.

Use this hub to learn SPFx from environment setup through deployment, understand web parts, React patterns, PnPjs, Microsoft Graph, SharePoint REST, external API integration, extensions, App Catalog deployment, security, performance and troubleshooting — and to connect SPFx work with SharePoint modernization and migration.

New to SharePoint development? Start with What is SPFx? and the SharePoint hub. Planning a move with legacy customizations? See the migration hub and the modernization roadmap.

Overview

What is SPFx?

SPFx is Microsoft’s client-side extensibility model for SharePoint and related Microsoft 365 scenarios. Solutions are built with TypeScript and React, run in the browser in the current user’s context, and deploy as versioned packages through the SharePoint App Catalog — there is no server-side code. That constraint is also its strength: upgrades stay supported because customizations use public extension points and APIs instead of page internals.

  • Web Parts
  • Extensions
  • SharePoint integration
  • Microsoft Graph
  • Microsoft 365 APIs
  • React
  • TypeScript

Architecture

SPFx Solution Architecture

Healthy SPFx projects keep page hosting, UI components, data services, permissions, and external integrations in separate layers. That separation makes it easier to test, modernize, troubleshoot, and replace an API without rewriting every component.

  1. Layer 1

    User

    Signed-in Microsoft 365 user with real tenant, site, and API permissions.

  2. Layer 2

    SharePoint Page

    Modern page surface where web parts and extensions are loaded.

  3. Layer 3

    SPFx Web Part / Extension

    Versioned package with context, lifecycle, manifests, and permission requests.

  4. Layer 4

    React Components

    UI, state, loading, error, and accessibility behavior.

  5. Layer 5

    Service Layer

    Thin boundary that hides data calls from components.

  6. Layer 6

    PnPjs / Graph / REST / External APIs

    The API choice changes by workload, permission model, and data owner.

  7. Layer 7

    Microsoft 365 + Business Systems

    SharePoint, Teams, users, files, workflows, and line-of-business systems.

SPFx tutorial path

Learn SPFx

Follow the stages in order. Items with links point to published nextM365 pages; the remaining items describe the curriculum each stage covers. Always match the toolchain, Node.js, and React versions to the SPFx release your project targets.

  1. Learn SPFx

    Understand the model, set up the workstation, and run your first local workbench session.

    What is SPFx? · Development environment · Project creation · Project structure · Toolchain · Local development and debugging

  2. Build

    Decide what deserves custom code, then build web parts with sound component structure.

    SPFx web parts · React · TypeScript · Properties and property pane · State management · Fluent UI

  3. Connect

    Read and write business data through the right API for each scenario.

    SharePoint REST · PnPjs · Microsoft Graph · External APIs · Authentication · Permissions

  4. Extend

    Customize page chrome, list commands, and column rendering — plus Copilot-era surfaces where applicable.

    Application Customizers · ListView Command Sets · Field Customizers · Teams-integrated experiences where applicable

  5. Secure

    Design permissions, external API mediation, data exposure, and dependency governance before rollout.

    Least privilege · Delegated permissions · No client secrets · Admin approval · CORS · Dependency review

  6. Deploy

    Ship versioned packages through the App Catalog with approved permissions.

    Packaging · App Catalog · Tenant deployment · API permission approval · Environment configuration · CI/CD and ALM

  7. Optimize

    Keep solutions fast, secure, accessible, and supportable in production.

    Performance · Caching · Error handling · Security · Accessibility · Maintainability · Troubleshooting

  8. Modernize

    Convert legacy customizations into supported modern SharePoint, SPFx, and Power Platform patterns.

    Classic customizations · Script Editor · JSLink · InfoPath · SharePoint Designer workflows · Migration planning

Development capabilities

What Developers Can Build with SPFx

SPFx covers page components, page chrome, list experiences, and data integrations — everything below ships through the same package and permission model, which keeps governance reviewable.

Web Parts

Custom page components with properties, React UI, and live data.

Application Customizers

Headers, footers, and page-level behavior across sites.

ListView Command Sets

Command-bar actions for selected list and library rows.

Field Customizers

Custom rendering for columns in list views.

Dashboards

Role-based views over lists, Graph data, and business APIs.

Document experiences

Library-centric UIs with metadata, views, and actions.

Search experiences

Scoped result views and refiners over SharePoint content.

Navigation

Consistent headers, footers, and wayfinding injected by extensions.

Business interfaces

Task-focused forms and approvals backed by lists or APIs.

Microsoft Graph experiences

People, files, mail, calendar, and Teams data in SharePoint pages.

API integrations

Line-of-business data surfaced through secured mediation.

Teams-integrated experiences

Shared components across SharePoint and Teams where applicable.

SPFx web parts

SPFx Web Parts

A web part is the primary SPFx building block: authors drop it on a page, configure its properties, and it renders a React UI bound to SharePoint, Graph, or business data.

  1. Step 1

    SPFx Web Part

    The packaged component deployed through the App Catalog.

  2. Step 2

    Properties

    Configured values from the property pane, editable by page authors.

  3. Step 3

    React / UI

    Components, Fluent UI controls, loading and error states.

  4. Step 4

    SharePoint / Graph / APIs

    Data layer via REST, PnPjs, Graph, or mediated business APIs.

  5. Step 5

    Business Experience

    The working outcome: approvals, directories, requests, insight views.

Web-part fundamentals — properties, React rendering, and data access — are covered across this hub and in What is SPFx?. Step-by-step web-part build tutorials are among the highest-priority additions on the content roadmap; the SPFx roadmap update tracks where the platform itself is heading in the meantime.

SPFx and React

SPFx + React

React is the standard UI layer for SPFx. Keep a strict separation: SPFx owns hosting and context, React components own rendering, and a thin service layer owns data access. This hub orients the architecture — it is not itself a React tutorial.

  1. Layer 1

    SPFx

    Hosting, lifecycle, properties, and context (page, user, theme).

  2. Layer 2

    React Component

    One responsibility per component; props flow down.

  3. Layer 3

    State / Hooks

    useState and useEffect for data, loading, and error state.

  4. Layer 4

    Fluent UI

    Controls that match the Microsoft 365 look and accessibility baseline.

  5. Layer 5

    Microsoft 365 Data

    Lists, Graph, and APIs bound through a thin service layer.

  • React components
  • Props
  • State
  • Hooks
  • useEffect
  • useState
  • Reusable components
  • Fluent UI
  • Loading states
  • Error states
  • Performance
  • Component architecture

SharePoint data access

SPFx + PnPjs

PnPjs is a community-supported JavaScript library that wraps SharePoint REST and Microsoft Graph calls in a fluent, typed API. The relationship is one-directional: SPFx provides the hosting and authentication context, PnPjs simplifies the data calls made inside it.

  1. Layer 1

    SPFx

    Web part or extension with user context and lifecycle.

  2. Layer 2

    PnPjs

    Fluent queries, batching, and typed responses over REST and Graph.

  3. Layer 3

    SharePoint / Microsoft Graph

    Lists, libraries, files, users, and groups.

Typical PnPjs operations in SPFx solutions:

  • Reading lists
  • Creating items
  • Updating items
  • Deleting items
  • Libraries
  • Files
  • Folders
  • Users
  • Groups
  • Batching
  • Filtering
  • Selecting fields
  • Error handling

Dedicated PnPjs walkthroughs are on the content roadmap; until then, apply the data-access principles in the Graph section and the REST guidance below — selecting fields, batching, and error handling transfer directly.

Microsoft 365 data

SPFx + Microsoft Graph

The Microsoft Graph client gives SPFx solutions delegated access to Microsoft 365 data beyond SharePoint — people, groups, Teams, mail, calendar, and files — under the signed-in user’s identity. Graph access is never automatic: each permission must be requested and approved.

  1. Stage 1

    SPFx

    Component with user and page context.

  2. Stage 2

    Microsoft Graph Client

    Authenticated, delegated calls on the user’s behalf.

  3. Stage 3

    Microsoft Graph

    One endpoint surface for Microsoft 365 workloads.

  4. Stage 4

    Users · Groups · Teams · Mail · Calendar · Files

    Workload data rendered in the SharePoint experience.

  • Users
  • Groups
  • Teams
  • Mail
  • Calendar
  • Files
  • Microsoft 365

Authentication context

Calls run as the signed-in user. There is no elevated service identity to hide behind — access errors mirror the user’s real permissions.

Delegated permissions

Request delegated scopes matching each call. Application permissions do not apply to browser-hosted SPFx solutions.

API permission requests

Declare every Graph scope in the solution package so reviewers see the full access surface before approval.

Tenant administrator approval

Requested scopes stay dormant until an administrator approves them. Unapproved permissions fail at runtime.

Least privilege

Prefer narrow scopes over broad ones, and re-justify each scope when the solution’s data needs change.

Graph API calls and error handling

Handle 401 (authentication) and 403 (authorization) distinctly, page large collections, and respect throttling signals.

SharePoint-specific data

SPFx + SharePoint REST

SharePoint REST remains the direct route for SharePoint-specific operations — lists, items, libraries, files, folders, and site information — especially where a wrapper adds no value. Choose the API per scenario rather than defaulting to one everywhere: PnPjs for fluent SharePoint data access, Microsoft Graph for cross-workload Microsoft 365 data, and raw REST where precise control over the SharePoint call matters. No single option is universally superior.

  • Lists
  • Items
  • Libraries
  • Files
  • Folders
  • Site information

Advanced integration

External API Integration

Business systems enter SPFx solutions through authenticated HTTP calls to mediated endpoints — never through direct browser-to-database paths or embedded credentials.

  1. Stage 1

    SPFx

    Component initiating the business request.

  2. Stage 2

    Authentication

    Microsoft Entra ID, OAuth flows, and tokens acquired in user context.

  3. Stage 3

    External API

    The business system’s HTTP surface, reached where applicable via the SPFx HTTP clients.

  4. Stage 4

    Business System

    CRM, ERP, service desk, or custom backend returning scoped data.

  • Microsoft Entra ID
  • OAuth
  • CORS
  • API permissions
  • Tokens
  • Secure API architecture
  • Backend mediation
  • Error handling

Security rule: never put client secrets or sensitive credentials in SPFx browser code. Bundles are downloadable by design. Secrets belong in a secured backend or managed identity flow that the SPFx solution calls — a backend or API-mediation layer is required wherever the API cannot authenticate the user directly.

API decision guide

PnPjs vs Microsoft Graph vs SharePoint REST

SPFx does not force one data-access path. Choose based on ownership, permissions, workload, supportability, and whether the call belongs in the browser or behind a secured API layer.

PnPjs

Best for: SharePoint lists, libraries, files, folders, users, groups, and ergonomic SharePoint data access.

Watch: Initialize with SPFx context, select only required fields, and batch carefully.

SPFx + PnPjs guide

Microsoft Graph

Best for: Cross-workload Microsoft 365 data such as users, groups, Teams, mail, calendar, OneDrive, and files.

Watch: Every delegated permission must be requested, approved, and justified.

SPFx + Graph guide

SharePoint REST

Best for: Direct SharePoint-specific calls where precise REST behavior or troubleshooting control matters.

Watch: Validate field names, paging, request digest requirements for writes, and threshold behavior.

Complete SPFx guide

External APIs

Best for: Business systems, custom services, Azure Functions, and integration endpoints outside Microsoft 365.

Watch: Use a safe API layer for secrets, CORS, token handling, and server-side access control.

Planning an SPFx build?

Validate the Architecture Before You Code

Share the web part, extension, API, permission, and modernization decisions you are weighing, and nextM365 can help turn them into a supportable implementation path.

Discuss an SPFx Project

Page and list chrome

SPFx Extensions

Extensions customize the experience around content rather than adding page components. There are three types, each with a distinct surface:

SPFx Extensions

├── Application Customizer

├── Command Set

└── Field Customizer

Application Customizer

Runs on site pages to inject headers, footers, banners, and page-level logic through supported placeholders.

Use case: A compliance banner and support link rendered on every page of the finance hub.

ListView Command Set

Adds command-bar buttons that act on the rows a user selects in a list or library view.

Use case: A “Request approval” action that starts a workflow for the selected documents.

Field Customizer

Changes how a column value renders inside list views without changing the stored data.

Use case: Risk scores shown as color-coded pills instead of raw numbers in the register view.

Ship to production

Deployment & App Catalog

Deployment is a governed pipeline, not a file copy. Every stage below uses the toolchain supported by the SPFx release being shipped — confirm commands against that release’s documentation rather than reusing steps from older projects.

  1. 01

    Develop

    Build and debug locally against realistic SharePoint data.

  2. 02

    Build / Bundle

    Produce optimized bundles with the supported SPFx toolchain for your release.

  3. 03

    Package

    Create the versioned solution package for distribution.

  4. 04

    App Catalog

    Upload the package to the tenant or site-collection catalog.

  5. 05

    Deploy

    Make the solution available, tenant-wide or scoped, per governance.

  6. 06

    Approve Permissions

    A tenant administrator approves the requested API permissions.

  7. 07

    Use in SharePoint

    Add web parts to pages and activate extensions where designed.

Solution package

Versioned, reviewable artifact — the unit that moves through environments.

Tenant-wide deployment

Available everywhere where governance allows; scoped deployment where it does not.

Versioning and upgrades

Bump versions deliberately; test upgrades against existing pages before rollout.

Deployment validation

Verify web parts render, extensions activate, and permissions behave in a non-production tenant first.

Environment configuration, CI/CD, and ALM practices ride on top of this pipeline — the SPFx roadmap update is the reference for where the platform’s deployment story is heading.

Release engineering

SPFx CI/CD

CI/CD for SPFx is mostly artifact discipline: restore, validate, bundle, package, review, deploy, and smoke test. GitHub Actions and Azure DevOps can both support this pattern, but the exact commands should come from the SPFx release and package scripts used by the project.

  1. Gate 1

    Source Control

    Keep SPFx source, package metadata, and environment notes reviewable.

  2. Gate 2

    Install

    Restore dependencies with the package manager and versions supported by the target SPFx release.

  3. Gate 3

    Validate

    Run linting, tests, type checks, and any local build gates the project owns.

  4. Gate 4

    Bundle / Package

    Create optimized bundles and a versioned solution package.

  5. Gate 5

    Release

    Promote the artifact through App Catalog review and tenant admin approval.

  6. Gate 6

    Smoke Test

    Verify page rendering, extensions, permissions, Graph calls, and telemetry after deployment.

Version discipline

SPFx Version and Compatibility Checks

SPFx compatibility changes over time, so this hub avoids hard-coding Node.js, React, TypeScript, or package versions. Use Microsoft’s current SPFx documentation as the source of truth, then record the supported matrix inside the project before development starts.

SPFx release

Start with the Microsoft-supported release target for the tenant and scenario.

Node.js and package manager

Use the versions supported by that SPFx release, not the newest version by default.

TypeScript and React

Align compiler and framework versions with the SPFx baseline before adding dependencies.

PnPjs and Fluent UI

Choose library versions that support the target SPFx stack and browser surface.

Microsoft Graph endpoints

Confirm endpoint availability, permissions, paging, throttling, and beta versus v1.0 status.

Tenant environment

Validate App Catalog scope, admin approval process, modern page support, and governance controls.

Enterprise engineering

SPFx Security

Browser-hosted code faces hostile networks and curious users. These practices separate enterprise SPFx work from demos that happen to run.

Critical rule: SPFx runs in the browser. Confidential secrets must not be embedded in the client bundle.

Least privilege

Request only the API permissions the solution actually calls.

Graph and API permissions

Declare every protected permission up front; nothing is implicit.

Microsoft Entra authentication

Run in the signed-in user’s delegated context — no service identities in browser code.

No client secrets in browser code

Bundles ship to the browser. Secrets, keys, and connection strings must never be embedded in them.

Input validation

Validate property-pane values, query strings, and user input before use.

Secure external APIs

Call business systems through authenticated, mediated endpoints — not direct database or secret-bearing calls.

Tenant administrator approval

Graph and third-party API access requires explicit admin consent per solution.

Dependency security

Audit npm packages, remove unused dependencies, and update known-vulnerable libraries.

Data exposure

Render only what the current user is allowed to see; client-side checks never replace server-side access control.

Logging

Log failures with correlation details for support — without capturing tokens or personal data.

Error messages

Show users actionable messages; keep stack traces and internals out of the UI.

Permissions vs SharePoint access

API approval grants the solution a ceiling; each user still only reaches SharePoint content they can access.

Fast by design

SPFx Performance

Performance in SPFx is dominated by data access patterns and bundle discipline — not by framework choice. Apply these practices from the first sprint; retrofitting them is expensive.

Avoid unnecessary API calls

Fetch once per need; derive view state locally instead of re-querying.

Batch requests where appropriate

Combine independent reads so pages pay one round trip instead of many.

Select only required fields

Project list and Graph queries to the columns and properties the UI renders.

Caching

Cache reference data with explicit expiry; never cache per-user sensitive data carelessly.

Lazy loading

Defer heavy controls and secondary tabs until the user needs them.

Bundle size

Import only the library surface used; watch for duplicated framework copies.

React rendering

Memoize expensive lists, key rows stably, and avoid state churn on scroll.

Large list considerations

Page, filter server-side, and index the columns queried — the 5,000-item threshold still shapes design.

Loading states

Skeletons and placeholders keep perceived performance high during fetches.

Error handling

Fail fast with retry only for transient faults; surface persistent failures clearly.

Fix it faster

SPFx Troubleshooting

Most SPFx failures fall into three buckets. Diagnose the bucket first — environment, deployment, or data and authentication — then work the specific symptom. Each entry below names the usual cause and the first isolation step.

Environment and toolchain

  • Development environment not working: Re-verify the prerequisites supported by your SPFx release, then isolate with a fresh sample project before touching the real one.
  • Node.js and SPFx compatibility problems: Each SPFx release supports specific Node.js versions. Version drift is the most common cause of inexplicable build failures.
  • Package installation errors: Clear caches, confirm registry access, and check for conflicting global tooling before retrying installs.
  • Build errors: Read the first error, not the last: TypeScript and bundling failures cascade, and the root cause sits at the top.
  • Manifest problems: Duplicate component IDs, malformed manifests, and stale serve configurations break loading silently — diff against a working baseline.
  • Dependency conflicts: Mixed React copies and incompatible library versions cause runtime duplication. Align versions with the SPFx release baseline.

Deployment and visibility

  • Web part not appearing: Confirm the package deployed, the app is added to the site, and the page targets a supported surface.
  • Solution not appearing in the App Catalog: Check package validity, catalog permissions, and whether upload actually completed — failed uploads often report quietly.
  • Deployment failures: Validate the package, tenant-scoped deployment settings, and version conflicts with an already-deployed solution.
  • API permissions not approved: Permission requests wait in the admin center until a tenant administrator approves them. Unapproved permissions fail at runtime, not at deploy time.

Data and authentication

  • Microsoft Graph 401: Authentication failed: the token is missing, expired, or never consented. Re-check sign-in context and admin approval.
  • Microsoft Graph 403: Authorization failed: the permission was not requested, not approved, or is broader than granted. Compare requested versus approved permissions exactly.
  • SharePoint REST errors: Verify list and field names, request digest handling for writes, throttling responses, and list-view threshold behavior on large lists.
  • PnPjs errors: Most PnPjs failures trace to initialization context, missing select or expand clauses, or batching misuse — reproduce the call as raw REST to isolate.
  • External API CORS errors: Browsers block cross-origin calls the API has not allowed. Fix it on the API side (allowed origins) or through a mediated backend — not with browser workarounds.
  • Authentication problems: Separate sign-in failures (identity, conditional access) from consent failures (permissions) — they have different owners and different fixes.

Related published resources

These pages cover the concepts behind the symptoms above — permissions, extensions, and platform direction. Step-by-step fix guides for individual errors are future content.

SharePoint modernization

SPFx + SharePoint Modernization

Modernization decides the fate of every legacy customization before it moves forward: inventory, assess, then retire, replace, modernize, or rebuild. SPFx is the destination for capabilities that must remain custom code — everything else should become a modern or Power Platform capability.

  • Script Editor Web Parts
  • Content Editor Web Parts
  • Custom JavaScript
  • JSLink
  • Custom Master Pages
  • Classic pages
  • SharePoint Designer workflows
  • InfoPath
  • Legacy SharePoint solutions
  • Unsupported customizations
Modernization mapping from legacy SharePoint approaches to modern options
Legacy approachModern direction
Script Editor / custom JavaScriptSPFx where custom code remains necessary
JSLinkJSON formatting or SPFx depending on requirements
SharePoint Designer workflowPower Automate where appropriate
InfoPathPower Apps, modern forms, or another supported solution depending on requirements
Custom master pagesModern SharePoint branding and extensions
Legacy integrationsMicrosoft Graph, supported APIs, and SPFx architecture

These mappings are starting directions, not automatic one-to-one replacements. Some workflows simplify into approvals, some forms become lists with formatting, and some customizations should be retired rather than rebuilt.

Solution blueprint

SPFx Architecture Example: Employee Portal

A reference shape for how SPFx solutions typically compose — illustrative, not a customer story.

  • SharePoint Online hosts pages, lists, and libraries — the content foundation.
  • SPFx renders the portal UI: web parts for news, directories, and requests.
  • Microsoft Graph supplies people, files, and calendar data under user identity.
  • Power Automate handles approvals and notifications behind portal actions.
  • External business API contributes line-of-business data through a mediated, authenticated endpoint.
  • Microsoft Entra ID authenticates users and backs delegated permission checks.

Automation patterns behind portal actions live in the Power Automate hub and the Power Platform hub.

Guides and references

SPFx Knowledge Library

Every item below is published nextM365 content — SPFx guides first, then the questions and decisions developers actually ask, then companion architecture reading. Nothing unrelated is listed to fill space.

Start and platform direction

SharePoint Framework (SPFx) Complete Guide
SharePointSep 17, 2026

SharePoint Framework (SPFx) Complete Guide

Learn SPFx development end to end: project setup, React web parts, PnPjs, Microsoft Graph, REST, extensions, security, App Catalog deployment, and troubleshooting.

By Suresh Girinathuni25 min read

Web parts, React, and Copilot-era interfaces

SPFx + React: Complete Developer Guide
SharePointSep 17, 2026

SPFx + React: Complete Developer Guide

Build production SPFx solutions with React architecture: components, hooks, services, PnPjs, Graph, Fluent UI, error handling, performance, and testing.

By Suresh Girinathuni22 min read

PnPjs, Graph, and API foundations

SPFx + PnPjs: Complete Developer Guide
SharePointSep 17, 2026

SPFx + PnPjs: Complete Developer Guide

Use PnPjs in SPFx with current patterns for lists, CRUD, filtering, paging, batching, files, users, groups, and search — behind a service layer.

By Suresh Girinathuni21 min read
SPFx + Microsoft Graph: Complete Developer Guide
SharePointSep 17, 2026

SPFx + Microsoft Graph: Complete Developer Guide

Use Microsoft Graph with SPFx securely: delegated authentication, least-privilege permissions, users, groups, Teams, files, paging, throttling, and production readiness.

By Suresh Girinathuni23 min read
Microsoft Graph API Explained for Beginners
Microsoft 365Aug 6, 2026

Microsoft Graph API Explained for Beginners

A beginner-friendly Microsoft Graph API guide explaining what Graph is, how requests work, permissions, tokens, endpoints, common use cases, and safe API design.

By Suresh Girinathuni11 min read

Troubleshooting and modernization

SPFx Troubleshooting: Errors, Causes & Fixes
SharePointSep 17, 2026

SPFx Troubleshooting: Errors, Causes & Fixes

Diagnose SPFx failures layer by layer: Node.js, build, deployment, web parts, PnPjs, REST, Graph permissions, CORS, and production-only errors — with fixes.

By Suresh Girinathuni24 min read
SharePoint Migration + SPFx Modernization Blueprint
MigrationSep 17, 2026

SharePoint Migration + SPFx Modernization Blueprint

An end-to-end blueprint connecting SharePoint migration with SPFx modernization: assessment, target architecture, waves, validation, and governance.

By Suresh Girinathuni20 min read

SPFx questions

Common SPFx Questions

What is SPFx?

SPFx (SharePoint Framework) is Microsoft’s client-side development model for extending SharePoint, Teams, and Viva Connections with modern web technologies such as TypeScript and React.

Read answer →

What are SPFx extensions?

SPFx extensions customize SharePoint list, library, and page experiences: Application Customizers inject header/footer and page behavior, Field Customizers re-render columns, and Command Sets add command-bar actions.

Read answer →

What is Microsoft Graph?

Microsoft Graph is the unified API for Microsoft 365: one endpoint model to read and manage users, groups, Teams, SharePoint, mail, calendars, and more — governed by explicit permissions and consent.

Read answer →

Technical discussion

Working Through a Complex SPFx Implementation?

Bring the architecture, API choices, permissions, deployment path, modernization dependencies, or troubleshooting symptoms, and nextM365 can help shape a practical implementation plan.

Discuss an SPFx Project

Related categories and tutorials

Related toolsLearning paths

Frequently asked questions

What is the SharePoint Framework (SPFx)?

SPFx is Microsoft’s client-side development model for extending SharePoint and related Microsoft 365 experiences with web parts, extensions and API integrations built with TypeScript and React. Solutions run in the browser in the current user’s context and deploy as packages through the SharePoint App Catalog.

When should I use SPFx instead of Power Apps?

Use SPFx when developers need custom SharePoint web parts, page extensions, or Microsoft 365 interface integrations with full code control. Use Power Apps for maker-led business applications, forms and workflow-facing experiences that do not need custom SharePoint UI.

Do SPFx solutions need administrator approval to call Microsoft Graph?

Yes. SPFx solutions request API permissions that a tenant administrator must approve before the solution can call Microsoft Graph or other protected APIs. Request only the least-privilege delegated permissions the solution needs, and never assume every endpoint is available automatically.

What SPFx extension types are available?

SPFx provides Application Customizers for page header, footer and behavior, Field Customizers for column rendering in list views, and ListView Command Sets for command-bar actions on selected items. All three deploy as packages through the App Catalog.