EXPLAINER

What is SharePoint?

SharePoint is Microsoft's platform for team sites, document libraries, pages and intranet content inside Microsoft 365. Custom UI on modern pages is built with the SharePoint Framework, not classic farm solutions.

Short answer: SharePoint stores and presents an organisation's pages, lists and files inside Microsoft 365. Modern custom web parts are built with SPFx, and data often comes from Microsoft Graph.

What it is

SharePoint is a Microsoft 365 service for storing files, structuring lists of data, and publishing intranet pages. A site is the container: it has owners, members, pages, document libraries and lists. A library is a folder-like store with version history, metadata columns and permissions. A list is a table of items with columns you define. Modern pages are made of web parts, the rectangular components that show news, lists, files or custom UI.

SharePoint Online (often called SPO) is the cloud service in Microsoft 365. SharePoint Server is the older self-hosted product. Most new work targets SharePoint Online. The address of a site looks like https://contoso.sharepoint.com/sites/finance. That URL is the home for both human browsing and many APIs.

Why and when it is used

Teams use SharePoint when more than one person must work on the same files with permissions, version history and a page that explains the work. Typical cases are a department intranet, a project site, a controlled document library, and the file storage behind a Microsoft Team. Teams files actually live in a SharePoint library; the Teams tab is a view on top.

Choose SharePoint when the content should stay inside the Microsoft 365 tenant, inherit Entra ID identities, and be governable by the same admins who run Exchange and Teams. Do not choose it as a general-purpose application database. High-volume transactional data belongs in a database such as PostgreSQL or Azure data services. SharePoint lists are fine for thousands of business rows, not for millions of events per day.

How it works

A user signs in with an Entra ID account. SharePoint checks the token, then evaluates permissions on the site, library, folder or item. Modern pages are client-rendered: the browser loads the page, then loads web parts. Out-of-the-box web parts cover text, images, lists and news. Custom web parts are built with the SharePoint Framework and deployed as a package to the tenant app catalog.

Behind the page, content is addressable by REST and by Microsoft Graph. Graph is the cross-product API (sites, drives, lists, mail, calendar). SharePoint also has its own REST endpoints under /_api. Files are stored in drives; each library is a drive. Versioning keeps prior bytes so a bad save can be restored. Search crawls sites so people can find pages and documents without knowing the URL.

Technologies and dependencies

SharePoint depends on Entra ID for users and groups, on the Microsoft 365 tenant for licensing, and on the app catalog if you deploy custom SPFx solutions. Branding and web parts depend on SPFx, TypeScript and usually React. Automation often uses Power Platform (Power Automate flows on libraries) or Graph calls from your own service.

Permissions are not the same thing as Azure RBAC. A site owner, a library role and an Entra group assignment are different layers. Breaking inheritance on a folder is powerful and easy to make unauditable. External sharing uses guest accounts or share links, which is an identity decision as much as a SharePoint decision. If a web part calls Graph, an administrator must approve the API permission in the SharePoint admin center.

How to get started

  1. Sign in to a Microsoft 365 tenant that includes SharePoint. A developer tenant from the Microsoft 365 Developer Program is enough to learn.
  2. Create a team site. Add a document library and one list with a few columns so you can see metadata versus folders.
  3. Edit the home page and add standard web parts. Publish the page.
  4. Note the site URL, the library name and how permissions change when you share with a person versus a group.
  5. When you need UI that the built-in web parts cannot provide, move to building an SPFx web part rather than injecting script into a classic page.
  6. Read Graph's sites and drives APIs before you write an integration. Prefer Graph for new code; keep /_api for gaps Graph does not cover yet.

Start with one real library and a written permission model. A site per project, a group per role, and as little broken inheritance as you can live with.

Cautions and trade-offs

SharePoint is a content platform with an API, not a low-latency application backend. Lists have throttling thresholds; unique permissions explode complexity; classic solutions and script editors are the wrong place for new UI. Customisation should go through SPFx so it survives modern pages and tenant administration.

Search is eventually consistent. A file you just uploaded may not be findable for a short time. Sync clients (OneDrive sync of a library) create offline copies that can conflict. Large migrations fail when filenames contain illegal characters or paths exceed length limits. Governance matters: without site lifecycle rules, tenants fill with abandoned project sites that still hold sensitive files. Treat external sharing as a security setting and review it, and do not store secrets or raw credentials in a library even if permissions look tight.