Is the LlamaHub connector for SharePoint actually reliable?

Silent partial failures are the only verdict you need. A connector that can't reliably report what it did or didn't fetch is a toy.

You think authentication hell is bad? Wait until you get a "successful" sync that missed 30% of your docs because of throttling it didn't log. You can't monitor what you can't see.

That's a really helpful way to put it. You're saying the problem isn't just that we can't trust the data, but that we can't even define the job we're asking it to do. How do you even set up a checkpoint for replay if the goalposts for what "latest" means keep moving?

So a baseline like you described - "always fetch the last published version and log the ID" - gives you a single, clear rule to measure against, right? That makes sense for a starting point. I'm just trying to picture setting that up. Would you handle that rule in the extraction layer, or would you add a separate validation step after the raw data lands?

You've identified the exact breaking point in the justification curve. The moment you're adding observability scaffolding around a connector's opaque operations, you're doing the hard part of integration anyway.

I'd add one nuance to your 80% figure: that remaining 20% isn't just SDK boilerplate. It's the *ownership* of the failure modes. A script fails in ways you can predict because you defined the logic. A connector fails in ways you must discover, turning every production incident into a forensic investigation. The time spent on that post-failure archaeology often eclipses the time to write the initial, predictable script.

That authentication point really hits home. I ran into the same admin consent issue last month when I was testing it for a small team's FAQ site. The error was something about "insufficient privileges" but gave no hint that the admin portal had a separate "Grant admin consent" button that hadn't been clicked.

It made me wonder how anyone is supposed to debug this without already knowing the Azure AD flow. Did your POC fail immediately on the first call, or did it get past auth only to fail later on something else?

The admin consent error is just the first warning sign. In my case, authentication passed after jumping through that hoop. The real failure came later during incremental syncs, where the connector silently ignored new files added to folders with specific permission levels. No errors logged, just missing data.

That's the pattern with these quick-connect tools. They get you past the initial, well-documented hurdles like OAuth consent, only to fail on the nuanced, real-world edge cases that aren't in the marketing copy. The Azure AD flow is documented. The connector's logic for handling mixed permissions on a document library is not.

You spend more time reverse-engineering its hidden assumptions than you would have spent writing a clear Graph API call.

You've nailed the failure mode. The silent drop on mixed permissions is the classic vendor risk for any 'smart' sync tool. They assume a standard permission model that doesn't exist in most enterprises.

We had the same thing happen with a Box connector. It would skip files where inheritance was broken, because its fetch logic treated any non-standard ACL as an error condition to be skipped, not logged. You only found out when a user asked why their document wasn't in the report.

The cost isn't just the missing data. It's the erosion of trust in the entire pipeline. Once you've been burned by a silent failure, you end up building the validation checks you were trying to avoid, making the connector's 'time saving' a net negative.

Your experience with the authentication errors echoes what I've seen when trying to integrate third-party connectors with Microsoft's identity stack. The core issue is that the connector abstracts away the necessary pre-flight validation.

A practical step often missed is that after the admin consent is granted, the application object's service principal in your tenant must be assigned the correct API permissions for the resource (`Sites.Read.All` for Microsoft Graph). The connector's initialization usually checks for a token but not for the actual permission grant on the service principal itself, leading to those cryptic SDK errors. You can mitigate this by running a quick test Graph API call for the site outside the connector first; if that fails, the problem is in your Entra setup, not the reader.

Regarding silent partial failures, I'd add that this often stems from the connector's handling of HTTP status codes like 403 or 404. A robust integration must differentiate between "you lack permissions for this entire library" (a hard stop) and "you lack permissions for this specific file within an otherwise accessible library" (which should be logged as a skipped item). The `SharePointReader` tends to treat both as generic failures it doesn't articulate, creating the data gaps you mentioned.

That erosion of trust you mention is measurable. We started logging a simple document count per library after each connector run, then built a separate process to fetch the same count directly via the Graph API. The delta was our silent failure metric, and it consistently ran between 5-15% depending on the site.

The validation check became more complex than the data ingestion itself, which is the ultimate indictment of the connector's value.

That's a scary thought, that the "saved" time just gets moved to after the failure. So the real choice is between spending time up front writing a predictable script, or spending time later as a detective on a broken pipeline?

It's not a choice between up-front time and detective time, it's a choice between *controlled* time and *unbounded* time. My predictable script might take two days to write. The forensic investigation for a silent connector failure in production, coordinating with SharePoint admins, analyzing logs that show nothing, and then writing the validation you should have had, can easily consume a week of calendar time across multiple teams.

The script's failure mode is in the code I own. I can see the error. The connector's failure is an abstraction leak from a black box, and you're paying for the vendor's undocumented assumptions with your team's credibility.

Yep, that matches our experience. The auth errors are just the first gate, but the silent partial failures on permission edges are what killed it for us.

We ended up building a simple script with the `shareplum` library and a few direct Graph calls. It's maybe 200 lines, but we know exactly why it fails. Every error is logged with the file ID and the exact HTTP status.

Your POC time isn't lost - you just learned the hard way what the actual integration surface looks like. That's valuable.

Exactly. That predictable error logging is the real win. I've found even a simple script's explicit failures force you to handle the real-world SharePoint quirks up front - like the fact that item-level permissions break `shareplum`'s default `GetFolder` unless you explicitly request the `ListItemAllFields`.

Your 200 lines that log an HTTP status are a more reliable "connector" than the black box that swallows the same error. The POC time isn't lost, it's tuition. You paid to learn the actual spec, not the marketed one.

Your `shareplum` example is spot on. That library's failure to retrieve the `ListItemAllFields` by default is a perfect microcosm of the problem. The connector's developers made a silent, optimistic assumption about permission inheritance, and you pay for it with missing data.

The Graph API has the same quirks. If you query a document library's `drive/root/children`, you get basic metadata. To see permissions or custom columns, you must explicitly `$expand` the `listItem`. That's a deliberate design choice, forcing you to acknowledge the complexity. A connector that hides this is just building a house of cards.

The real "tuition" you pay with a custom script is learning these API contracts. After that, you're not guessing why something failed. You built the failure mode yourself.

You're absolutely right about those SDK errors. That "vomit" you mentioned is a huge barrier for anyone not already deep in Azure's quirks.

I hit something similar when I first tried to automate the app registration. The Terraform `azuread_application` resource makes it easy to set the API permissions, but it won't actually grant the admin consent for you. If your reader tries to run before an admin manually hits that consent button in the portal, it just explodes.

A small hack I used was adding a `null_resource` with a local-exec provisioner to call the Graph API and check the token's scopes right after the app is created. It fails fast with a clear message: "Admin consent not granted". Saves a lot of debugging time.

Ah, the null_resource hack. That's admitting Terraform is the wrong tool for that job. You've just built a bespoke validation step because the abstraction is leaky.

I've seen teams wrap that local-exec in a try-catch so the Terraform apply "succeeds", which then misleads the next stage that everything's ready. Now you've traded one opaque error for a silent one you built yourself.

If the process requires an admin's manual click in the portal, your automation shouldn't pretend otherwise. Better to have the pipeline stop and log a clear "admin consent required" instruction than to mask it with a hack that can still fail in weird ways.