@uipath/skills 1.195.0

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/argument-mismatch-400.md

@@ -0,0 +1,38 @@
+---
+confidence: medium
+---
+
+# Invalid Status Code 400 — Argument Mismatch
+
+## Context
+
+What this looks like:
+- HTTP 400 with `Argument values did not match definitions` or similar
+- Often a sibling of the more specific top-20 errors:
+  - [input-schema-mismatch](input-schema-mismatch.md) — full payload schema mismatch on workflow/agent start
+  - [missing-required-parameter](missing-required-parameter.md) — a single named required field is absent
+
+What can cause it:
+- Arguments do not match the consuming activity's expected types or schema
+- Wrong number or order of arguments passed to a service task or API call
+- A workflow input renamed without updating callers
+
+What to look for:
+- Whether the error names a single field (→ [missing-required-parameter](missing-required-parameter.md))
+- Whether the error mentions schema conformance broadly (→ [input-schema-mismatch](input-schema-mismatch.md))
+- Otherwise, the activity's argument signature vs what's being passed
+
+## Investigation
+
+> Substitute `<type>` with `bpmn`, `flow`, or `case` per the [Maestro investigation guide](../investigation_guide.md) § Determine the Maestro process type.
+
+
+1. Get the incident: `uip maestro <type> instance incidents <instance-id> -f <folder-key> --output json`
+2. Pull the inputs sent to the failing activity: `uip maestro <type> instance variables <instance-id> -f <folder-key> --parent-element-id <element-id> --output json`
+3. Compare against the activity's argument definitions in the BPMN: `uip maestro <type> instance asset <instance-id> -f <folder-key> --output json`
+
+## Resolution
+
+- Fix the argument mapping in the workflow or consuming activity to match the expected definitions
+- Validate payload structure (types, order, names) before API or activity calls
+- For more specific failures, route to [input-schema-mismatch](input-schema-mismatch.md) or [missing-required-parameter](missing-required-parameter.md)

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/attachment-not-found.md

@@ -0,0 +1,24 @@
+---
+confidence: high
+---
+
+# Attachment Not Found After Job Retention
+
+## Context
+
+What this looks like:
+- "Attachment not found" or 404 on file access
+- Files disappear after some time but process initially worked
+
+What can cause it:
+- Attachments are linked to the job that created them. Job retention policy deletes the job and orphans the attachment
+
+## Investigation
+
+1. Check the job retention policy for the folder
+2. Verify the job that created the attachment still exists
+
+## Resolution
+
+- Redesign the process so downstream jobs download files directly from the source (e.g., Data Fabric, storage bucket) instead of passing file references as job arguments
+- Alternatively, increase job retention period (delays the issue but does not fix it)

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/autopilot-429.md

@@ -0,0 +1,24 @@
+---
+confidence: high
+---
+
+# Autopilot 429 Too Many Requests
+
+## Context
+
+What this looks like:
+- "Failed to apply" error in Autopilot for Maestro
+- HTTP 429 error
+
+What can cause it:
+- Rate limiting on the Maestro backend or LLM Gateway side when using Autopilot features
+
+## Investigation
+
+1. Confirm the error is HTTP 429
+2. Check if the issue is intermittent or persistent
+
+## Resolution
+
+- Retry after a short wait
+- No permanent fix available yet

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/boundary-event-duplicate-task.md

@@ -0,0 +1,35 @@
+---
+confidence: medium
+---
+
+# Boundary Event and Duplicate Task Execution
+
+## Context
+
+What this looks like:
+- Task running twice or duplicate agent runs
+- Boundary events firing unexpectedly
+- Error boundary events not logging incidents
+
+What can cause it:
+- Both Error and Timer boundary events attached to the same task — previously boundary events were not canceled when the attached task faulted (fixed in later releases)
+- Error boundary events suppressing incident logging — this is expected BPMN behavior: boundary error events catch errors and redirect the flow, so incidents only appear for uncaught errors
+- For Data Fabric tasks: error output (detail, category) is not exposed on boundary events unlike API Workflow tasks (known limitation)
+
+What to look for:
+- Check which boundary events are attached to the task
+- Check if the task has both Error and Timer boundary events
+- Check if the issue is duplicate execution or missing incident logging
+
+## Investigation
+
+1. Examine the BPMN process for boundary events on the affected task
+2. Check if both Error and Timer boundary events are attached to the same task
+3. Check if error boundary events are catching errors (expected behavior — no incident logged)
+4. For Data Fabric tasks: check if error output fields are expected but not available
+
+## Resolution
+
+- **If duplicate execution due to boundary event bug:** update to the latest version containing the boundary event cancellation fix
+- **If missing incidents:** this is expected BPMN behavior when error boundary events catch the error; incidents only appear for uncaught errors
+- **If Data Fabric error output needed:** workaround is to use API Workflow tasks instead (Data Fabric boundary event error output is a known limitation)

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/bpmn-job-stuck.md

