A time-tracking rollout usually lands on your desk as a project. There is a vendor security questionnaire to fill in, an Entra app registration asking for consent to scopes somebody has to actually read, a provisioning connector to stand up, and at the end of it, a new pipe carrying your organisation's working data to a cloud you do not run. All of that for a tool whose job is writing down hours.
It is worth asking why the ceremony exists at all. It exists because the tool lives outside your tenant, so identity has to be bridged in and data has to be piped out. Remove that one architectural decision and most of the project disappears with it.
What zero setup actually means
ProjectPoint's time-entry surface is a browser extension for Edge and Chrome, and its requirements from IT are, precisely: nothing. No Entra app registration. No admin consent. No API permissions to review. It never reads cookies; it rides the user's existing signed-in SharePoint session, the one governed by the conditional-access and MFA policies you already enforce. This is not a marketing rounding of "almost nothing": the claim was verified on a vanilla tenant, with a normal user account holding only list-level permissions, with no admin action taken anywhere.
It can only see what they can already see
The extension writes time entries as rows in a SharePoint list, using the user's own permissions. It has no service account, no elevated identity, and no reach beyond
*.sharepoint.com. If a person cannot edit the list, the extension cannot either. There is no new permission surface to audit, because no new permissions exist. Under Manifest V3 it runs no remotely hosted code, and its browser permission set is short enough to read in one breath: storage, alarms, the side panel, and SharePoint itself.The record stays in the tenant
Because entries are ordinary SharePoint list items in your own site, everything you already do to SharePoint data applies to them automatically. Your retention policies, your backup posture, your eDiscovery scope, your audit trail: all of it covers the timesheet record with no extra configuration, because the record never left. There is no vendor copy to reason about, and nothing to repatriate if the relationship ends. Deleted entries go to the site recycle bin, where a site owner can restore them.
Governed from a list, not a console
Central control, where you want it, comes from a plain SharePoint Settings list on the site rather than a vendor console living in your tenant. A row can be a rule, enforced for every user and shown locked in their preferences, or a starting point that seeds new installs and then leaves people alone. The same list carries your brand colours, so both surfaces render in company colours before first paint. You govern the tool with list permissions you already understand, and there is nothing else installed to govern.
One component of a suite that thinks this way
The extension ships as the time-entry surface of ProjectPoint, and its setup story is the suite's philosophy in miniature: a user pastes the ProjectPoint site address, clicks Connect, and the extension finds the lists ProjectPoint installs by itself. The full ProjectPoint solution is a complete project management suite on SharePoint, the governed project workspace, the registry, the project registers, and time and budget capture, built on as much vanilla Microsoft 365 as possible, precisely so that questions like "where does the data live" and "what did we just consent to" keep having boring answers.
Two honest notes for this audience. Distribution today is a team install, with the store listing in preparation, so deployment is a sideload your desktop team runs rather than a store click. And the extension speaks to
*.sharepoint.com only: vanity SharePoint domains and GCC tenants are out of scope for v1, and we will say so rather than let you discover it.Get in touch, and we will show you the whole setup. It fits in one sentence.
