Home Security
Permissions and data
Security and permissions
What OnboardPoint asks for, where your onboarding records are kept, what leaves your tenant and why. Your onboarding records stay in your Microsoft 365 tenant; the licence check-in and the pre-start portal's transit are described below.
Where your data is
Every OnboardPoint record is a SharePoint list item or file on the site where you set it up, in your own Microsoft 365 tenant. Apps 365 Ltd does not keep a copy. People are linked by a random key, never by person or lookup columns.
Privacy comes from SharePoint permissions that set-up applies: role groups for HR, staff, restricted readers and starters; private lists that only named roles can open; one folder per journey with its own permissions; and restricted answers (such as right to work, emergency contact and bank details) in a separate restricted list. Hiding a column is not a security boundary: anyone who can read a list can read every column of the rows they can see. Site owners and SharePoint administrators can read everything on the site.
Permissions by tier
| Tier | Permission | Type | What it adds |
|---|---|---|---|
| Basic | None | The signed-in person's own SharePoint access | Everything in the core: journeys, templates, tasks, forms, acknowledgements, evidence, the UK pack, agents |
| Notify | User.Read.All | Delegated, optional | People pickers with job titles, the manager chain, "Meet your team" (read only) |
| Notify | Mail.Send | Delegated, optional | One daily digest per task owner, sent as the signed-in HR coordinator. It sends only and never reads a mailbox. |
| Connected (coming soon) | Lists.SelectedOperations.Selected | Application, for the OnboardPoint Portal Service app, granted list by list | The pre-start portal, on a dedicated portal site only |
The core package requests no Microsoft Graph permission that writes to your directory or tenant data. Requesting is not granting: an administrator approves each one, and OnboardPoint detects at run time what is granted instead of assuming it.
Licence keys and the daily check-in
Licence keys are signed and checked inside your tenant, with no call to us. Separately, at most once a day from each browser, OnboardPoint sends Apps 365 your tenant ID, the addresses of the OnboardPoint site and its site collection, the app version, the licence state and plan, and the licence ID, so we can support your licence. It never sends names, onboarding records or keys. A site owner can switch the check-in off in Settings.
The pre-start portal (Connected, coming soon)
The portal lets a new starter with no Microsoft 365 account fill in forms, upload documents and acknowledge policies from a private link. It is served by onboardpoint.com, so starter answers pass through our server on their way to your tenant. This is how it is built:
- One app, five lists. The multi-tenant app "OnboardPoint Portal Service" has one application permission, Lists.SelectedOperations.Selected, which gives no access to anything until lists are granted to it one by one. It is granted read on the portal's Settings list and Documents library, and write on its Invites and Submissions lists and its Drop-off library. It has no site-wide, directory or mail permission, and no grant on your OnboardPoint site. It signs in with a certificate, never a password.
- A dedicated portal site. An app with list grants can still read the name of the site and the names of its lists, so the five portal lists live on a small communication site of their own that holds nothing else.
- Single-use links. Each link carries 256 random bits, made in HR's browser. Only its SHA-256 hash is stored in your Invites list; the link itself is shown to HR once and never stored. A link belongs to one journey, expires (seven days by default) and works once: it is exchanged for a session and moves out of the address bar. A used, altered, expired or revoked link gets the same calm page, after the same time.
- Sessions. A random session ID in an HttpOnly, HTTPS-only, SameSite=Strict cookie that is sent only to the portal's own pages. It ends after 30 minutes idle or 120 minutes in all, at finish, when HR revokes the invite, or when a kill switch is on. On the server the session holds only the connection code, the invite's item number, the journey key and the link's hash.
- Transit only. Answers and acknowledgements are written to your Submissions list in the same request and are not kept on our server: no database, files or queues hold them. Uploaded files go from the starter's device straight to your Drop-off library through a Microsoft upload session; the service then checks the size and the file's first bytes against its type and sets aside any file that does not match.
- Kill switches. The portal runs only while the kill-switch row in your portal's Settings list says off. It is read before every request that touches your tenant, kept for at most 30 seconds, so switching it on stops reads and writes within a minute. A switch on our server stops every tenant at once. The portal never deletes anything in your tenant.
- Outbound calls. The service calls only graph.microsoft.com, login.microsoftonline.com and your tenant's own SharePoint host, honours Microsoft's Retry-After and identifies itself as OnboardPoint Portal.
- Logs. Kept for 30 days: the method, the address without its query and with the link replaced by [token], the status, the time taken and your SharePoint host. Never request bodies, links, hashes, names or answers.
For the portal, Apps 365 Ltd is a processor of starter personal data in transit. A data processing agreement, the hosting location statement and an independent review come before the portal goes live.
This website
onboardpoint.com loads no third-party scripts, fonts or trackers and sets no cookies on its public pages. Every page has a strict Content Security Policy, HTTPS with HSTS, and no framing.
Reporting a security problem
Email info@apps365ltd.com, or see security.txt. Please do not test against other customers' data.