@@ -0,0 +1,23 @@
+---
+confidence: low
+---
+
+# BPMN Job Stuck or No Error Reported
+
+## Context
+
+What this looks like:
+- BPMN process instance appears stuck with no progress
+- No error reported in Orchestrator job state
+- Child jobs may or may not have been created
+
+What can cause it:
+- A connection was disconnected during execution — Maestro instances do not propagate faults to Orchestrator job state by default
+- ~60-second delay in WaitForOrchestratorJobCompletion — known backend issue where the orchestration layer takes ~60s to resume after receiving a job completion signal
+- Parent Maestro instance was cancelled
+- Child job was never created — upstream issue with binding resolution, folder mismatch, or missing release
+
+What to look for:
+- Check Maestro Instance Management for incidents (may not appear in Orchestrator)
+- Check if child jobs were actually created
+- Check if the parent instance is still active

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/debug-vs-deploy.md

@@ -0,0 +1,39 @@
+---
+confidence: medium
+---
+
+# Process Works in Debug But Fails After Deploy
+
+## Context
+
+What this looks like:
+- Process runs successfully in debug mode but fails after publishing/deploying
+- Errors only appear in deployed mode, not during Studio Web debugging
+
+What can cause it:
+- Debug runs under the user's identity; deployed runs under the robot account which may lack folder-level permissions (Triggers, Connections.View, asset access)
+- Robot/Studio version incompatibility — file type handling changed between Studio Desktop 24.10 and newer versions; agents expect File objects with metadata that older Robot versions do not produce
+- `debug_overwrites.json` redirects folder bindings during debug; deployed mode resolves against the actual folder structure via `bindings_v2.json`
+- For agent + index scenarios: context indexes accessible to the user account may not be accessible to the robot account
+- For Integration Service triggers: the robot account needs "Triggers" permission in the folder where the connection resides, not just "Connections.View"
+
+What to look for:
+- Compare which identity runs in debug vs deployed (user vs robot account)
+- Check folder permissions for the robot account
+- Check Robot version compatibility
+
+## Investigation
+
+1. Identify the error message in deployed mode
+2. Check robot account permissions in the target folder — specifically Triggers, Connections.View, asset access
+3. Compare Robot version against Studio Web version requirements
+4. Check `bindings_v2.json` for folder binding references and compare against actual folder structure
+5. For agent tasks: verify context indexes are accessible to the robot account
+6. For IS triggers: verify "Triggers" permission on the robot account in the connection folder
+
+## Resolution
+
+- **If permission issue:** grant the robot account the required permissions in the target folder
+- **If version mismatch:** upgrade Robot to the latest version
+- **If folder binding issue:** fix `bindings_v2.json` references to point to correct folders
+- **If context index access:** grant robot account access to the required context indexes

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/deployment-datetime-input.md

@@ -0,0 +1,23 @@
+---
+confidence: high
+---
+
+# Deployment Error — DateTime Input Parameters
+
+## Context
+
+What this looks like:
+- "Package entry points definition is invalid"
+- Deployment fails after adding input parameters to a BPMN start event
+
+What can cause it:
+- DateTime data types on BPMN start event input parameters cause the package entry points definition to become invalid
+
+## Investigation
+
+1. Check the BPMN start event input parameters for DateTime data types
+
+## Resolution
+
+- Change all BPMN input parameters from DateTime to text/string data type
+- Verify both deployment and debug mode work after changing parameter types

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/deployment-email-received.md

