Fair warning up front: I have not hit this specific one myself, so treat the below as reasoning from how the pieces normally behave rather than something I have confirmed in production. Your isolation is good enough that it is worth working through regardless.
First, disregard my Processes table point entirely. System Administrator in both environments rules that out. A sysadmin cannot be short of Dataverse privileges, which means the error message is misleading and something other than your identity is failing the write.
Your ADO comparison is the sharpest detail in the whole thread. A connector-based topic in the same collection accepts a user connection, while an agent flow in that same collection does not. Those take different code paths. Connector connections bind at the agent level, whereas agent flow run-only connections write a record against the flow in Dataverse. So the fault sits specifically in the agent flow connection path under a component collection, not in component collections generally. Lead with that if this goes to support.
Cheap things to try first, roughly in order of effort:
- Republish the agent. Adding a component collection does not always refresh tool connection bindings until a publish. Thirty seconds, and worth ruling out.
- Remove and re-add the component collection to the agent, then publish. Forces the agent to rebuild its tool registration for the flow.
- Turn the flow off and on in the target environment. Solution-imported flows can land with run-only configuration present but not fully committed. Toggling forces a rewrite of that state.
- Delete both run-only entries and add yourself explicitly, then save. Those two entries look like application users rather than people, and both show what appears to be the same truncated GUID. If they are stale references to principals that exist in source but not in target, the write may be failing on them rather than on you. This is the one I would try first if I had to pick one.
- Reassign the flow owner to yourself in the target environment. You noted a system user appeared as co-owner there but not in source, so ownership was changed by the import rather than by you.
- Isolate the import step. Export unmanaged, remove the flow from the collection, import, then add the flow back to the collection locally in the target environment. If a locally assembled collection works where an imported one does not, that separates the collection concept from the import process, which is useful either way.
If none of that moves it, open a support ticket rather than continuing to guess. Before you do, grab the real error: F12, network tab, click Submit, and read the failing request's response body. Dataverse usually names the actual privilege and the identity it was evaluated against, which will tell you whether this is you, the agent's application user, or something the import created. Not a diagnostic step so much as what turns a two-week back and forth into a one-week one.
Your repro is already complete, same flow works in a plain solution, fails in a component collection, both managed and unmanaged, reproducible as System Administrator. Given your end goal of reusable managed collections across multiple agents, this needs a real fix rather than a workaround.
