The two paths you're given
The built-in web parts cover the basics well. When a page needs something beyond them, such as an org chart from your own data or a calendar that overlays more than one list, there are two paths. On one side: workarounds. Hand-written JSON view formatting, calculated columns, stacked sections standing in for real navigation. They take real skill to build, they're invisible to whoever inherits the site, and they break when Microsoft updates something. On the other side: custom development. An SPFx project, an agency engagement, or a full intranet platform, each a commitment of budget, timeline, and lock-in far out of proportion to "I need one better web part on this page."
Zenpo Intranet Suite for SharePoint is the third option: eighteen production components that are already built, already tested, and drop into the pages you already have. It is SPFx, but SPFx we solved, so you don't have to.
Your SharePoint content stays in your tenant
Customer SharePoint content and list data stay in the tenant. Zenpo does not use Microsoft Graph or a proprietary content backend, and there are no admin consent grants and no content telemetry. Zenpo does use an external service for licensing and registration: it receives your domain and the product owner's email, and it does not receive customer SharePoint content or list data.
That architecture answers much of a security review up front. The verified scope today is commercial SharePoint Online and GCC.
The lists you already have
SharePoint supports JSON view formatting for custom list presentation. Zenpo web parts instead let you map existing list columns through the property pane, without requiring a fixed schema or migration. Each one uses schema-agnostic field mapping: you point it at a list and map its columns, whatever they're actually called. No mandated column names, no provisioning scripts, no content types, no migration. Your data stays your data, structured the way you structured it.
Additive, not a replacement
Intranet platforms ask you to replace your intranet. We ask you to improve one page. Adopt one component on one page; keep every built-in web part, and keep your existing vendor if you have one. Nothing is ripped out and nothing is migrated, and if you ever remove Zenpo, your content is exactly where it always was: in your lists and libraries. Because the suite honors SharePoint permissions and needs no central rollout, any authorized team site can improve its own pages without asking an intranet authority or a specialist author for permission.
Things modern SharePoint still doesn’t do
Many of the web parts extend common SharePoint page patterns. A few address gaps that modern SharePoint does not currently cover:
An org chart from a list. Microsoft's own documentation says the built-in chart "only supports displaying the organizational relationship of a specific user," that it "cannot export," and that "External users cannot be added." It stops working entirely where Entra manager data is missing, and Microsoft has advised a customer in writing to use "a third-party solution that supports more complex organizational structures." Our Org Chart draws the whole tree from a SharePoint list you control.
A multi-list calendar overlay with per-source colour. Classic SharePoint did this. Modern SharePoint does not. Full Calendar brings it back.
Correct recurring-date logic for birthdays and work anniversaries, which is hard to build with calculated columns and formatting rules.
Built on supported SharePoint APIs
Microsoft changes SharePoint's interface regularly and without warning, and those changes can break carefully built pages, sometimes in ways the page owner can't even see from their own account. Customizations that hook into page markup or CSS break when that markup changes; Microsoft states that page DOM and CSS are unsupported and subject to change.
We build only on Microsoft's supported SharePoint APIs and never take a dependency on page DOM or CSS. When SharePoint changes, keeping our web parts working is our responsibility. We don't prevent Microsoft from changing SharePoint; we keep our own products compatible as it does.
How we write about SharePoint
Our guides explain the native SharePoint approach first, including when the built-in web part already fits the requirement. Where the native approach has a ceiling, the guide names it plainly, and you can decide for yourself whether you've hit it. Helpful first, product second.
This isn't a promise for later. The library already exists. Our SharePoint how-to guides cover the out-of-the-box web parts today, and we keep them current as Microsoft updates the platform.
Browse the SharePoint how-to guides →Curious what the eighteen components are? See the full suite, or read about the two already on the Microsoft Marketplace.