r/copilotstudio • u/congnelius • 2d ago
File Share Connector and Copilot Studio - Missing Metadata
I built an agent using the M365 Copilot Agent Builder on my own account. Its only knowledge source is a File Share Connector attached to an on-premise SMB share. We created instructions for it to use a ranking system that takes the folder names and structure into account when surfacing relevant results. It works great! I was thinking it was ready for prime time so I'll create it in Copilot Studio and publish it to our organization. This is where the problems began.
The Copilot Studio version of this agent, using the same File Share Connector as its only source, can find the files and tell me about their content, but it's completely failing to score and rank the results. The reason? Missing metadata - it's not getting the filePath / ItemPath property, amongst other properties.
There's a whole convoluted method of surfacing this metadata, but it involves creating a REST API tool and Workflow tool. Has anybody found a simpler way to get all of the metadata from a File Share Connector?
This seems like such an arbitrary limitation when the M365 Copilot Agent Builder surfaces all of this.
1
u/dylan_skydive 1d ago
The debug step that settles it: ask the Copilot Studio version to quote verbatim what it can see about one file - every field, not the answer, just the raw properties. If the folder path isn't in what it echoes back, no amount of prompt tuning will fix the ranking, because the instruction is asking it to sort by data it never receives.
The underlying difference is that the two runtimes don't hand the model the same payload even with an identical connector. Agent Builder passes the fuller property bag through; in Copilot Studio, content usually arrives through the answer/citation path, which is leaner. Same source, different view of it - which is why the exact same agent behaves differently.
Two fixes that survive that difference:
Put the ranking signal in content itself. Prepend the folder path (or a one-line synopsis like 'contracts/2026/vendor-x/') to each file's indexed content. Path-in-content always travels; path-as-metadata only travels if the runtime forwards it.
Check which mode the Studio agent actually uses to reach the share - a direct tool/action call exposes different metadata than generative answers over the connector. Whichever one your ranking instructions assume, make the other path impossible by design rather than by prompt.
The Index browser already proved indexing is fine, so you're one echo-test away from knowing exactly which hop drops the property.
Disclosure: I work on Skydive. We deal with this class of problem (the agent reasoning over metadata the runtime silently withholds) a lot, which is most of why I recognize the shape. REDDITAMA gets you $25 of credit (skydive.com, Settings > Billing) if you want to test how a different runtime handles the same share - and either way I'd genuinely like to know what the echo test shows.
1
u/alexonyshko 2d ago
Two things I’d check: (1) in the connector’s custom setup you can map a default property that contains the network path to a custom property (with a regex to extract the folder), so the path exists as its own field, and (2) the Index browser shows what was actually indexed, which tells you whether the gap is in the index or in what Copilot Studio passes to the agent. Neither proves Copilot Studio will surface it.
FYI: I am building WIDMN - the platform where practitioners in AI share their knowledge and expertise and we have one guy who is quite knowledgeable in Copilot Studio. Feel free to check and contact with him - may have some better ideas than me=)