n8n SharePoint Trigger Node Tutorial: Start Workflows When Files Change

Introduction

SharePoint is where most Microsoft 365 teams keep the files that matter: contracts, invoices, policies, and project documents. Until recently, reacting to a new file meant a scheduled workflow that listed the whole library and compared it with the last run, or a Power Automate flow outside n8n. The Microsoft SharePoint Trigger node, added in n8n 2.44.0, removes that workaround. It watches one document library or one list and starts your workflow when something changes. This tutorial sets it up end to end, using a contract library as the example: a new or changed file triggers a workflow that reads the file and posts a summary to the team.

Quick answer

Add the Microsoft SharePoint Trigger node, connect Microsoft OAuth2 or an Entra service principal, pick a site and one library or list, choose your events, set Poll Times, and activate the workflow. Changes arrive on the next poll.

Evidence

The scale explains why this node matters. Microsoft announced in December 2020 that SharePoint had passed 200 million monthly active users in the cloud, after doubling in about a year, and SharePoint remains the document store inside most Microsoft 365 tenants. On the n8n side, the project passed 209,000 GitHub stars as of November 2026. A trigger node for SharePoint was the missing piece between those two facts.

The node itself is new and narrowly scoped. The n8n 2.44.0 release notes list one line for it: “Microsoft SharePoint Trigger Node: Add the Microsoft SharePoint Trigger node (#40055)”. The Microsoft SharePoint Trigger documentation then defines the contract precisely: “The node watches one document library or one list on one site. It checks for changes on a schedule you set. Each check starts the workflow at most once.” One check reads about 40 pages of changes at default settings, and the node saves its position and carries on at the next check if more changes are waiting, so a large burst arrives over several executions rather than one.

The most important design decision in the docs is the credential advice. The docs say, “Triggers keep checking when nobody is signed in, so use the Service Principal credential in production. A user credential stops working when that user’s session is revoked.” That sentence decides the setup below: test with a personal OAuth2 sign-in, then switch to an Entra service principal before going live.

Prerequisites

• n8n 2.44.0 or later, Cloud or self-hosted. If you run an older self-hosted version, upgrade first. Our guide to installing n8n on an Ubuntu VPS covers the Docker setup this tutorial assumes.
• A Microsoft 365 tenant with a SharePoint site you can read, plus a document library or list on it. The worked example uses a library called Contracts.
• Either a Microsoft account that can read the site (testing) or an Entra app registration with admin consent (production). The older Microsoft SharePoint credential is not supported: its tokens target the SharePoint REST API, not Microsoft Graph.
• About 20 minutes, including the Entra app registration.

Step 1: Create the credential

Add the trigger node first, then create its credential from inside the node, so n8n offers the right types. In a new workflow, add the Microsoft SharePoint Trigger node from the node picker and open its Credential to connect with dropdown.

For a quick test, choose Microsoft OAuth2, sign in with your Microsoft account, and set the Scope field to exactly this string:

openid offline_access Sites.Read.All

The openid offline_access part lets n8n refresh tokens without another sign-in, and Sites.Read.All grants read access to SharePoint sites. If sign-in asks for consent your account cannot grant, an admin must approve it.

For production, create a Microsoft Entra Service Principal credential instead. The app registration needs the Sites.Read.All application permission with admin consent, and a client secret or certificate. The Azure CLI provisioning guide for a SharePoint app registration gives copy-paste commands including the permission manifest, which is the fastest reliable route. If your organization grants access site by site, grant Sites.Selected instead and have an administrator grant the app access to each site. Government cloud tenants should select the matching Microsoft Graph API base URL in the credential settings.

Step 2: Pick the site, resource, and events

With the credential connected:

1. Site: pick your site, or switch to By URL mode and paste the address, for example https://contoso.sharepoint.com/sites/legal. Use By URL when your organization grants access site by site, because site search needs a tenant-wide read permission.
2. Resource: choose Document Library to watch files, or List to watch list items. The worked example uses Document Library.
3. Document Library: pick the Contracts library.
4. Events: leave both Changed and Deleted on. Changed covers a file being added, edited, renamed, or moved, and metadata changes. Deleted covers a file being deleted. There is no separate Created event, because Microsoft Graph’s change feed reports the latest state of each item, not each change, so an added file and an edited file both arrive as Changed. To tell them apart, compare createdDateTime with lastModifiedDateTime in an IF node and treat the result as a hint, since an item created and then edited between two checks arrives once with different timestamps. Folders produce no events on either resource.

Note the scope: the node watches the whole library, and you cannot narrow it to one folder. Microsoft Graph’s change feed cannot be filtered on the server, and it does not report the folder path of a changed file. If your Contracts library also holds drafts you do not care about, filter later in the workflow using the webUrl field. Do not rely on parentReference.path, which the docs warn is unreliable in these entries.

Step 3: Set how often the node checks

Poll Times sets how often the node checks, and it defaults to every minute. A custom cron expression can go finer, down to seconds, but Microsoft throttles requests well before that frequency is useful, so leave it at one minute unless you have a measured reason to change it.

Understand the timing this gives you. A change is picked up on the next check, so the workflow runs within about a minute of the change in the normal case. When many files change at once, the node reads about 40 pages of changes per check, saves its position, and continues at the next check, so a large burst arrives over multiple executions. If your workflow sends a message per file, a 200-file upload becomes 200 messages spread over several minutes. Design for that, or add a step that batches items before notifying anyone.

Step 4: Read the full item with the SharePoint node

The trigger output is the raw Microsoft Graph entry, with no reshaping, and for list items it does not expand the item’s fields, so a trigger entry does not carry column values. To read a column, or to download a file, add a Microsoft SharePoint node after the trigger. The Microsoft SharePoint node documentation lists the operations, and the two you need most often are Item: Get, with the item ID mapped from the trigger output ({{ $json.id }}), to read list columns, and File: Download, to fetch the contents of a changed file.

The SharePoint node is version 2 from n8n 2.37.0 and uses the same Microsoft Graph API the trigger reads. It signs in with the same two credential types, and for full read and write access its scope is openid offline_access Sites.ReadWrite.All. Two limits from its docs: uploads over 250 MB fail, because file contents go in a single request, and filtering a list with more than 5,000 items only works on indexed columns.

For the worked example, the flow is now: trigger on the Contracts library, then a SharePoint node that downloads the changed file, then a notification step that posts the file name and link to the team channel. Keep the notification as a separate node so you can swap channels without touching the trigger.

Step 5: Test, then activate

Testing a polling trigger differs from testing a webhook. Testing the node in the editor does not move the saved position, so a test never consumes real events. A test lists items that already exist in the library or list, up to one page of them. It does not wait for a change, and it never shows a deletion. Use the test to see the shape of an entry, not to check your event selection.

To test for real:

1. Click Execute step on the trigger node once and confirm the output shows existing library items with the fields your later steps use, especially id, name, and webUrl.
2. Save the workflow, then click Active to activate it. The node starts watching from that moment. Files that already exist raise no event.
3. Upload a test file to the Contracts library, wait for the next poll, and check the Executions list. You should see one execution carrying the new file as a Changed entry.
4. Edit the same file and delete a test file, and confirm both arrive as expected. A deletion entry carries much less than a change entry, because Microsoft Graph drops most fields from it. Expect the item’s id and the deleted property, and do not rely on anything else being present. If your workflow needs a deleted item’s name, keep your own record of the items you have seen, keyed by id.

Troubleshooting

The workflow never fires after activation

First check the version. The node does not exist before n8n 2.44.0, so an older instance shows no Microsoft SharePoint Trigger in the picker at all. Next, confirm the workflow is actually Active, not just saved, because a polling trigger only checks while the workflow is active. Finally, remember that existing files do not trigger anything. Upload a genuinely new file after activation and wait one full poll interval before concluding it is broken.

The trigger reports a permission error

The node reports Microsoft Graph errors as they come back, and a permission error does not name the library or list. Check the credential’s scopes and the signed-in account’s access to the site. For the OAuth2 credential, the scope must include Sites.Read.All. For a service principal, the app registration needs Sites.Read.All with admin consent, and with per-site access the app must also have been granted access to that specific site. A passing credential test does not prove the permissions are right: from n8n 2.40.0, the connection test only checks that the app registration can sign in, not which permissions it holds.

Changes are missing after I edited the trigger

Changing the Authentication method, Site, Resource, Document Library, or List resets the saved position. The node starts watching from that moment and does not report earlier changes. Choosing a different credential of the same type keeps the position. If you must change the watched library, accept the gap or backfill it with a one-off SharePoint node run listing recent items.

The same file arrives more than once

Within one check, the node combines repeated changes to the same item. Across checks, the same item can arrive more than once while a large burst of changes is being processed. Design your workflow so repeats for the same item are harmless: check whether the file was already processed, keyed by item ID, before sending a notification or writing to another system. Polling triggers have this property generally. Our fix for the n8n Gmail trigger timing out covers a related polling trigger failure mode.

The test shows items, but not my change

This is expected behavior, not a bug. A test lists existing items, never shows a deletion, and does not move the saved position. Activate the workflow and make a real change. If the library or list cannot be found, the node reports an error naming it and the site, and keeps its saved position so it resumes if the target comes back. A rename does not break the node, because it watches by ID, unless you entered a list title in By ID or Title mode.

FAQ

Which n8n version do I need for the SharePoint Trigger node?

n8n 2.44.0 or later. The node shipped in 2.44.0, released 13 October 2026, and later 2.x and 3.x releases include it. If your instance is older, upgrade first.

Does the trigger fire for files that are already in the library?

No. The node starts watching from the moment you activate the workflow, and files or items that already exist raise no event. To process a library’s existing contents, use the Microsoft SharePoint node to list and download them instead.

Can the trigger watch a single folder inside a document library?

No. The node watches the whole library or the whole list, and you cannot narrow it to one folder. Microsoft Graph’s change feed cannot be filtered on the server, and it does not report the folder path of a changed file, so there is nothing reliable to filter on. Filter by file path in a later step of your workflow instead.

What permissions does the trigger need in Microsoft 365?

For a user sign-in, the Microsoft OAuth2 credential needs the scope openid offline_access Sites.Read.All. For an app sign-in, the Entra service principal needs the Sites.Read.All application permission with admin consent. If your organization grants access site by site, use Sites.Selected instead and have an admin grant the app access to each site.

Conclusion

The SharePoint Trigger node is a small, honest addition: one library or one list, two events, a poll every minute, and raw Graph entries as output. Its limits are the interesting part. It cannot watch one folder, it cannot tell you a file is new, it starts watching only when you activate the workflow, and its output for deletions is nearly empty. Build with those limits in mind, use a service principal in production, and keep a record of item IDs if deletions matter to you. The result is SharePoint automation that lives in n8n alongside everything else, not in a separate Power Automate flow. For more Microsoft 365 automation in n8n, read our n8n Dataverse node tutorial next, and keep the complete n8n guide open as the platform reference.

Frequently asked questions