Hi everyone,
I am building a Maestro Case Management solution integrated with a custom UiPath App (EscalationApp_Final) for a human review task.
When running Debug on cloud, the process steps through the agent execution trail seamlessly, but fails immediately when executing the App Task element (tVcLetA93) inside the Human Review stage block.
The specific incident error log is:
Failure in the AppTasks request - (170000) AppTasks request failed with status NotFound. Response body could not be parsed: Unexpected character encountered while parsing value: S. Path ‘’, line 0, position 0. Incident ID: FAADD180-5211-4395-95D2-38F3659F0433 (Jun 25, 00:01:36)
What I’ve verified so far:
-
The app container EscalationApp_Final is cleanly built, validated with no red syntax errors inside App Studio, and successfully published to Orchestrator as Version 3.0.0.
-
The Case Plan JSON definition bindings correctly map to this resource:
JSON
{
"id": "b3mURfe26",
"name": "name",
"type": "string",
"resource": "app",
"resourceKey": "pugalesan2004@gmail.com's workspace (Converted).EscalationApp_Final",
"default": "EscalationApp_Final",
"propertyAttribute": "name"
}
- Inside the App’s Action Schema, input property data types match the Case variables (
prior_complaint_count is an Integer in Case Plan, and mapped to Whole number / System.Int32 in the App input properties).
Despite everything matching, Maestro continues to throw a NotFound 404 block when attempting to call the endpoint to provision the form. It seems like it cannot locate version 3.0.0 or something is broken with the underlying task schema request mapping.
Has anyone faced this specific unexpected character S parsing/NotFound issue at line 0 position 0 with AppTasks requests? Any advice on how to force the Maestro design canvas to properly recognize and bind the runtime application bundle would be highly appreciated!
Thanks in advance!
Most likely issue:
The app is bound to your personal workspace, not the folder the case runs in.
At runtime, Maestro resolves the AppTask’s app within the Orchestrator folder where the case instance executes, it cannot reach an app that only lives in your personal workspace. A working App-task binding’s resourceKey looks like Shared/.EscalationApp_Final (folder path + app name), not a …workspace (Converted) key. That mismatch is exactly what produces a NotFound when it tries to provision the form, and why it “can’t find 3.0.0.”
Second issue: your binding set is incomplete. You’ve bound only the name property. An App task needs both name and folderPath resolved, or it has no folder context to locate the app in. You need a second
binding, e.g.:
{
“id”: “b3mURfe27”,
“name”: “folderPath”,
“type”: “string”,
“resource”: “app”,
“resourceKey”: “Shared/.EscalationApp_Final”,
“default”: “Shared/”,
“propertyAttribute”: “folderPath”
}
I tried that also same error is coming
I’m hitting the exact same error during AgentHack 2026 — “Failure in the AppTasks request - (170000), AppTasks request failed with status NotFound. Response body could not be parsed: Unexpected character encountered while parsing value: S.” Same element pattern (App User task inside a Case stage), and same outcome even after explicitly publishing the App (v1.0.0) before running. I’m on the staging.uipath.com hackathon sandbox (hackathon26_1027). Has anyone from UiPath staff looked into this, or found a workaround? Trying to get an App task working inside Maestro Case for AgentHack and currently blocked.
The fixes, in the order I’d try them
- Deploy the App into the case’s folder - not just publish it. Open the App, and install/deploy it to the exact folder your case process runs in. If the case runs in Shared/ and the App lives elsewhere, you get this 404. This is the #1 cause.
- Use an Action App (with an action schema), not a plain Web App. Maestro Case App-User tasks bind to an app that exposes an action schema. A regular web app has no action contract for the case to invoke → NotFound.
- Check the binding in the caseplan for that task, the App-User task’s =bindings. needs to resolve. Setting the binding to empty so it resolves the App by name may fix it (the platform then matches the deployed App by name in-folder). If yours points at a stale key/version, it’ll 404.
- Version/folder drift: if you republished the App, make sure the case’s binding isn’t pinned to an old version that’s no longer the deployed one.
Why “I already published v1.0.0” doesn’t help - That step only guarantees the package exists. The runtime resolution path is folder → deployed App → action schema → binding by name. Break any link and you get exactly this 170000 NotFound + the bogus parsing value: S tail.
Found the real cause in my case: it’s not actually a binding/folder issue — it’s a hard license limit. When I tried redeploying the App into any workspace folder (Personal or Shared), I get: “Limit of 1 published process(es) in personal workspace reached. Upgrade user license for unlimited processes.” My Maestro Case process already occupies that single slot, so the App can never get published alongside it — which is exactly what triggers the NotFound/170000 error when the Case tries to call it at runtime. This seems like a hackathon sandbox tier limitation (1 published process per account) that conflicts directly with Track 1’s whole premise of building multi-component Case + App solutions. Tagging this for AgentHack organizers — anyone else hit this exact license wall?