@@ -0,0 +1,23 @@
+---
+confidence: high
+---
+
+# Deployment Error — EMAIL_RECEIVED
+
+## Context
+
+What this looks like:
+- Deployment fails with error code 4006
+- Error: "No package resource with type 'Property' and key 'EMAIL_RECEIVED' was found"
+
+What can cause it:
+- Integration Service component exposed a new property on the Outlook email received trigger that was out of sync with the packaging component
+
+## Investigation
+
+1. Confirm the error code is 4006 and the message references "EMAIL_RECEIVED"
+
+## Resolution
+
+- Open the email received trigger configuration in Studio Web and republish the solution
+- Verify deployment succeeds and the trigger fires correctly in the target environment

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/deployment-failure.md

@@ -0,0 +1,36 @@
+---
+confidence: medium
+---
+
+# Deployment Failure
+
+## Context
+
+What this looks like:
+- Solution deployment fails with various errors
+- Errors during publish or deploy from Studio Web to Orchestrator
+
+What can cause it:
+- Duplicate entry points — multiple start points with the same ID cause deployment or runtime 404 errors
+- Cross-tenant solution deployment trigger conflicts — deploying to a tenant that already has triggers from a previous version
+- Manually deleted triggers from Orchestrator UI creating stale ServiceKey references and duplicate trigger name errors
+- IS/packaging sync issues (see specific playbooks for EMAIL_RECEIVED, DateTime inputs)
+
+What to look for:
+- Check the specific error code and message
+- Check if this is a fresh deployment or an upgrade of an existing solution
+- Check if triggers were manually modified in Orchestrator UI
+
+## Investigation
+
+1. Get the exact deployment error message and code
+2. Check for duplicate entry points in the BPMN process
+3. Check if triggers were manually deleted from Orchestrator UI before this deployment
+4. For cross-tenant deployments: check if the target tenant already has triggers from a previous version
+5. For upgrade deployments: verify no manual trigger modifications were made outside Studio Web
+
+## Resolution
+
+- **If duplicate entry points:** delete the duplicate start points in Studio Web and republish
+- **If cross-tenant trigger conflict:** deploy to a fresh tenant as a workaround; check latest release notes for a permanent fix
+- **If stale trigger references:** do not manually delete triggers from Orchestrator UI; redeploy the solution cleanly

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/expression-evaluation-errors.md

