TABLE OF CONTENTS

• Before you start
• 1. Work out which site you are granting
• 2. Find the site ID
• 3. Make the grant
• 4. Give the person access in SharePoint (Desktop Client only)
• 5. Check it worked
• What to paste into the product
• Also worth knowing

Introduction

From release 2.16.0.0, a SharePoint address can point at a document library, or a folder inside one, rather than only at the site. Giving just the site still works exactly as before.

Access is granted per site collection, using the Sites.Selected permission. One grant covers every library and folder inside that site, so you do not repeat it per folder — but a library on a different site needs its own grant.

These steps assume the app registration already exists and already has the Sites.Selected permission with admin consent.

Each step in the process will get its own section below:

Before you start

• The account doing this needs Sites.FullControl.All on Microsoft Graph, with admin consent. That is the permission that lets you hand out site access, and it is not the same as the Sites.Selected permission the application holds.
• It also needs SharePoint Administrator or higher. Holding the scope alone is not enough — every check will pass and the final grant will still return 403.
• Click the profile avatar (top right) and choose Consent to permissions. That screen lists every available permission. Search for Sites.FullControl.All and consent to it, ticking Consent on behalf of your organization in the prompt.
• Have these to hand:
  • {sharepoint-hostname} — your SharePoint host, e.g. contoso.sharepoint.com
  • {client-id} — the Application (client) ID of the registration, from Entra ID → App registrations → your app → Overview. Not the Object ID, and not the enterprise application's object ID.
  • {app-display-name} — that same app's Display name
  • {tenant-id} — from Entra ID → Overview → Properties, or your domain name
  • If you need a raw token for curl or Postman, the Access token tab shows the current one. Copy it into {access-token}. It usually lasts 60–90 minutes, after which you copy a fresh one.

1. Work out which site you are granting

You will usually be handed the address of the library or folder the files are going into, not the site — because that is the address that goes into SchedEx. Permission, though, is granted on the site. So trim it back first.

This step gives you {sharepoint-hostname} and {site-name}, both used in step 2.

The rule: keep the host plus /sites/<name> or /teams/<name>, and drop everything after it. If there is no /sites/ or /teams/ part at all, the site is the host on its own.

Keep the original address. You grant the trimmed site, but into SchedEx you paste the full folder address you started with. Those being different is the point — one grant covers everything inside the site, while the address you configure names the exact folder.

A root-site address is a broader grant than it looks. With no /sites/ or /teams/ part, the site is the tenant root — usually the organisation's intranet home page — and the grant covers every document library on it, with no way to narrow it to one. It does not reach any other site: anything under /sites/ or /teams/ is separate and stays untouched. This is supported and normal, so carry on if that is genuinely where the library lives.

One grant covers everything inside the site, at any depth, so you do not repeat this per library or per folder. Two exceptions:

• Microsoft Teams. A standard channel is just a folder in the team's own site, so the team's grant covers it. A private or shared channel is its own separate site and needs its own grant.
• Subsites. Do not grant them — access exists only at site level. Grant the site above and the subsite is covered.

2. Find the site ID

The site ID is not the site URL. In Graph Explorer, with GET selected:

GET https://graph.microsoft.com/v1.0/sites/{sharepoint-hostname}:/sites/{site-name}

For https://contoso.sharepoint.com/sites/ProjectDocs that is:

GET https://graph.microsoft.com/v1.0/sites/contoso.sharepoint.com:/sites/ProjectDocs

The response carries an id like contoso.sharepoint.com,9e7f0a1b-…,4dc44a2e-…. Copy it whole, commas included — that is your {site-id}. Check the webUrl in the response is the site you meant.

For a /teams/ site, put /teams/ after the colon instead. For the tenant root site the call above does not work — there is no name to put after the colon, so ask for it by name:

GET https://graph.microsoft.com/v1.0/sites/root

3. Make the grant

write is the right role — it covers creating folders and writing files, and nothing more.

POST https://graph.microsoft.com/v1.0/sites/{site-id}/permissions Content-Type: application/json 
{  "roles": ["write"],  "grantedToIdentities": [    {      "application": {        "id": "{client-id}",        "displayName": "{app-display-name}"      }    }  ] }

A 201 comes back carrying the grant's own id. Keep it — it is the only way to change the role or revoke access later. Check the displayName in the response is the application's real name: leaving the placeholder unreplaced does not fail, it just creates a grant nobody can identify afterwards.

4. Give the person access in SharePoint (Desktop Client only)

Skip this if you only use the Autonomous Client — it signs in as the application itself, so no person is involved.

The Desktop Client works on behalf of the person signed in and can never do more than they could by hand. Open the site in a browser, click the Settings gear, and choose Site permissions:

• A team site (one with a Microsoft 365 group behind it) shows an Add members button. Click it, choose Share site only, enter the person's name, set the level to Edit, and select Add.
• A communication site shows Share site instead, with no menu. Enter the name, set Edit, select Add.

If your tenant has older labels, the button reads Invite people; it is the same button. The level dropdown offers only Read, Edit and Full control — choose Edit. Read lets them open files but not add any, so transfers fail.

Two cases where that is not enough:

• A Teams private or shared channel. SharePoint shows those permissions read-only. Add the person in Teams: channel name → More options (...) → Manage channel → Members. For a private channel they must already be in the parent team.
• A library with its own separate permission list. Open the library → Settings gear → Library settings → you may need More library settings → under Permissions and Management, Permissions for this document library → Grant Permissions.

How to check: ask the person to upload any file to the folder by hand in a browser. If they cannot, the Desktop Client cannot either, whatever was granted above.

5. Check it worked

List what the site now grants and confirm the application is there:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/permissions

Then confirm the application can see the site's libraries by name — this is a separate check and can fail while the one above passes:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drives

If that comes back empty or 403 and stays that way, the application cannot find a library by name, so an address naming one will not reach it. Fix the grant rather than changing the address in the product.

The simplest end-to-end test is to run a transfer against the site and confirm it completes without a permission error.

A new grant does not always take effect at once. If a check fails within a few minutes of granting, wait and retry — re-granting does not speed it up and leaves duplicate grants to clean up. First confirm the client is not still holding a sign-in from before the grant; that is the more common cause.

What to paste into the product

Open the library or folder in SharePoint and copy the address out of the browser's address bar. A copied address is much longer than the folder path — that is expected, and SchedEx trims it when it saves.

Do not use Share → Copy link. Those links carry a permission token rather than a path, so there is nothing in them that says where the folder is.

If the files live in a Teams channel, open the channel → Shared tab → More commands (...) → Open in SharePoint, then copy from the address bar.

Addresses that work

Addresses that are refused

Also worth knowing

• The folder must already exist. SchedEx creates its own sub-folders inside what you point at, but will not create the folder you named.
• Capitalisation does not matter. SharePoint treats Invoices and INVOICES as the same folder, though it keeps showing whichever casing the folder was created with.
• If the address ends in something that looks like a file name, you are asked whether it is a file or a folder before saving. Anything with a dot in the last part is asked about, so a folder genuinely called Rev.2 is questioned too.
• Nothing is checked when you save. A convincing typo saves without complaint and only shows up when a transfer runs, or when you press Test on the connector. In particular, an address naming a site you have not granted saves cleanly and then fails at transfer time.