Dockli requests only the Microsoft Graph permissions it needs, and every one of them is delegated — Dockli acts as the signed-in user, never as an application in its own right. This page lists the exact scopes, groups them into what is requested at sign-in versus on first use, and explains what each one does.
The delegated (act-as-user) model
A Graph permission can be granted two ways: application (the app gets standing access to the whole tenant, independent of any user) or delegated (the app acts on behalf of a signed-in user, bounded by that user’s own rights). Dockli uses delegated permissions exclusively.
That single design choice produces the strongest access guarantee in the product:
- Dockli can only ever see and act on what the signed-in user could already see and act on in Microsoft 365.
- It never widens a user’s permissions. If a user can’t open a file in SharePoint, Dockli can’t either.
- There is no app-only identity with standing access to your tenant’s content. Consent removes the per-user prompt; it does not hand Dockli a key to your data.
Primary scopes (requested at sign-in)
These delegated scopes make up Dockli’s base request. They cover navigating the file estate, reading and writing files the user already has rights to, and the dashboard cards.
| Scope | What it’s for |
|---|---|
Sites.Read.All | Discover and browse SharePoint sites, Hub Sites, and document libraries the user can access. |
Files.ReadWrite.All | Read and modify files the user has rights to — upload, rename, move, copy, delete, edit metadata. |
Files.Read.All | Read files across the tenant the user can access — powers the Recent Files view and cross-site browsing. |
User.Read | Read the signed-in user’s own basic profile (name, email, photo, company). |
Team.ReadBasic.All | List the teams the user belongs to, so their Teams-backed SharePoint sites appear in the tree. |
Calendars.Read | Read the user’s calendar for the “Today’s Schedule” dashboard card. |
Mail.Read | Read flagged messages for the dashboard’s priority items. |
Tasks.Read | Read the user’s Microsoft To Do tasks for the priority-tasks card. |
Why the '.All' suffix isn't tenant-wide access
Scopes like Files.Read.All and Sites.Read.All read all the sites and files the signed-in user has permission to — not everything in the tenant. Because the permission is delegated, “All” is still bounded by that user’s own access. It is what lets Dockli show a user their full estate in one tree without a separate grant per site.
Incremental scopes (requested only when a feature is first used)
Higher-impact capabilities are not in the base request. Dockli asks for them incrementally — a one-time consent the first time the user actually invokes that feature. This keeps the default footprint minimal and means a user who never touches, say, Teams messaging is never asked to consent to Teams scopes.
| Scope(s) | Requested when | Used for |
|---|---|---|
Mail.Send | First time Ask Dockli sends an email | Sending a composed message as the user via /me/sendMail. |
People.Read, User.ReadBasic.All | First time a person is looked up | Resolving a name to an email address and fetching a profile photo for people pickers. |
Chat.Create, ChatMessage.Send, ChannelMessage.Send, Channel.ReadBasic.All | First time a message is sent or a file shared via Teams | Creating a 1:1 or group chat, posting to a chat or a channel, and listing the user’s teams/channels. Bundled with the People scopes so one consent lights up the whole Teams composer. |
Per-host AllSites.Write (e.g. https://contoso.sharepoint.com/AllSites.Write) | First time the recycle bin or a permission check is used on a given SharePoint host | Viewing and restoring items in the SharePoint recycle bin and checking permissions — via the SharePoint REST API, which Microsoft Graph does not expose. Scoped to that one host, and to the least-privilege AllSites.Write (not FullControl / Manage). |
Least privilege in the details
Even the incremental scopes are chosen conservatively. The SharePoint recycle-bin token requests AllSites.Write — enough to view and restore — rather than a full-control or app-only grant, and its audience is a single SharePoint host, not every site collection you own.
How consent happens
For an organization, all of these permissions can be approved once, tenant-wide, by a Global Administrator, so individual users never see a consent prompt of their own. The incremental scopes above are included in that admin-consent grant, so the first-use experience for the user is seamless.
See Tenant-wide admin consent for the exact approval flow and who can grant it.
Consent is not access
Granting admin consent does not give Dockli standing access to your files. It only removes the per-user approval prompt. Dockli still acts solely as each signed-in user, using that user’s own Microsoft 365 permissions — nothing more.
Related reading
- How tokens for these scopes are acquired and stored → Authentication and tokens
- The one-time tenant approval → Tenant-wide admin consent
- Where data goes once a scope is used → Data handling and residency