Skip to main content
Majestic_problemc186
Level 1
September 14, 2026
Question

Edge Delivery SharePoint content source fails in the collect phase: the sharing link no longer exists

  • September 14, 2026
  • 1 reply
  • 15 views

The code side of my Edge Delivery site is working. Code Sync serves my blocks, styles
and 404 page from the repository. No document has ever previewed, because the content
bus cannot read the folder.

Setup

1. Site set up through the tools.aem.live configuration wizard.
2. Content source is a SharePoint team site document library, the journal folder of the
   site's Documents library.
3. The folder is shared with helix@adobe.com at Can edit. Manage Access lists it as an
   external user, and there is a matching entry under Links.
4. The content source URL is set in Site Admin, Edit Sources, and verified by reopening
   the form after saving.

What happens

Loading the preview host returns my own 404 page with this banner:

  (404) Unable to fetch /index.md from onedrive
  (404) The sharing link no longer exists, or you do not have permission to access it.

Running the same preview from Admin Tools, Bulk Operations, over seven paths returns
0/7 in about half a second. The job detail is the useful part:

  "data": { "paths": [ seven paths, all correct ], "phase": "collect" },
  "error": "The sharing link no longer exists, or you do not have permission to access it."

Every path parses correctly. The failure is in the collect phase, at the folder lookup,
before any document is touched.

What I have already ruled out

1. Drive type. A personal OneDrive folder and a SharePoint team site library fail
   identically.
2. Configuration location. fstab.yaml in the repository is not what governs a site set
   up through the wizard. The configuration service holds the correct URL, confirmed by
   two successful config writes in the audit log and by reopening the form.
3. The Sidekick. Removing it from the path entirely by running the preview server side
   through Bulk Operations produces the same result.
4. The URL form. Using a real SharePoint sharing link scoped to helix@adobe.com as the
   content source, taken from Manage Access, gives the same error.

Questions

1. Is this the signature of a guest access restriction at the Microsoft 365 tenant
   level, rather than anything wrong with the project configuration?
2. If so, is admin consent to the AEM Content Integration application the supported fix,
   and what exactly does a tenant administrator need to approve? I would like to give
   ours a precise request rather than a general one.
3. Is there anything else that produces a collect phase failure with this error that I
   have not thought to check?

1 reply

AmitVishwakarma
Community Advisor
AmitVishwakarmaCommunity Advisor
Community Advisor
September 18, 2026

Hi ​@Majestic_problemc186 

Based on the details provided, this is not enough to conclude that the issue is caused by a Microsoft 365 guest-access restriction. The first issue to correct is the SharePoint source URL format.

For a site configured through the AEM Configuration Service, use the canonical SharePoint folder URL, for example: 

https://<tenant>.sharepoint.com/sites/<sharepoint-site>/Shared%20Documents/journal

Do not use a SharePoint sharing-link format such as:

https://<tenant>.sharepoint.com/:f:/r/...
https://<tenant>.sharepoint.com/:u:/s/...
https://<tenant>.sharepoint.com/...?...&e=...

Adobe's documentation specifically notes that copying a SharePoint sharing link adds unnecessary parameters. The source should be the canonical site, document-library, and folder path. After updating the source, open that canonical URL in a browser and confirm that it opens the expected folder view, then save it again in Site Admin.https://www.aem.live/docs/setup-customer-sharepoint

The collect-phase failure is consistent with AEM being unable to resolve or access the configured content root. The error message is generic and can be returned for either an invalid sharing URL or an authentication/permission problem. Since all paths fail before a document is processed, the problem is with the content-source lookup, not with the repository code, Sidekick, or individual documents.

Also, sharing the folder with helix@adobe.com as an external user does not by itself confirm that the AEM Content Integration application has access. These are two different authentication models:

  • Delegated access: A technical user is granted access to the folder and is registered with Edge Delivery Services.
  • Application access: The AEM Content Integration application receives Microsoft Graph application permission and a site-specific SharePoint permission.

For a site created through the Configuration Service, the recommended approach is the application-permission model:

  • Use the canonical SharePoint folder URL.
  • Open the Edge Delivery Services Registration Portal and validate the content source using the challenge file.
  • Connect the AEM Content Integration application.
  • Ask the Microsoft Entra tenant administrator to grant the application the Microsoft Graph Sites.Selected application permission.
  • Ask a SharePoint site administrator to grant that application write permission on the SharePoint site containing the content folder.

Granting Sites.Selected alone is not sufficient. The application must also receive permission on the specific SharePoint site. The runtime application should not be given broad tenant-wide permissions such as Files.ReadWrite.All or Sites.ReadWrite.All when the supported site-scoped model is being used. https://www.aem.live/docs/setup-customer-sharepoint

A precise request to the tenant and SharePoint administrators would be:

Please verify that the Edge Delivery Services content source uses the canonical SharePoint folder URL rather than a sharing-link URL. For application-based access, please provision the AEM Content Integration enterprise application, grant Microsoft Graph Sites.Selected application permission, and grant the application write permission on the specific SharePoint site containing the content root folder. Please do not grant broad tenant-wide file permissions unless specifically required by the selected integration model.

After the permissions are applied, validate the connection in the Registration Portal. The expected result is that the content source is found and the permission validation reports canRead: ok. If that still fails, collect the following:

  • The exact canonical source URL, with tenant and customer-sensitive values redacted.
  • The selected source type from Site Admin.
  • The Registration Portal validation result.
  • The Microsoft Entra application name and application ID.
  • Confirmation that Sites.Selected is an Application permission.
  • Confirmation that the SharePoint site—not only the folder sharing link—has an application permission.
  • The Microsoft Graph correlation/request ID, if available.

The most likely correction is to replace the SharePoint sharing link with the canonical folder URL. Admin consent may be required for the application-permission setup, but admin consent by itself will not fix the issue unless the correct application is granted Sites.Selected and then assigned site-level write access.

Amit Vishwakarma - Adobe Commerce Champion 2025 | 17x Adobe certified | 6x Adobe SME
    Terms & ConditionsAccessibility statement

    Loading footer...