@@ -0,0 +1,52 @@
+---
+confidence: high
+---
+
+# Expression Evaluation — Property Not Found
+
+## Context
+
+What this looks like:
+- HTTP 400 with `Error evaluating expression in activity inputs for element: ...`
+- `Property 'X' not found against object of type ExpressionDictionary`
+- "Expression could not be parameterized" in parallel multi-instance subprocesses
+- Job faulted due to null input during GUID parsing
+- Ternary expressions failing in C# due to type erasure in Dynamic Expresso
+- Underlying engine codes: `400300` (`InputVariablesEvaluationError`), `400301` (`ExpressionEvaluationError`), `400302` (`FlowExpressionEvaluationError` — gateway flows)
+
+What can cause it:
+- Expression references a variable/property that does not exist in the variable dictionary at evaluation time (typo, never assigned, conditionally assigned on a path not taken)
+- Property casing — objects wrapped in `ExpressionDictionary` expose lowercase property accessors (e.g., `vars.error.detail` works, `vars.error.Detail` does not)
+- Iterator references inside parallel multi-instance subprocesses were not supported historically — known workaround was to use embedded subprocess
+- C# ternary type-erasure bug in Dynamic Expresso — known workaround is to switch to JS expressions (`=js:` prefix)
+- Script Task iterator references unresolved by the engine (fix shipped in alpha and rolled forward)
+- Upstream activity failed silently and left the consumed variable unset
+
+What to look for:
+- The exact property/variable name in `errorDetails`
+- Whether the variable is initialized on every execution path that leads to this expression
+- Whether the expression is C# or JS — both have distinct known bugs
+
+## Investigation
+
+> Substitute `<type>` with `bpmn`, `flow`, or `case` per the [Maestro investigation guide](../investigation_guide.md) § Determine the Maestro process type.
+
+
+1. Get the incident: `uip maestro <type> instance incidents <instance-id> -f <folder-key> --output json` — `errorDetails` includes the full expression
+2. Pull the variables snapshot at the failing element: `uip maestro <type> instance variables <instance-id> -f <folder-key> --parent-element-id <element-id> --output json` — confirm whether the referenced variable exists and what's defined
+3. Walk element executions to find an upstream branch that should have initialized the variable: `uip maestro <type> instance element-executions <instance-id> -f <folder-key> --output json`
+4. Inspect the expression in the BPMN: `uip maestro <type> instance asset <instance-id> -f <folder-key> --output json`
+
+## Resolution
+
+- **If typo / missing variable:** correct the name; use Maestro Expression Editor autocomplete (Ctrl+Space). The "Fix variables" dialog flags broken references
+- **If casing mismatch on `ExpressionDictionary`:** access nested properties in lowercase (e.g., `vars.error.detail`)
+- **If variable conditionally assigned:** initialize the variable on all paths or default it at the process start
+- **If parallel multi-instance + iterator reference fails:** switch to embedded subprocess, or upgrade to a Maestro version where the parallel marker on the subprocess is supported
+- **If C# ternary type-erasure:** rewrite as JS expression with `=js:` prefix
+- **If null on GUID parse:** add a null check before parsing
+- **If upstream silently failed:** fix the upstream task or add a boundary error event so the failure surfaces
+
+## References
+
+- [Docs: Variables and Expression Editor](https://docs.uipath.com/maestro/automation-cloud/latest/user-guide/variables-and-expression-editor)

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/file-field-required.md

@@ -0,0 +1,45 @@
+---
+confidence: high
+---
+
+# 'File' Field Required — DAP-RT-1003 (502)
+
+## Context
+
+What this looks like:
+- HTTP 502 surfaced by Maestro
+- Error message: `The "File" field is required. Error code: DAP-RT-1003.`
+- Always raised by an Integration Service activity that expects a file input (typically Document Understanding or GenAI activities)
+
+What can cause it:
+- The `File` input on the activity is unmapped or mapped to a variable that is `null`/empty at runtime
+- The upstream activity that should have produced the file failed silently and left the file variable unset
+- File was previously linked to an Orchestrator job whose retention expired (orphaned attachment — see [attachment-not-found](attachment-not-found.md))
+- File variable defined as a process variable instead of an argument, breaking the binding in deployed mode
+
+What to look for:
+- The activity's `elementId` from the incident → confirm it's a DU/GenAI step
+- Variables API: is the file variable `null`?
+- The upstream activity's status — did it actually produce a file?
+
+## Investigation
+
+> Substitute `<type>` with `bpmn`, `flow`, or `case` per the [Maestro investigation guide](../investigation_guide.md) § Determine the Maestro process type.
+
+
+1. Get the incident: `uip maestro <type> instance incidents <instance-id> -f <folder-key> --output json` — incident `elementId` identifies the failing activity
+2. Pull the variables for that element: `uip maestro <type> instance variables <instance-id> -f <folder-key> --parent-element-id <element-id> --output json` — confirm the file variable is null
+3. Trace upstream element executions to see where the file should have been produced: `uip maestro <type> instance element-executions <instance-id> -f <folder-key> --output json`
+4. If the file came from a previous job, check whether job retention has elapsed (see [attachment-not-found](attachment-not-found.md))
+
+## Resolution
+
+- **If unmapped input:** map the activity's `File` input to a non-null variable in the BPMN task's input mapping
+- **If upstream failure:** fix the upstream activity that should have populated the file; add a boundary error event or a null check before the DU/GenAI step
+- **If null on optional path:** add an exclusive gateway before the DU/GenAI step that skips it when the file is null
+- **If attachment orphaned by retention:** redesign so files come from a stable source (Data Fabric, storage bucket) rather than from a job attachment — see [attachment-not-found](attachment-not-found.md)
+- **If file modeled as a variable:** convert it to an argument so binding resolution works in deployed mode
+
+## References
+
+- [Docs: About Integration Service Activities](https://docs.uipath.com/activities/other/latest/integration-service/about-the-integration-service-activities)

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/file-handling.md

@@ -0,0 +1,38 @@
+---
+confidence: medium
+---
+
+# File Handling Issues
+
+## Context
+
+What this looks like:
+- "Attachment not found"
+- File inputs not working or not passed correctly between tasks
+- Files not appearing in the debug input panel
+
+What can cause it:
+- File inputs defined as variables instead of arguments — files must be passed as arguments to appear in the debug input panel
+- Job retention policy deleting the job that owns an attachment (see [attachment-not-found](attachment-not-found.md) for retention-specific cases)
+- Box connector "Update Variables" option not saving the source value in XML for File types (frontend bug in IntsvcActivityConfig v2)
+- File type incompatibility between ILocalResource (Studio Desktop) and File (Studio Web) with newer agent expectations
+- Robot version incompatibility — older Robot versions do not produce File objects with metadata that agents expect
+
+What to look for:
+- Check if files are defined as arguments or variables
+- Check Robot version compatibility
+- Check if the issue is in debug, deployed, or both
+
+## Investigation
+
+1. Check if file inputs are defined as arguments (not variables) in the BPMN process
+2. Check Robot version against Studio Web requirements
+3. For Box connector: check if the "Update Variables" XML contains the correct source value for File types
+4. Check if the file is being passed between tasks or downloaded from an external source (Data Fabric, storage bucket)
+
+## Resolution
+
+- **If variable vs argument:** change file inputs to arguments instead of variables
+- **If version mismatch:** upgrade Robot to the latest version
+- **If Box connector bug:** manually fix the XML source value as a workaround
+- **If file passing between tasks:** redesign to download files from source (e.g., Data Fabric) in each task instead of passing file references

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/folder-not-accessible.md

@@ -0,0 +1,46 @@
+---
+confidence: high
+---
+
+# Folder Does Not Exist or No Access (400, #1100)
+
+## Context
+
+What this looks like:
+- HTTP 400 (sometimes 403) from Orchestrator surfaced by Maestro
+- Error message: `Operation returned invalid status code '400'. Folder does not exist or the user does not have access to the folder.`
+- Orchestrator error code `#1100`
+
+What can cause it:
+- Robot/user account is not assigned to the target folder
+- Folder name contains characters Maestro's folder-path resolver historically chokes on — e.g., commas (`"Autopilot, Agentic, and Gen AI"` triggered `PLT-82739`)
+- Folder was renamed or deleted; bindings still reference the old path or key
+- Solution imported across environments (staging → alpha) where folder keys differ — keys were baked into the solution
+- API call missing or pointing the `X-UIPATH-OrganizationUnitId` header at the wrong folder
+- Modern folder permissions missing at tenant level (need both tenant-level access and folder-level role)
+
+What to look for:
+- `folderKey` in the incident — does it actually exist in Orchestrator?
+- Whether the folder name contains commas or other unusual characters
+- Whether the solution was recently imported from another environment
+
+## Investigation
+> Substitute `<type>` with `bpmn`, `flow`, or `case` per the [Maestro investigation guide](../investigation_guide.md) § Determine the Maestro process type.
+
+1. Get the incident: `uip maestro <type> instance incidents <instance-id> -f <folder-key> --output json`
+2. Verify the folder exists: `uip or folders list --output json` — search by `Key`
+3. List users on that folder: `uip or users list-in-folder --folder-key <folder-key> --output json` — is the robot account assigned?
+4. Check the underlying bindings — request `bindings_v2.json` (deployed) or `debug_overwrites.json` (debug)
+5. If the folder contains commas in its name, suspect the historical path-resolver bug
+
+## Resolution
+
+- **If user/robot not assigned:** assign with the appropriate role at Orchestrator → **Folder > Manage Access > Assign**
+- **If folder name contains comma:** rename the folder to remove the comma; re-publish so bindings refresh
+- **If solution cross-imported:** update bindings to the destination folder keys; re-deploy
+- **If API call:** include the correct `X-UIPATH-OrganizationUnitId` header
+- **If modern folder permissions:** ensure tenant-level access AND folder-level role for the account
+
+## References
+
+- [Forum: Error code #1100](https://forum.uipath.com/t/folder-does-not-exist-or-the-user-does-not-have-access-to-the-folder-error-code-1100/541536)

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/foreground-unattended-robot.md

@@ -0,0 +1,46 @@
+---
+confidence: high
+---
+
+# Foreground Job Requires Unattended Robot (409, #1230)
+
+## Context
+
+What this looks like:
+- HTTP 409 from Orchestrator surfaced by Maestro
+- Error message: `Operation returned invalid status code '409'. Foreground job requires an unattended robot to be defined on your user`
+- Orchestrator error code `#1230`
+
+What can cause it:
+- The user triggering a foreground (UI-interactive) unattended job has no unattended robot configured
+- Underlying RPA project is a Studio (desktop) project running in **My Workspace**, which doesn't allow assigning bots/machines
+- User has Unattended runtime license at tenant level but no machine credentials configured
+- Debug-only manifestation — deployed flows running under a different identity work fine
+
+What to look for:
+- Whether the underlying RPA project is Studio (desktop, `.xaml`) or Studio Web (Agentless/Serverless)
+- Whether the folder is "My Workspace" vs a standard folder
+- Whether the user has unattended machine credentials configured
+
+## Investigation
+
+> Substitute `<type>` with `bpmn`, `flow`, or `case` per the [Maestro investigation guide](../investigation_guide.md) § Determine the Maestro process type.
+
+
+1. Get the incident: `uip maestro <type> instance incidents <instance-id> -f <folder-key> --output json`
+2. Confirm the user has Unattended Robot enabled: Orchestrator UI → **Tenant > Manage Access > Users** → select user → license tab
+3. Check that machine credentials are set (domain\username + password)
+4. Confirm the folder type — "My Workspace" cannot host unattended robots
+5. Identify the underlying RPA project type from the service task's binding
+
+## Resolution
+
+- **If user lacks Unattended enabled:** enable "Unattended Robot" on the user and assign valid machine credentials
+- **If running from My Workspace:** move the process to a standard folder where unattended bots can be assigned
+- **If Studio (desktop) project:** rebuild in Studio Web so the workflow runs on Agentless/Serverless and no unattended bot is needed
+- **If runtime license missing:** assign an Unattended runtime license to the user
+- **If debug-only and deployed works:** debug runs under the user's identity, deployed under the robot's — provision an unattended robot on the user, or run via deployed mode
+
+## References
+
+- [Forum: Error #1230](https://forum.uipath.com/t/foreground-job-requires-an-unattended-robot-to-be-defined-on-your-user-1230/718082)

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/gateway-no-outgoing-flow.md

@@ -0,0 +1,54 @@
+---
+confidence: high
+---
+
+# No Outgoing Flow Condition Met (400001)
+
+## Context
+
+What this looks like:
+- HTTP 400, Maestro error code `400001` (`NoOutgoingFlow`)
+- Error message: `No condition for an outgoing flow was met. At least one outgoing flow condition needs to evaluate to true or have a default flow.`
+- Always raised by an Exclusive or Inclusive Gateway
+
+What can cause it:
+- All outgoing sequence flow conditions evaluated to `false` and no default flow was configured
+- Variable ID mismatch — designer-side bug where renaming a variable leaves expressions bound to the old variable ID, so they read the wrong value
+- Boolean variable populated via Actionable Messages (email approval) arriving in an unexpected shape
+- Condition expressions reference a variable that is uninitialized on some execution paths
+
+What to look for:
+- The gateway name in `errorDetails` and the variables it depends on
+- Whether a default flow is configured on the gateway in the BPMN XML
+- Whether any variable was renamed recently in Studio Web
+
+## Investigation
+
+> Substitute `<type>` with `bpmn`, `flow`, or `case` per the [Maestro investigation guide](../investigation_guide.md) § Determine the Maestro process type.
+
+
+1. Get the incident: `uip maestro <type> instance incidents <instance-id> -f <folder-key> --output json`
+2. **If `IncludeGatewayDebugInfoInIncidents` is enabled** ([PO.BpmnEngine PR #3092](https://github.com/UiPath/PO.BpmnEngine/pull/3092)): `errorDetails` already lists each outgoing flow's condition expression, the default flow config, and variable values at evaluation time — no further data gathering needed
+3. **If the flag is not enabled:** pull the BPMN XML to read gateway conditions: `uip maestro <type> instance asset <instance-id> -f <folder-key> --output json`
+4. Pull the variables snapshot just before the gateway element: `uip maestro <type> instance variables <instance-id> -f <folder-key> --parent-element-id <gateway-id> --output json`
+5. Walk element executions to confirm which gateway: `uip maestro <type> instance element-executions <instance-id> -f <folder-key> --output json`
+
+## Resolution
+
+- **If no default flow:** add a default flow on the gateway in the BPMN modeler — set one outgoing sequence flow as the default; this path is taken when no conditions match
+- **If conditions are not exhaustive:** broaden the conditions to cover all possible runtime values
+- **If variable ID mismatch after rename:** open the gateway in Studio Web and **re-select** the correct variable in each condition expression; do not just retype the name
+- **If variable is uninitialized on some paths:** assign a default earlier in the flow so the variable is always defined before reaching the gateway
+- **If actionable messages payload:** verify the boolean comes back in the expected shape; consider routing through Action Center if Actionable Messages keeps yielding unexpected values
+
+## Notes
+
+- Pre-PR #3092: this error is **Not Troubleshootable** from PIMS API alone — agents had to ask the user for the `.bpmn` and walk variables manually
+- Post-PR #3092 with the targeted feature flag enabled: this error is **Fully Troubleshootable** — incident `errorDetails` contains everything needed
+- Variable values in enriched `errorDetails` are truncated to 200 chars per variable
+
+## References
+
+- [PR #3092 — Enrich NoOutgoingFlow incident with gateway debug info](https://github.com/UiPath/PO.BpmnEngine/pull/3092)
+- [Docs: Gateways and Flow Logic](https://docs.uipath.com/maestro/automation-cloud/latest/user-guide/gateways-flow-logic)
+- [Docs: Gateways](https://docs.uipath.com/maestro/automation-cloud/latest/user-guide/gateways)

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/generic-error-400.md

@@ -0,0 +1,51 @@
+---
+confidence: low
+---
+
+# Generic Error_400 — Bad Request With No Details
+
+## Context
+
+What this looks like:
+- Error code: `400`, error name: `Error_400` (no specific name)
+- Incident `errorDetails` is empty or non-actionable
+- API data alone is not enough to root-cause — must inspect upstream response body
+
+What can cause it:
+- Malformed JSON payload
+- Request headers too long (HA setups with mismatched token-signing certs)
+- Invalid `Content-Type` (must be `application/json`)
+- Expired auth token
+- Maestro frontend bug — historically `MST-4535` "actionable messages" feature surfaced as generic 400 when a new app version was available
+
+What to look for:
+- Whether actionable messages toggle is enabled on the failing app — if yes, this is the known frontend bug
+- Whether the workflow uses a custom HTTP request task with hand-crafted headers/body
+- Whether the issue is tied to a specific HA tenant
+
+## Investigation
+
+> Substitute `<type>` with `bpmn`, `flow`, or `case` per the [Maestro investigation guide](../investigation_guide.md) § Determine the Maestro process type.
+
+
+1. Get the incident: `uip maestro <type> instance incidents <instance-id> -f <folder-key> --output json` — capture any HTTP body returned upstream
+2. Pull the activity inputs to see what was actually sent: `uip maestro <type> instance variables <instance-id> -f <folder-key> --output json`
+3. If the failing element is an Action App task with actionable messages enabled, jump straight to the `MST-4535` resolution
+4. For HA setups, request platform logs from the Maestro service — generic 400 here often points to token-signing certificate mismatch across nodes
+
+## Resolution
+
+- **If actionable messages bug (`MST-4535`):** turn OFF the "Enable actionable messages" toggle on the Action App task. Frontend fix is deployed to disable by default — re-publish to pick it up
+- **If malformed JSON:** validate the payload structure
+- **If Content-Type:** set `application/json`
+- **If expired token:** rotate the auth token and retry
+- **If HA token-signing mismatch:** sync the token-signing certificates across all nodes (platform/infra owner)
+
+## Notes
+
+- This error is **Not Troubleshootable** from PIMS API alone — full root cause typically requires ADX logs or Temporal history
+- When the incident gives nothing useful, ask the user for the failing element name and whether they recently re-published the app
+
+## References
+
+- [Forum: 400 Bad Request](https://forum.uipath.com/t/400-bad-request/506399)