Connect Multi FileFeeds to Microsoft 365 (SharePoint / OneDrive)

Availability: Multi FileFeeds with the WorkflowsAzureSharepointSource and/or WorkflowsAzureSharepointDestination features enabled.

This guide walks through four things:

1. The one-time tenant setup that a Microsoft 365 admin in your organization runs once: granting admin consent for the OneSchema FileFeeds Connection app and allowlisting the specific SharePoint sites OneSchema may read from or write to.
2. Connecting your Microsoft 365 account in OneSchema (an OAuth click-through that produces a per-user delegated token).
3. Using that connection as a source on a Multi FileFeed, so OneSchema polls a SharePoint folder or OneDrive folder on a schedule and ingests new files.
4. Using that connection as a destination on a Multi FileFeed, so OneSchema writes processed output files into a drive folder.

A single Microsoft 365 connection can back both directions — you do not need separate connections for source and destination usage.

Terminology

How it works

OneSchema's Microsoft 365 integration uses delegated OAuth with the Sites.Selected scope. In plain language, that means two things:

• Per-user token. When a user in your organization clicks Connect in OneSchema, they sign in to Microsoft and grant the OneSchema FileFeeds Connection app a refresh token. OneSchema stores that token and uses it to call Microsoft Graph on the user's behalf. The user can revoke the token at any time by disconnecting in OneSchema or removing the app from their Microsoft account.
• Admin allowlist per site. Sites.Selected means the app has no SharePoint access by default — not even sites the user can otherwise read. A tenant admin must explicitly grant the app read (and optionally write) access on each SharePoint site OneSchema should see. This is run-once-per-site, not run-once-per-user.

