Share
ReportSummary
After our production environment was rebuilt via an environment copy (copied to a new Sandbox, then converted to Production), one cloud flow fails on every single run with UnresolvableHostName. The Dataverse connection it uses shows as Connected and works elsewhere. The flow has never succeeded since the copy.
Environment background
Original PROD had an issue; Microsoft's guidance was to copy it to a new environment
New environment was provisioned as Sandbox, then converted to Production
Environment is not in Administration mode; State = Ready
Copy completed approximately 8 days ago
Flow was created/copied in on the same day as the copy
The error
json
{
"error": {
"code": "UnresolvableHostName",
"message": "Http request failed with status code 'HostNotFound' and status message: 'No such host is known.'."
}
}
Failing action: Microsoft Dataverse → List rows (ListRecords)
Key detail: it fails in 0 seconds
Looking at the retry history, each of the 12 retries shows:
Duration: 0 seconds
Start time and end time are identical
This is not a timeout. The hostname is being rejected at resolution time, before any request goes out. Total run duration of ~3h 30m is purely the retry policy backing off between 12 instant failures.
Action inputs (raw)
json
{
"host": {
"connectionReferenceName": "shared_commondataserviceforapps",
"operationId": "ListRecords"
},
"parameters": {
"entityName": "xxx_campaignteams",
"fetchXml": "<fetch version=\"1.0\" mapping=\"logical\" distinct=\"true\">...</fetch>",
"accept": "application/json;odata.metadata=minimal"
}
}
Note there is no organization URL in the inputs — the host is resolved at runtime from the connection reference.
What works vs what fails
FlowDataverse connectionResult
Child Flow (different flow, same environment)Same connectionSucceeded
Failing flowSame connectionFails every run, 100%
Both flows are in the same solution, in the same environment, using the same Dataverse connection.
What we have already checked and ruled out
Environment is not in Administration mode; State = Ready
No active Microsoft service health incident
Dataverse connection status = Connected (green)
Connection reference in the solution is bound and shows a green check
The same connection succeeds in a different flow in the same environment
Flow status = On
Flow owner (service account) is Active with security roles assigned
FetchXML is valid — the query has not changed and worked pre-copy
Repointed the connection reference to a known-good connection — no change
Recreated the Dataverse connection — no change
Additional observation
The Dataverse connection is owned by a service principal. That service principal does not appear in the Application Users list of the new environment (application users are not carried across an environment copy).
Our working theory is that the Dataverse connector resolves the target org URL at runtime based on which environments the calling identity has access to. If that identity has no application user in the environment, the lookup returns nothing, the connector builds a request against an empty hostname, and DNS rejects it instantly — which would explain a 0-second HostNotFound rather than a 401/403.
We have not been able to confirm this. A comparison environment appears to have the same application user list and does not exhibit the problem.
Questions for the community
Has anyone seen UnresolvableHostName / HostNotFound on the Dataverse connector specifically after an environment copy, where the connection itself is healthy?
Does the Dataverse connector resolve the org URL from the calling identity's environment access at runtime? If so, would a missing Application User for a connection-owning service principal produce a DNS-level failure rather than an authorization failure?
Is there any way to inspect the actual hostname a Dataverse connection resolves to? Nothing in the maker portal or admin center appears to expose it.
Are there known cases of a flow retaining stale environment bindings after a copy that cannot be cleared by repointing connection references — requiring the flow to be recreated or the solution re-imported?
Constraint
We cannot edit flows directly in this environment (managed solution / no edit rights in production), so Save As and retry-policy changes are not available to us in place. Any suggestion that can be applied via connection references, application users, or the admin center is preferred.
Thanks in advance — happy to provide any additional run details, correlation IDs, or screenshots.
All responses (
Answers (
277
