Dodeca SharePoint Connector

Set OAuthConnectionID to the ID of a Microsoft Authorization Connector connection (an OAuthConnection of kind MicrosoftConnection). The Microsoft Authorization Connector performs the actual Entra ID (Azure AD) sign-in — interactive delegated login, client credentials, or certificate, depending on how that connection is configured — and SharePointConnection requests a token scoped to the SharePoint site from it.

This path authenticates directly against the Microsoft identity platform (Entra ID) and is unaffected by the Azure ACS retirement described below.

Whether the Entra app registration behind a SharePoint connection is configured as app-only (confidential client) or delegated (public client) determines whose identity SharePoint sees for every operation this connector performs:

If a ClientCertificate (or, formerly, ClientSecret) would otherwise need to be installed on every end-user workstation just so that arbitrary users can publish documents, that’s a sign the connection should be reconfigured as delegated/public client instead: Dodeca then publishes to SharePoint on the signed-in user’s behalf, and no secret needs to be protected on the client at all.

When the Entra app registration behind a SharePoint connection uses the Sites.Selected permission — recommended over tenant-wide Sites.Read.All/Sites.ReadWrite.All — configuration is a two-step process, and both steps are required:

The roles that can be granted per site:

An administrator can create and verify grants with PnP PowerShell:

or by calling the Graph endpoint directly:

Creating a site-level grant is itself a privileged operation: the identity making the call needs Sites.FullControl.All (or to be a sufficiently privileged SharePoint/tenant administrator signing in interactively with PnP PowerShell).

Delegated connections intersect with the user’s own permissions. For a delegated (public client) connection, effective access is the intersection of the signed-in user’s SharePoint permissions and the app’s site grant — the app can never exceed the user, and the user can never exceed the app’s grant through Dodeca. In particular, "the user can browse to the library and upload manually" demonstrates the user’s access only; it says nothing about whether the app has a grant.

Symptom of a missing (or read-only) site grant: a site-only connection test can report success while every document library and list operation fails with The specified document library or path could not be found. — regardless of the path used, including paths that resolve fine in a browser. Without a test document library configured, the connection test verifies only that the signed-in identity can open the site, and SharePoint reports folders the app cannot access as non-existent rather than as access denied. Configure the focused read/write test described in Testing a SharePoint Connection below to exercise the same library and upload paths as the real operation. If a path has been verified in a browser and operations still report it as not found, check the site grant before debugging the path.

A read-only grant is not limited to failing the write itself: the document library lookup that precedes the write has been observed to be denied as well, so the operation fails with "could not be found" before it ever attempts to upload — for every path, including one that is provably correct. When a library or list cannot be resolved, the Smart Client log records the path and whether the connection can view items on the site. Add-items permission is checked and reported by the focused connection test only after an actual upload fails; view items = yes, add items = no there is the signature of a read-only grant that needs upgrading to write. Workbook-operation errors stay concise and report only a conclusion the lookup or probes established — see the Logging and Diagnostics section below.

TenantID, ClientID, ClientSecret, ClientCertificate, and ClientCertificatePassword are legacy properties retained as a migration lifeline for connections created before the Microsoft Authorization Connector existed. They are hidden in the property grid unless already populated, and new connections should use OAuthConnectionID instead. Saving a connection metadata change deliberately removes these deprecated values, so migrate the connection to OAuthConnectionID before editing and saving it. When OAuthConnectionID is not set, the connection falls back to one of three direct token-acquisition flows depending on which properties are populated:

SiteType (Online, OnPrem, or Extranet) controls how DefaultNetworkCredentials/SpecifiedCredentials credentials are applied — Online uses SharePoint Online cookie-based auth, Extranet uses an explicit NTLM credential cache, and OnPrem passes the credential directly.

A failed lookup is reported in two places, because it has two audiences. The error states the conclusion, for the person who ran the view. The Smart Client log records the evidence behind it, for whoever has to diagnose it afterwards.

The error names what was concluded and where to look for the rest:

Nothing in that message requires knowing how the connection is configured, and it exposes neither the structure of the site nor what the connection is permitted to do there.

The SharePointOperations overloads that take a DocumentLibraryPath or ListPath resolve that path against the site’s server-relative URL as reported by SharePoint, and then request the resulting URL. All three values are recorded in the log, so that a mistyped path can be told apart from one that was constructed incorrectly:

A duplicated site segment (/sites/finance/sites/finance/...) or an unexpectedly encoded character is visible immediately in the requested URL, without needing a network trace.

When a document library or folder cannot be resolved, the log also records how far along the path SharePoint could get, and what exists at that point:

A path that was never valid and a path whose final folder has not been created yet produce the same "could not be found" on their own. Reporting the deepest part of the path that does resolve separates them: here the library and the year folder exist and only the month is missing, which is the ordinary outcome for a report that publishes into month-named folders before the month’s folder has been created. When nothing along the path resolves, no such line appears — that points at the site itself, the path’s leading segments, or access.