sequenceDiagram
    participant Admin as Tenant admin (one-time)
    participant Graph as Microsoft Graph
    participant Site as SharePoint site
    participant User as End user
    participant OS as OneSchema

    Note over Admin,Site: One-time per tenant
    Admin->>Graph: Admin consent for OneSchema FileFeeds Connection app<br/>(scopes: Sites.Selected, offline_access)
    Admin->>Graph: POST /sites/{site-id}/permissions<br/>(grant app read [+write])
    Graph->>Site: App is now allowlisted on this site

    Note over User,OS: Per user
    User->>OS: Click "Connect" → redirected to Microsoft
    User->>Graph: Sign in + accept consent prompt
    Graph-->>OS: Authorization code → access + refresh tokens
    OS->>OS: Store delegated token<br/>(per-user credential)

    Note over OS,Site: Per MFF run
    OS->>Graph: GET /sites/{id}/drives, /items, downloadable content<br/>(bearer = user's token)
    Graph-->>OS: Folder listing / file bytes
    OS->>OS: Ingest into MFF import

A few things follow from this design:

• No long-lived secrets on either side. OneSchema never sees your tenant's app secrets; you never copy a service-principal credential to OneSchema. The app's client ID and secret live with OneSchema centrally; tokens are issued per user via OAuth and rotated automatically via refresh tokens.
• Per-site auditability. Because Sites.Selected requires an explicit per-site grant, your security team can answer "which SharePoint sites can OneSchema read?" by listing the app's site grants in Microsoft Graph — there's nothing implicit.
• One Entra app for all customers. OneSchema FileFeeds Connection is a multi-tenant Entra app registered in OneSchema's tenant. Customers consent to it; they don't register their own. This is the standard Microsoft 365 SaaS integration pattern.

Prerequisites

You will need:

Step 1 — One-time tenant setup (Microsoft 365 admin)

This step is run once per tenant, by an Entra ID admin. After it's done, any user in your organization can connect their account in OneSchema without re-running it.

Step 1a — Grant admin consent for the OneSchema app

In the Azure Portal:

Entra ID → Enterprise applications
  → search "OneSchema FileFeeds Connection"
  → Permissions
  → Grant admin consent for <your tenant>

If the app doesn't appear in Enterprise applications, have a user in your tenant click Connect in OneSchema once — that triggers Microsoft to provision the service-principal entry. Cancel out of the consent screen if needed; you only need the entry to appear. Then re-run the consent step as the admin.

The scopes being consented:

Sites.Selected alone gives OneSchema access to zero sites. That's intentional; step 1b is what actually grants per-site access.

Step 1b — Allowlist each site OneSchema should access

For each SharePoint site you want OneSchema to read from or write to, the tenant admin runs two Microsoft Graph calls.

The OneSchema picker also embeds these calls inline (with your tenant and OneSchema's app client ID pre-filled) — click Need to allowlist a site for OneSchema? (admin-only setup) in the SharePoint target form to copy them straight from the UI. Below is the same flow in long form.

Find the site ID:

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

Substitute {tenant} with your tenant's SharePoint prefix (e.g. oneschemainc in oneschemainc.sharepoint.com) and {site-path} with the site's URL slug (e.g. engineering in /sites/engineering). The response includes an id field — that's the site ID OneSchema needs.

Grant the app access:

POST https://graph.microsoft.com/v1.0/sites/{SITE_ID}/permissions
Content-Type: application/json

{
  "roles": ["read"],
  "grantedToIdentitiesV2": [
    {
      "application": {
        "id": "<ONESCHEMA_APP_CLIENT_ID>",
        "displayName": "OneSchema FileFeeds Connection"
      }
    }
  ]
}

Replace <ONESCHEMA_APP_CLIENT_ID> with the client ID shown in the OneSchema picker. For a destination — where OneSchema writes back to the site — use "roles": ["read", "write"] instead.

You can run both calls from Microsoft's Graph Explorer, from PowerShell with the Microsoft.Graph module, or from any tool that handles Entra ID auth. The admin running them needs an Entra role with permission to manage site permissions (Global Administrator covers it; SharePoint Administrator alone does not — site-permission grants require Microsoft Graph permissions that aren't automatic for SharePoint Admins).

Repeat per site. OneDrive for Business drives don't require this step — they're per-user, and a user's delegated token already covers their own OneDrive without site-level allowlisting.

Step 2 — Connect a Microsoft 365 account in OneSchema

This step is run per user, by anyone in your organization who will configure a SharePoint source or destination.

In OneSchema, edit a Multi FileFeed and open the Source (or Destination) section. Choose Microsoft 365 (SharePoint / OneDrive) as the type. If no account is connected yet, you'll see a Connect Microsoft 365 button.

Click it. You'll be redirected to Microsoft's login page. Sign in with the account you want OneSchema to use, accept the consent prompt, and you'll land back in OneSchema with the picker now showing your drive contents.

A few notes on which account to use:

• The account's permissions matter. OneSchema can only see sites the user can see (filtered by the admin allowlist from step 1b). If you connect with a user who lacks access to the "Finance" site, the picker won't show it — even if the app is allowlisted on that site.
• The connected user owns the access. If that user leaves the organization, the connection breaks until someone else connects with another account. For long-lived workflows, consider connecting with a service account or a shared mailbox that won't depend on one employee.
• Re-using one connection across users. A connection is currently per-user. Multiple users in your organization can each connect their own account; each MFF then points at one of those connections.

Step 3 — Use SharePoint / OneDrive as a source on a Multi FileFeed

A Microsoft 365 source tells OneSchema to poll a SharePoint folder or OneDrive folder on a schedule, find new files matching a filter, and ingest them into Multi FileFeed imports.

In the source form, fill in:

Why you paste a URL instead of searching

OneSchema's app uses the narrow Sites.Selected permission scope (see How it works). Microsoft Graph's /sites?search=… endpoint can't enumerate sites under that scope — it requires the broader Sites.Read.All permission, which would defeat the per-site allowlist model. Paste-by-URL hits /sites/{host}:{path} directly, which does work under Sites.Selected once the admin has allowlisted the specific site.

Deep links work fine: if you paste a document URL like https://your-tenant.sharepoint.com/sites/your-site/Shared Documents/file.xlsx, OneSchema strips everything after the site slug and resolves the parent site.

Behavior to know about

• Polling order. OneSchema lists items by Microsoft Graph's default order — generally most-recently-modified first within each folder. Don't rely on a specific ordering for downstream logic.
• Deduplication is exact. OneSchema tracks every file it has ingested by (drive_id, item_id, ctag) — the ctag (content tag) changes whenever the file's content is edited. Re-saving a file in SharePoint creates a new ctag, which OneSchema treats as a new ingestion.
• Maximum file size: 1 GiB. Files larger than this are skipped, and the source surfaces a failure status on its next run until the offending file is removed or its size brought under the limit.
• Folder navigation does not recurse. OneSchema polls only the specific folder you selected, not subfolders. If your producer drops files into nested subfolders, configure a separate source per subfolder or flatten the layout upstream.
• Manual pulls. A source with no Pull frequency set is only ever polled when you click Pull from sources in the Multi FileFeed canvas.

Step 4 — Use SharePoint / OneDrive as a destination on a Multi FileFeed

A Microsoft 365 destination tells OneSchema to write the processed output files of a Multi FileFeed run into a drive folder. There is no polling and no filter — the destination simply receives whatever the run produces.

The destination picker has the same shape as the source picker (Drive type → Site → Drive → Folder), but with two differences:

• No File filter. Filenames are determined by the Multi FileFeed run (see Default vs. custom output filenames in the Destinations overview).
• No Pull frequency. Destinations run after each successful import, on the import's schedule rather than their own.

Behavior to know about

• Allowlist permission needed: write. When the tenant admin allowlisted the site in step 1b, make sure they used "roles": ["read", "write"] rather than just "read". Read-only allowlists work for sources but block destinations.
• Existing files in the destination folder. If an output file's name collides with an existing item in the folder, OneSchema replaces the existing item using Microsoft Graph's conflictBehavior: replace. Microsoft 365 typically retains the prior version under the site's Version history; OneSchema does not enforce this — it depends on the site's versioning policy.
• Filename safety. OneSchema strips newlines and tabs from output filenames before writing; characters that SharePoint rejects (e.g. <, >, :, ", /, \, |, ?, *) come from your filename pattern and should be sanitized there.
• Large files use upload sessions. Files larger than 4 MiB are uploaded in chunks via Microsoft Graph's upload-session API, with automatic retry on rate-limit (429) responses. You don't configure anything for this; it just works.

Troubleshooting

Limits and behavior