Building an employee directory in SharePoint

Last updated:

Check what you already have first. SharePoint's built-in People web part shows selected colleagues with their photo, title and contact details straight from Entra ID, at no cost and with no deployment. If your requirement is a handful of contacts on a team page, that is the answer and you are done in five minutes.

It stops when you need a real directory: everyone, searchable, grouped by department or location, with fields Entra ID does not hold — who to call about expenses, which office someone sits in on Tuesdays, who covers a region.

At that point, the fastest route is to describe it to Sharelio, the AI platform for building SharePoint tools: “an employee directory as cards with photo, name, role, department, location and extension, searchable and grouped by department”, backed by a list you control.

The decision that matters: where the data comes from

Everything else follows from this, and it is the question most directory projects skip.

Entra ID (the directory)A SharePoint list
Kept up to date byIT and HR processes that already existWhoever you appoint — a real, ongoing job
Leavers disappear automaticallyYesNo, unless someone removes them
Custom fieldsOnly what your tenant is configured to holdAnything you want
PhotosFrom Microsoft 365 profilesYou manage them
Effort to startNoneAn import, then maintenance

The trap is choosing a list because you want two extra fields, and inheriting the whole maintenance burden of a directory that will be quietly wrong within a year. If the data lives in Entra ID, keep it there — and if you need extra fields, the cleanest answer is usually to ask IT whether they can be added to the directory itself, before building a parallel one.

The three routes

RouteCostBest for
Built-in People web part€0A team page, a handful of named contacts. Reads Entra ID, always current.
A list plus a cards componentFree plan, then flat per tenantA full directory with your own fields, search and grouping, looking native on the page
Bespoke SPFx reading Microsoft Graph€3,000–8,000Live directory data with custom presentation — and a tenant-wide Graph permission to justify

Note what the third row really costs: a component that reads the whole directory from Microsoft Graph needs a tenant-wide directory permission, which is a genuine security conversation and one of the slower approvals to get. Worth knowing before it is discovered halfway through the project — see what you are actually approving.

The part people regret skipping

A staff directory is personal data, and a company-wide one is personal data about everybody. Three things to settle before launch rather than after the first complaint:

  • Which fields are voluntary. Photo, mobile number and personal pronouns are commonly optional; publishing them by default is where objections come from.
  • Who can see it. Everyone internally is normal. Make sure the site is not somewhere with wider sharing than you think.
  • How someone gets an entry corrected or removed, and who acts on that. If the answer is “nobody knows”, the directory will not survive an HR review.

Sourcing from Entra ID helps here too: the fields are already governed by whatever policy your organisation applies to the directory, rather than by a spreadsheet somebody imported.

Frequently asked questions

Can we show an org chart?

If the manager field is populated in Entra ID, the built-in organisation chart in Microsoft 365 profiles already shows reporting lines and costs nothing. A custom org chart component is a bigger project than most people expect and depends entirely on that same field being accurate — check the data before commissioning the visual.

Where do profile photos come from?

From Microsoft 365 profiles, which is why routes based on Entra ID get them for free. If you build a directory on a SharePoint list, you are responsible for the photos too: storing them, updating them and dealing with people who want theirs changed. It is a bigger job than it sounds.

How do we handle leavers?

This is the strongest argument for sourcing from Entra ID: a leaver disappears because the account is disabled, with no action from you. On a list-based directory, removing leavers is a manual step tied to offboarding — and if it is not part of that checklist, it will not happen.

Can people update their own entry?

For Entra ID fields, users can edit parts of their Microsoft 365 profile depending on your tenant's policy — ask IT what is enabled. On a list-based directory you can grant contribute rights, but expect to pair it with light moderation. Self-service is what keeps a directory current; nothing else scales.