The folder listing is capped at 25 names, with a count of the remainder.

What SharePoint itself said is recorded too, because its own sentence separates an item that is absent from one the connection cannot reach without any investigation at all:

The first line is what the lookup itself was told. The second appears when walking back up the path, or reading the permissions, was refused in a different way — which is the case the investigation exists to resolve, so the two are kept apart rather than the first standing for both. When both would say the same thing, only the first is written.

On SharePoint Online, when the document library or list itself could not be resolved, the log additionally records whether the connection can view items on the site, because SharePoint Online reports a library the connection cannot reach as though it does not exist. Add-items access is irrelevant to explaining a read lookup and is not reported here. This reporting is specific to the Online and Standard builds; the on-premises targets neither disguise an inaccessible library as a missing one nor use Sites.Selected grants, so their logs do not raise permissions:

Every interpretation that points at a site grant refers the reader to the Granting Sites.Selected Access to a Specific SharePoint Site section, and the log entry closes with that section’s published address:

The address is recorded once, on its own line, however many of the lines above refer to it. A section title alone leaves the reader searching, and whoever is reading this log is already stuck.

The error raised for the same failure reports only a conclusion the lookup or probes established, such as the missing folder or an explicit access denial, with no permission values, grant name, or documentation address. A site-level result of view items = yes does not by itself prove that a particular library is reachable, so it is not turned into advice that the path is wrong. Lack of add-items permission is reported as the conclusion of an actual failed write, not as the explanation for a read failure.

This view-items result is reported only when the library or list could not be resolved. When the container resolved and an item inside it was missing — a document that does not exist in a library the connection can read, for instance — neither the log nor the error raises permissions at all, because nothing suggests they are involved. The separate focused connection write test reports add-items access only after an actual upload fails, as described under Testing a SharePoint Connection.

A tolerated miss is recorded but not investigated. Establishing how far the path resolves and what the connection may do costs around ten round trips where the lookup itself took one. When ContinueOnItemNotFound is set, the operation is expected to miss — a script publishing into a folder it will create, or a loop downloading whatever happens to be present — and paying that on every iteration would invite throttling for a message nobody is going to see. The supplied path, the site URL, and the URL requested are still written to the log; the walk and the permissions read are not performed.

For a delegated connection, effective access is the intersection of the signed-in user’s permissions and the app’s site grant, so a permission reported as available to the connection may still be unavailable to the application acting alone. For an app-only connection, the reported permissions are the application’s own.

This permission describes the site, not a particular library. It is read from the web, and an application can report view items = yes and still be denied when it opens a specific document library. Treat the readout as a strong indication rather than proof: view items = yes does not guarantee that a given library can be reached.

Confirming a permissions cause conclusively. With request/response logging enabled, the response to the folder lookup carries the definitive signal. SharePoint returns HTTP 200 with the folder reported as non-existent, and adds a header naming the real reason:

Look for that header on the response to the GetFolderByServerRelativeUrl request specifically. When it appears there and not on the surrounding requests, the library was not missing — it was unreachable, and the site grant is what needs fixing. This header is known to appear spuriously in some SharePoint Online responses, so weigh it by where it lands rather than by its presence alone.

The connector writes its SharePoint traffic to the client’s request/response logging path, using the same toggle and the same folder as every other HTTP-based connector. Both the CSOM protocol calls and the binary transfers performed by document uploads and downloads are captured.

Enable the logging toggle and set the logging path before reproducing the failure. Whether content is captured is decided for each request as that request is created, so a toggle enabled partway through an operation captures only the requests issued after it — never the ones that have already gone out, which are usually the ones being investigated. Enable it first, then reproduce. While the toggle is off, no content is captured and no files are written — request and response streams are passed straight through untouched.

Each request and response is written as a separate file:

The files are written by the same writer the other Dodeca connectors use, so they carry the same naming and the same conventions. That writer became reachable to this connector in Dodeca 8.10. Dropped into an earlier client, the connector writes the files itself instead, naming them <tenant>.HttpWebRequest.<timestamp>-<n>.request.xml and <tenant>.HttpWebResponse.<timestamp>-<n>.<status>.response.txt and leaving JSON bodies unformatted. The contents are otherwise the same, and the same exclusions apply. The extension follows the content rather than the direction: .xml for a body that is XML, .yml otherwise. In practice the CSOM protocol requests are XML and their responses are JSON, so look for responses as .yml — searching the folder for .response.xml will find nothing. JSON bodies are indented rather than written as the single line they arrive as. Each file begins with the request line or status line and the headers, as comments.

Four limits apply, so that the folder stays small enough to collect and safe enough to send:

Independently of the toggle, the Smart Client log records the method and URL of each SharePoint request, which is often enough to identify a wrongly constructed URL without collecting logs at all.