If you want a people directory for your intranet, one of the first decisions is whether to build a SharePoint employee directory yourself or buy a supported product. Microsoft 365 already holds all the data, and the SharePoint Framework gives skilled developers everything they need to read it, so building your own is genuinely possible. The question is not whether you can, but whether it is the best use of your time and budget. This is an honest build vs buy comparison, and it tries to be fair to both sides, because for some teams building really is the right call.
What it actually takes to build a SharePoint employee directory
A directory sounds simple until you list the moving parts. If you set out to build one in-house, here is the work you are signing up for.
- An SPFx web part. You need a SharePoint Framework solution to host the directory on a page, packaged, deployed to the app catalogue and added to your sites.
- Calling Microsoft Graph. The people, job titles, departments, offices and reporting lines all live in Microsoft 365, and you reach them through the Graph API.
- Photos at scale. Fetching a profile photo per person one request at a time will crawl on a large tenant. You need to batch photo requests and cache them so pages stay fast for thousands of users.
- Teams presence. Showing who is available, busy or away means fetching presence efficiently rather than one call per card, and caching it so you do not hammer the service.
- Paging thousands of users. Graph returns people in pages. Handling that cleanly, without freezing the browser, takes care.
- Search and filters. People expect instant search across name, title and department, plus filters for department and office location, and something like an A to Z jump bar.
- An org chart. Building a reporting view from each person's manager and direct reports adds another set of Graph calls and layout logic.
- Permissions and consent. Reading people and presence requires the right Graph scopes and admin consent, and your IT and security teams will rightly want to review exactly what you are requesting.
- Accessibility and theming. To sit properly in a modern intranet, the directory must be keyboard accessible, screen-reader friendly and respect the site theme, including dark mode.
None of this is exotic for an experienced SPFx developer, but together it is a real project, not an afternoon's work. Getting a rough version working is one thing. Making it fast and pleasant on a tenant with several thousand people is another.
The ongoing costs that are easy to miss
The build cost is only the beginning. What catches teams out is the maintenance, because a directory is not a project you finish, it is software you own.
- Developer time. Bugs, feature requests and support all land on whoever built it. If that person moves on, you inherit a codebase nobody fully understands.
- Graph throttling. Microsoft Graph enforces rate limits. On a large tenant a naive directory will hit them, so you have to design around throttling and keep tuning as usage grows.
- Keeping up with change. The SharePoint Framework, the Graph API and the surrounding tooling all move. Node versions, package updates and deprecations mean periodic rework just to stay current, even when you add no new features.
- The Microsoft Graph Toolkit retirement. Many in-house directories lean on the Microsoft Graph Toolkit to render people, cards and presence quickly. The Graph Toolkit reaches end of support on 28 August 2026, which breaks solutions that depend on it and forces a rebuild of those components. If you are starting a build now, choosing that toolkit would be building on ground that is about to shift.
These are the costs that rarely make it into the original estimate, and they are the ones that decide whether a home-grown directory ages well or quietly rots.
When building in-house makes sense
Building is not the wrong answer. For some organisations it is clearly the best one. Building tends to pay off when several of the following are true.
- Very specific requirements. If you need bespoke fields, unusual layouts or tight integration with an internal system that no off-the-shelf product will match, owning the code gives you full control.
- In-house SPFx skills. If you already employ developers who know the SharePoint Framework and Microsoft Graph well, the build itself is far cheaper and less risky.
- Time and appetite to maintain it. If you can commit to keeping the solution current as the platform changes, and treat it as a small ongoing product rather than a one-off, it can serve you for years.
The honest pros of building are control, no per-tenant licence fee and a directory shaped exactly to your needs. The honest cons are the up-front effort, the standing maintenance burden and the key-person risk if the developer who built it leaves.
When buying is the better value
For most teams, a supported product wins on total cost of ownership. You skip the build, you skip the maintenance, and someone else keeps up with SharePoint Framework and Graph changes on your behalf. The trade-off is a subscription fee and accepting the product's feature set rather than an exact bespoke fit.
This is the gap a tool like Glow Cloud Directory is designed to fill. It is a SharePoint Framework (SPFx) web part, currently version 2.0, for SharePoint Online and Microsoft 365, and a Glow Cloud Kit product from Glow Cloud Solutions. You add it to a page, point it at your own tenant, and it reads live people data rather than asking you to maintain a second copy.
Crucially for the timing above, Glow Cloud Directory was built with no Microsoft Graph Toolkit dependency, so it is unaffected by the August 2026 retirement. It uses only three read-only Graph scopes, User.Read.All, Presence.Read.All and User-LifeCycleInfo.Read.All (work anniversaries), runs as the signed-in user, and keeps all directory data inside your own tenant. It batches profile photos and caches presence so large tenants stay fast, which is exactly the performance work an in-house build has to solve from scratch.
On features, it covers what most organisations actually ask for: contact cards with photos, Teams presence, instant search with department and office location filters, an A to Z bar, an org chart on demand, opt-in birthdays and anniversaries, self-service profile fields, guests excluded by default, and configuration export and import. Pricing is from £29 per month per tenant for unlimited users, with a 14-day free trial through Glow Cloud Kit. Set that against the developer days a build consumes, and for many teams the maths favours buying.
How to make the decision
A quick way to choose is to be honest about three things: how unusual your requirements really are, whether you have SPFx skills in-house today and in two years, and whether you have the appetite to maintain software as the platform shifts. If your needs are standard and you would rather not own a codebase, buy. If your needs are genuinely bespoke and you have the skills and the commitment, build, but go in with eyes open about the maintenance and about the Graph Toolkit deadline.
Either way, it helps to know what good looks like before you commit. For more on the native options and how to present people well, see our more guides, including how to create an employee directory in SharePoint Online and the different ways to display a staff directory in SharePoint.
If you would rather try the buy path before writing a line of code, you can see a live, searchable directory in your own environment with the Glow Cloud Directory free trial.