Trust
Security and data handling
How DirectoryPoint reaches your data, where what it keeps lives, who can read it, what is kept on each device, what leaves your tenant and how this website works. Written for IT, security and data protection reviewers.
Last updated: 3 November 2026, for DirectoryPoint 1.0. Draft for legal review: it describes how DirectoryPoint behaves as built, and is not legal advice.
In one paragraph
Your directory data stays in your Microsoft 365 tenant. DirectoryPoint runs in the browser of the person using it, reads people from Microsoft Graph or SharePoint as that person, keeps what people add and its own settings in SharePoint lists on the DirectoryPoint site, and keeps some copies in the browser on each device so pages open faster. Separately, it sends Apps 365 a small daily licence check-in, which a site owner can switch off. Apps 365 Ltd does not receive your directory data.
How DirectoryPoint reaches data
- As the signed-in person. DirectoryPoint is a SharePoint Framework solution: a SharePoint web part that is also a SharePoint full-page app, a Microsoft Teams tab and a Microsoft Teams personal app, and four Viva Connections dashboard cards. It has no server of its own: it acts with the permissions of the person using it and can only read what that person could read.
- Microsoft Graph, read-only and optional. It works with no Microsoft Graph permission (Basic). It requests three delegated, read-only permissions a Global Administrator may approve: User.Read.All, Presence.Read.All and People.Read. It never requests a permission that writes or changes anything. See permissions.
- Checked, never assumed. Each time it opens, DirectoryPoint checks which permissions are approved and uses only those.
- SharePoint lists. It reads and writes its own lists on the site where it is set up, with the signed-in person's own SharePoint rights. A site owner may name one other site of the same SharePoint host as the shared agent registry, which then holds DirectoryPoint Agents and DirectoryPoint Taxonomy; DirectoryPoint never reads or writes another host.
- Copies of directory details, and where they are. Details read from Microsoft Graph and SharePoint are not copied into DirectoryPoint's lists, with two exceptions: the snapshot a site owner chooses to publish for a large organisation (DirectoryPoint Snapshots), and the old and new values of a detail someone proposes to correct (DirectoryPoint Change Requests, and DirectoryPoint Audit once it is decided). Browsers also keep copies on each device, listed below.
- Its own code only. Every script is inside the package; nothing is loaded from a content delivery network, and apart from Microsoft Graph and SharePoint in your tenant and the licence check-in, DirectoryPoint's code calls no other service.
- The microphone, only when asked. Only when someone chooses to record how they say their name does the browser ask for the microphone. See the microphone.
What is stored, and who can read it
All lists are on the SharePoint site where DirectoryPoint is set up, in your tenant. Hiding is not a lock: anyone who can read a list can read every column of the rows they can see, whatever DirectoryPoint chooses to show. Keep site permissions in line with who should read the directory.
| List | Holds | Who can read | Who can change |
|---|---|---|---|
| DirectoryPoint Settings (hidden) | Directory source, who-is-listed policy, privacy defaults, celebrations switches, the agents switch and shared registry location, field mapping, change request routing, directory size and search-first choices, the top of the organisation for Data health, office time zones, the usage counting switch, the Who's Who switches, set-up and schema records, saved licence keys (never shown on screen) and the check-in switch | Everyone with access to the site | Site owners |
| DirectoryPoint People Extras | One row per person who saved something: "Ask me about", languages, other names they add ("also known as", up to four), whether to show their mobile number, birthday opt-in with day and month only, work anniversary opt-in, fields they hide from colleagues, how to say their name, pronouns (only as typed), how to work with them, and, if they record one, a few seconds of their voice saying their name as an attachment | Everyone with access to the site (anyone who can read the list can play a recording) | Each person their own row and its attachment; site owners |
| DirectoryPoint Skills | Skills people list about themselves, with level, source, last confirmed date and visibility | Everyone with access to the site | Each person their own rows; site owners |
| DirectoryPoint Taxonomy | Skill and task terms with synonyms (shared with other Apps 365 Point apps on the site) | Everyone with access to the site | Site owners |
| DirectoryPoint Favourites | Each person's private saves | Only that person, and site owners | Only that person, and site owners |
| DirectoryPoint Collections | Each person's private collections: manual ones, and smart ones as saved conditions | Only that person, and site owners | Only that person, and site owners |
| DirectoryPoint Shared Collections | A copy of each collection a person shares, one row per colleague it is shared with: its name, the people in it or its conditions, a note, and the sharer's and recipient's names and IDs | Everyone with access to the site (DirectoryPoint shows a row only to its sharer and recipient, and notifies nobody) | Only the person who shared it; site owners |
| DirectoryPoint Exclusions | Who-is-listed rules (sign-in name, domain, Entra group, employee type) | Everyone with access to the site (the rules are applied in each browser) | Site owners |
| DirectoryPoint Agents | AI agents people can find by task, with stored launch links (shared with other Apps 365 Point apps on the site) | Everyone with access to the site | Site owners |
| DirectoryPoint Audit | Administrator and approval actions: set-up, settings changes, rules added or removed, exports (who, when, how many rows, which columns), each change request decision and reopening with the request as it was decided, external contacts added, changed, removed, imported or exported, snapshots published or removed, and the shared registry location | Site owners | Added by DirectoryPoint; never deleted by the app |
| DirectoryPoint Change Requests | One row per proposed correction: the person it is about, who sent it, the field, the old and new values, the reason, the status, the approver and their note, and where the change is made | Each person sees only the requests they sent; site owners see every request | Each person their own requests (a request edited after its decision is held back from IT's summary until a site owner decides it again); site owners |
| DirectoryPoint External Contacts | Contractors, suppliers and partners a site owner adds or imports: name, company, email, phone, job title, other names, contact type, the colleague who looks after them, notes, and the audience (everyone, or Entra groups) | Everyone with access to the site: the audience only decides who DirectoryPoint shows a contact to, so anyone who opens the list reads every row, notes included | Site owners |
| DirectoryPoint Snapshots (library) | Only when a site owner publishes one: the listed people as colleagues see them (no hidden field, no mobile number without the person's opt-in, nobody the rules leave out), with copies of the Skills, People Extras and Taxonomy rows as any reader of those lists reads them | Everyone with access to the site | Site owners (publish, refresh, remove) |
| DirectoryPoint Kudos | For each person who turned kudos on, their public sealing key; each kudos waiting for its recipient as a sealed item; each accepted kudos in the open (sender, recipient, skill, message and when) | Everyone with access to the site (a sealed item reads only as "Sealed kudos" by its author, and when) | Each person their own rows; site owners |
| DirectoryPoint Kudos Private (hidden) | Each person's private sealing key, and the kudos they declined or removed (a reference only) | Only that person, and site owners (who can therefore open sealed kudos) | Only that person, and site owners |
| DirectoryPoint Usage (hidden) | Daily counts for the whole organisation: a day, what was counted (DirectoryPoint opened, searches, searches that found no one, profiles opened, Discover cards seen, saves, contact actions, card views) and how many. No names, IDs or search words | Everyone with access to the site (the list holds the exact numbers) | People who can add items to the site's lists, who can therefore also change or remove a count; site owners |
| DirectoryPoint Quiz Scores | Only for people who join the Who's Who scoreboard: their name, points, right, wrong and skipped answers, games played and when they last played | Everyone with access to the site (the scoreboard lists the players) | Each person their own row; site owners |
So anyone who can open the site can read: the choices people make about themselves (including what they hide, and a name recording), skills, agents, external contacts with their notes, the published snapshot, shared collections, accepted kudos and who has kudos turned on, the Who's Who scoreboard and the daily usage counts. DirectoryPoint says so where each is made. No birth year is stored anywhere: birthdays are day and month only, and withdrawing clears the date.
What site owners can read
The site's owners hold Full Control, which in SharePoint lets them read and change every row of every list, including the private ones: each person's favourites and collections, every change request, the audit list and each person's private kudos key. With that key a site owner could open sealed kudos to or from that person, past ones included. DirectoryPoint does not hide this: the Kudos page, the list descriptions and the privacy notice text for your staff say so. Choose your site owners with that in mind.
On each device
Browser storage is on the device only, never in a list, and is never sent anywhere by DirectoryPoint.
| What | Whose | Kept until |
|---|---|---|
| Photos of people on screen | Shared on the device (the same photos everyone in the organisation can see) | Replaced when a photo changes |
| Recent searches and recently viewed people | The signed-in person | The person clears them, or someone else opens DirectoryPoint in the same browser |
| Discover deck history (who was saved or skipped in each deck) | The signed-in person | Someone else opens DirectoryPoint in the same browser |
| The person's own copy of the directory, in organisations of 2,000 to 30,000 people on the Standard tier: the fields DirectoryPoint reads from Microsoft Graph for each account, including contact details and mobile numbers, compressed | The signed-in person (what they could read from Microsoft Graph anyway) | Read again in full after seven days; cleared in Settings, Directory size and snapshot; removed when someone else opens DirectoryPoint in the same browser |
| Copies of the published snapshot's files | Shared on the device (the same files everyone with access to the site can read) | Replaced when a new snapshot is published; cleared in Settings, Directory size and snapshot |
| Copies of the Skills, People Extras and Taxonomy rows, kept up to date through SharePoint's change log | The signed-in person (the same rows everyone with access to the site reads) | Read again in full after seven days; cleared in Settings, Directory size and snapshot; removed when someone else opens DirectoryPoint in the same browser |
| Which kudos rows were last looked at for the person (item numbers only, never what a kudos says or who sent it) | The signed-in person | Removed when they turn kudos off, when someone else opens DirectoryPoint in the same browser, and by Clear this device's copies |
| Where a site owner's snapshot publishing stopped, so it can carry on | The site owner's device | The publish finishes, or 24 hours pass |
| Usage counts not written yet (per day, what was counted and how many; no person, IDs or words) | The device (counts only) | Written to DirectoryPoint Usage within minutes; dropped after 14 days; forgotten when a site owner switches counting off |
| Which collections shared with the person they opened or put away on this device | The signed-in person | Someone else opens DirectoryPoint in the same browser |
| View state and whether the welcome card was answered | The device | The browser's own clearing |
A name recording stays in the browser, not saved anywhere, until the person presses Save. Signing out of Microsoft 365 runs no DirectoryPoint code, so it cannot clear these; when DirectoryPoint next opens in that browser for a different person, it removes the previous person's recent searches, deck history and copies. Clearing the browser's site data for the SharePoint address removes everything above.
How kudos are sealed
Kudos are each person's own choice: nothing is turned on for anyone.
- Keys made in the browser. When someone turns kudos on, their browser makes a key pair (ECDH P-256, with the browser's own Web Crypto). The private half goes to their own row in DirectoryPoint Kudos Private, which only they and site owners can read; the public half goes to DirectoryPoint Kudos, so anyone with access to the site can see who has kudos turned on.
- Sealed while waiting. The sender's browser encrypts the recipient, skill and message for the two of them (AES-GCM, with a key derived through HKDF-SHA-256 from the pair's keys), adds a tag only the recipient can recognise and a public commitment. Other colleagues, visitors and the list itself show only "Sealed kudos", by its author, and when.
- Accepted in the open. Accepting writes an accepted row that everyone's browser checks against the sender's sealed row and its author, so it cannot be reworded or made up. Declining and removing are the recipient's private rows: the sender is never told. A sender can withdraw a kudos, which removes the sealed row.
- Limits we say plainly. Site owners can read the private keys, so they could open sealed kudos. Turning kudos off removes a person's keys, so kudos still sealed for them can no longer be opened; turning it on again makes a new pair. Nobody is notified, emailed or messaged, and kudos are never counted or ranked across people.
Name recordings
A person who chooses to record how they say their name keeps a few seconds of their voice as an attachment to their own row in DirectoryPoint People Extras. It is personal data. Anyone who can read that list can play it, and on a profile it plays only when someone presses Play. Only the person and site owners can change or delete it. Deleting sends it to the site recycle bin at once, which SharePoint empties after up to 93 days. Pronouns are kept only as the person types them, and are never part of search, filters or exports.
Usage counts
Unless a site owner switches it off (More, Usage), DirectoryPoint counts how much it is used each day across the organisation, in the hidden list DirectoryPoint Usage: a day, what was counted and how many. No names, no IDs, no search words and no record of who viewed whom. The Usage page shows numbers under 5 as "Fewer than 5", but the list holds the exact numbers and anyone with access to the site can read it.
SharePoint records who created and who last changed each row, as it does for every list item, so on a day when only one or two people use DirectoryPoint the rows can show who they were and roughly how much they did. Adding to the counts needs the right to change shared rows, so anyone who can add items to the site's lists can also change or remove a count: the numbers are a guide, not a record. Switching counting off stops new counts at once on that page and on every device at its next page load; counts already in the list stay until a site owner deletes them.
Search-first mode and links into a profile
- Search-first mode. A site owner can turn it on when people are hidden from the address list or information barriers are used. DirectoryPoint then lists nobody in bulk and finds people only through Microsoft 365 people search, which Microsoft documents leaves out people hidden from the address list or by information barriers; a profile opened by link is shown only when that search also finds the person. It needs the People.Read permission.
- Links into a profile. A Viva Connections card's person row, and a link another app builds, open the DirectoryPoint page with the person's Microsoft Entra object ID in the page address (never a search word), so it can appear in the browser's history and in SharePoint's own logs of page visits. A card opens only a page on the same SharePoint host as the DirectoryPoint site. The page then shows the profile only to someone the directory would show it to, and says nothing about anyone else.
Exports and imports
A site owner can save the listed directory as an Excel or CSV file. The file is built in the browser and saved on their computer; nothing is uploaded anywhere. Columns hidden for everyone are not offered, a field a person hides is left empty on their row, mobile numbers appear only for people who chose to show them, and birthdays, anniversaries, favourites and skills are never exported. External contacts are never in this export.
A site owner can also save the external contacts as their own CSV file (every column, notes included), and copy the summary of approved corrections for IT (the person's name, sign-in name and object ID, each field with its old and new value, and where to make the change). An external contacts CSV a site owner imports is read in the browser (at most 2 MB and 2,000 rows at once) and each row is checked before it is added. Each export is recorded in DirectoryPoint Audit, and cells a spreadsheet would run as a formula are prefixed with an apostrophe.
What leaves your tenant
- The licence check-in. At most once a day from each browser, DirectoryPoint sends the Apps 365 Licence Manager (licences.apps365.pro) your tenant ID, the addresses of the site and its site collection, the app version, the licence state and plan, and the licence ID. It never sends names, profiles, directory data or keys. A site owner can switch it off in Settings, Licence; licence keys keep working without it.
- Links people choose to open. Chat and call buttons open Microsoft Teams; Open agent opens the agent's stored link; help links open this website.
- Usage counts stay in your tenant. The daily counts go only to the DirectoryPoint Usage list on your site; the licence check-in carries none of them.
Withdrawing and deleting
- A person withdraws a birthday or anniversary, removes other names, clears About you or deletes a name recording in Settings at any time, even when DirectoryPoint is read-only. Deleted recordings go to the site recycle bin.
- A person removes or declines a kudos, or turns kudos off (their keys go to the site recycle bin); a sender withdraws a kudos they sent.
- Stopping sharing a collection, or taking a colleague off it, sends the copies to the site recycle bin at once. "Leave the scoreboard" sends the player's Who's Who row there at once.
- Removed who-is-listed rules, external contacts and snapshot files go to the site recycle bin. A published snapshot shows the details as they were when it was published until a site owner refreshes or removes it.
- Change requests and audit rows are not deleted by DirectoryPoint: a site owner deletes them like any SharePoint list item, under your organisation's retention rules.
- Removing DirectoryPoint from the site leaves the lists in place, so nothing is lost by accident; a site owner deletes them like any SharePoint list.
Licence keys
Licence keys are signed by Apps 365 and checked in the browser against the public key built into DirectoryPoint, so checking a key needs no call to us. Keys saved for every site go into a hidden list (Apps365LicenceKeys) on your tenant app catalog, which everyone in your organisation can read and only its administrators can change; otherwise a key is saved in the site's DirectoryPoint Settings. Keys are never shown on the page after they are saved. Without a key, after the 14-day evaluation, DirectoryPoint becomes read-only; nothing is deleted.
This website
- No cookies, no analytics, no advertising and no tracking. Nothing is loaded from other websites: every page has a strict Content Security Policy.
- No forms: this site collects nothing you type. To contact us you use your own email.
- Our web server keeps short access logs (the page, the time, the result) for 30 days to run the site and find faults. Our application logs do not record your internet address; our hosting provider's standard server logs may, for a short time.
- Hosted by our hosting provider in the United Kingdom, over HTTPS only.
Reporting a security issue
Email info@apps365ltd.com or see security.txt. Please give enough detail for us to reproduce the issue, and do not access other people's data while testing. We aim to reply within one working day.