@uipath/skills 1.195.0 → 1.196.0

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/add-queue-item-failed.md

@@ -0,0 +1,58 @@
+---
+confidence: medium
+---
+
+# Add Queue Item Failed
+
+## Context
+
+`Add Queue Item` failed while pushing an item into an Orchestrator queue. The failure can be a
+client-side validation of the inputs, or an error returned by Orchestrator.
+
+What this looks like:
+- "\"Queue name\" may not be null or empty." — the queue name input was not set
+- An error about invalid characters in an item-information key — keys may not contain certain
+  characters (`.`, `#`, `@`, `:`)
+- "An item name from the '{0}' collection is the duplicate of another item name in the '{1}'
+  collection" — the same key appears in both the `ItemInformation` and the
+  `ItemInformationCollection`
+- An Orchestrator error: queue does not exist, permission denied, HTTP error, or a timeout
+
+What can cause it:
+- The `QueueName` input is empty or resolved to null from an unset variable/argument
+- A queue with that name does not exist in the folder where the job runs
+- The robot account lacks permission to create queue items in that folder
+- Item-information keys contain reserved characters, or the same key is supplied twice across the two
+  collections
+- Network/connectivity or session issues between the robot and Orchestrator, causing an HTTP error or
+  timeout
+
+What to look for:
+- The resolved `QueueName` and the folder the job runs in
+- The item-information keys being sent (reserved characters, duplicates)
+- The HTTP status / error text returned by Orchestrator, if any
+- Whether the queue exists in that folder and the robot account has rights to it
+
+## Investigation
+
+1. Identify the failing `Add Queue Item` and the resolved `QueueName` (from logs/variables).
+2. Confirm the queue exists in the Orchestrator folder where the job runs.
+3. If a validation error fired, inspect the named inputs: empty queue name, reserved characters in
+   keys, or a duplicate key across `ItemInformation` and `ItemInformationCollection`.
+4. If Orchestrator returned an error, read the HTTP status / message — distinguish permission denied,
+   not found, and timeout.
+5. Confirm the robot account is authenticated and has permission to add items in that folder.
+
+## Resolution
+
+- **If the queue name is empty:** set `QueueName` (ensure the upstream variable/argument that feeds it
+  is populated).
+- **If the queue doesn't exist in the job folder:** create it there, or run the job in the folder
+  where the queue is defined.
+- **If keys contain reserved characters:** rename the item-information keys to remove `.`, `#`, `@`,
+  `:`.
+- **If a key is duplicated across the two collections:** remove the duplicate so each key appears
+  once.
+- **If permission is denied:** grant the robot account permission to create queue items in that
+  folder.
+- **If it's a network/HTTP/timeout error:** address robot↔Orchestrator connectivity and retry.

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/application-launch-failed.md

@@ -0,0 +1,56 @@
+---
+confidence: medium
+---
+
+# Application Could Not Launch
+
+## Context
+
+`Open Application` (or `Open Browser` launching the browser executable) could not start the target
+application, so the scope had no window to attach to.
+
+What this looks like:
+- The activity fails at or shortly after launch, before any inner activity runs
+- A validation error "Both FileName and Arguments arguments are null. You should pass at least one of
+  them" (neither `FileName` nor `Arguments` was provided)
+- The application starts but never produces the expected window, so the scope's selector then fails
+  to attach
+
+What can cause it:
+- The executable / file path in `FileName` does not exist on the robot machine, or is a path that is
+  valid on the developer machine but not on the robot
+- Neither `FileName` nor `Arguments` is set
+- The arguments are malformed or the working directory is wrong, so the process exits immediately
+- The application requires elevation/permissions the robot account does not have
+- The app launches a splash/loader and the real window appears later than the scope expects, or under
+  a different selector than configured
+- The application is already running in a mode that prevents a second instance from starting
+
+What to look for:
+- The exact `FileName`, `Arguments`, and selector configured on the activity
+- Whether that executable path exists on the robot machine (not just the dev machine)
+- Whether a process actually started (and immediately exited) vs. never started
+- Whether the scope selector matches the window the app actually shows
+
+## Investigation
+
+1. Read the `FileName`, `Arguments`, and the scope selector from the failing activity.
+2. Confirm the executable/file path exists and is launchable on the robot machine and account.
+3. Confirm at least one of `FileName` / `Arguments` is set (the validation error fires when both are
+   empty).
+4. Launch the application manually with the same path/arguments on the robot machine to see whether
+   it starts and what window it produces.
+5. Compare the window the app actually shows against the scope selector — confirm they match.
+6. Check whether the app needs elevation or is blocked by policy/AV on the robot machine.
+
+## Resolution
+
+- **If the path is missing/incorrect on the robot:** correct `FileName` to a path valid on the robot
+  machine, or ensure the application is installed there.
+- **If both FileName and Arguments are empty:** set at least one so the activity has something to
+  launch.
+- **If arguments/working directory are wrong:** fix them so the process starts and stays running.
+- **If the window appears later or under a different selector:** point the scope selector at the
+  window the app actually produces, and wait for that window rather than racing the cold start.
+- **If elevation/permissions are missing:** grant the robot account what the app requires, or launch
+  it through a supported elevated mechanism.

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/browser-open-or-attach-failed.md

@@ -0,0 +1,59 @@
+---
+confidence: medium
+---
+
+# Browser Could Not Open or Attach
+
+## Context
+
+A classic browser activity failed to open, attach to, or close a browser, throwing a browser
+operation error (`BrowserOperationException`) or an invalid-browser error. Applies to `Open Browser`,
+`Attach Browser` (Browser Scope), and `Close Tab`.
+
+What this looks like:
+- `BrowserOperationException`, or an error indicating the browser is invalid / not available
+- `Open Browser` fails to start the browser, or starts it but the automation cannot communicate with
+  it
+- `Close Tab` / `Attach Browser` fails because there is no live browser to act on
+
+What can cause it:
+- The selected browser is not installed on the robot machine, or is a different major version than
+  expected
+- The UiPath browser extension is missing, disabled, or not allowed by browser/enterprise policy
+- The browser type does not match the communication method (e.g. a custom browser, or WebDriver,
+  used with an unsupported browser)
+- The browser process crashed, was closed by the user/another step, or never finished launching
+- `Attach Browser`/`Close Tab` run against a browser that is no longer open (a previous step closed
+  it, or it was never opened in this execution)
+- Profile/user-data conflicts prevent a new browser instance from starting
+
+What to look for:
+- Which browser and communication method the activity is configured for
+- Whether that browser is installed and the UiPath extension is enabled on the robot machine
+- Whether a browser instance was actually open and still alive when the failing activity ran
+- Whether the same workflow opened the browser earlier and whether that open succeeded
+
+## Investigation
+
+1. Identify the failing activity and its configured browser type and communication method.
+2. Confirm the browser is installed on the robot machine and note its version.
+3. Verify the UiPath browser extension is installed and enabled for that browser, and not blocked by
+   policy.
+4. For `Attach Browser`/`Close Tab`, trace back to where the browser was opened — confirm it opened
+   successfully and was still alive at the point of failure.
+5. Check for browser/communication-method incompatibility (custom browser, or WebDriver, with an
+   unsupported browser type) — see [ui-activity-configuration-error.md](./ui-activity-configuration-error.md).
+6. Check robot logs / event log for a browser crash around the failure time.
+
+## Resolution
+
+- **If the browser is not installed or wrong version:** install/repair the supported browser version
+  on the robot machine.
+- **If the extension is missing/disabled/blocked:** install and enable the UiPath browser extension;
+  allow it through browser or enterprise policy.
+- **If `Attach`/`Close` ran with no live browser:** fix the flow so the browser is opened (and its
+  open verified) before attaching or closing; handle the case where a prior step closed it.
+- **If the browser crashed mid-run:** address the crash cause (resources, conflicting profile,
+  incompatible version) and re-open the browser cleanly.
+- **If browser type and communication method are incompatible:** correct the configuration per
+  [ui-activity-configuration-error.md](./ui-activity-configuration-error.md).

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/file-operation-failed.md

@@ -0,0 +1,60 @@
+---
+confidence: medium
+---
+
+# File Operation Failed — Rename / Move / Append
+
+## Context
+
+A classic file-system activity (`Rename File`, `Move File`, or `Append Line`) faulted while acting on
+a path. These activities run on the robot machine's file system and surface a file-system error.
+
+What this looks like:
+- "The source file does not exist." (`Rename File` / `Move File` — the source path is wrong or gone)
+- "Destination should be a folder." (`Move File` — the destination must be a folder, but a file path
+  was given)
+- "File cannot be null" (an empty/unresolved path argument)
+- Standard .NET I/O errors: file already exists at the destination, access denied
+  (`UnauthorizedAccessException`), the path is a directory, the file is locked by another process, or
+  the path is too long
+
+What can cause it:
+- The path is valid on the developer machine but does not exist on the robot machine (different
+  drives, user folders, or mapped network drives)
+- The source file was never created, or a previous step that should have produced it failed
+- A path variable resolved to empty/null because an upstream assignment or input was missing
+- The destination already contains a file with the same name and overwrite is not enabled
+- The robot account lacks read/write permission on the folder, or the file is open/locked by another
+  application
+- For `Append Line`: an invalid encoding name, or the target file/folder is not writable
+
+What to look for:
+- The exact source and destination paths the activity resolved at run time (from logs/variables)
+- Whether those paths exist and are reachable on the robot machine, with the right permissions
+- Whether the destination is a folder (for `Move File`) vs a file path
+- Whether the file is held open by another process
+
+## Investigation
+
+1. Identify the failing file activity and the exact paths it used at run time (resolve any variables
+   from logs).
+2. Check the error text to classify it: source missing, destination-not-a-folder, null path, already
+   exists, access denied, or locked.
+3. Verify the source path exists on the robot machine and the robot account can read it.
+4. Verify the destination: for `Move File`, confirm it is a folder; check whether a same-named file
+   already exists there.
+5. Confirm the robot account has write permission to the destination folder and that the file is not
+   open in another process.
+6. If a path variable was empty, trace back to the upstream step/input that should have set it.
+
+## Resolution
+
+- **If the source file does not exist:** fix the source path, or fix the upstream step that should
+  have created it; do not point the activity at a path that isn't there on the robot.
+- **If the destination should be a folder:** give `Move File` a destination folder, not a file path.
+- **If a path is null/empty:** ensure the upstream assignment/input that feeds the path is set.
+- **If the destination already has the file:** enable overwrite if that is intended, or change the
+  destination/name.
+- **If access is denied:** grant the robot account read/write permission on the path.
+- **If the file is locked:** ensure no other process (or earlier step) is holding it open before the
+  operation.

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/foreach-row-failed.md

@@ -0,0 +1,56 @@
+---
+confidence: low
+---
+
+# For Each Row Failed
+
+## Context
+
+`For Each Row` (iterating a DataTable) faulted. The fault is usually not in the loop construct itself
+but in the data it iterates or in an activity inside the loop body. `Log Message` rarely faults on
+its own; when it appears in a stack it is normally relaying an error from elsewhere — investigate the
+surrounding activity rather than the log call.
+
+What this looks like:
+- The loop throws at the start (before iterating) — typically a null/uninitialized DataTable
+- A design-time validation error about the iterator (`CurrentRow`) variable name
+- The loop runs and then throws on a particular row — the real error is an activity inside the body
+  acting on that row's data
+
+What can cause it:
+- The DataTable is null/uninitialized because an upstream step (Read Range, Build Data Table, a query)
+  did not produce it
+- The iterator variable name is invalid (empty, starts with a digit, or contains characters other
+  than letters/digits/underscore)
+- An activity inside the loop body throws on a specific row — a missing/empty column value, a failed
+  type conversion, an out-of-range access, or a downstream activity (UI, file, queue, etc.) failing
+
+What to look for:
+- Whether the DataTable passed to the loop was actually populated upstream
+- Which iteration/row the failure occurred on (first row → setup/data problem; a later row →
+  row-specific data)
+- The innermost exception and which body activity raised it
+
+## Investigation
+
+1. Confirm the DataTable input is non-null and populated — trace the upstream step that builds/reads
+   it.
+2. If a validation error names the iterator variable, check the `CurrentRow` variable name against
+   the naming rules.
+3. Determine which row the failure happened on (fails immediately → setup/data; fails after some
+   iterations → that row's data).
+4. Read the innermost exception and identify which activity inside the body threw, then switch to
+   that activity's signature/playbook.
+5. Inspect the offending row's values (missing/empty columns, unexpected types) against what the body
+   activities assume.
+
+## Resolution
+
+- **If the DataTable is null:** fix the upstream step so it produces a populated DataTable before the
+  loop.
+- **If the iterator name is invalid:** rename `CurrentRow` to a valid identifier (letters/digits/
+  underscore, not starting with a digit).
+- **If a body activity throws on a row:** diagnose that activity with its own playbook; handle the
+  bad row's data (validate/convert columns, guard missing values).
+- **If certain rows are expected to be incomplete:** validate/skip them explicitly inside the loop
+  rather than letting the body throw.

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/image-target-not-found.md

@@ -0,0 +1,56 @@
+---
+confidence: medium
+---
+
+# Image Target Not Found / Did Not Vanish
+
+## Context
+
+A classic image-based activity did not behave as expected. The most common case is `Wait Image
+Vanish`: either the image was never matched on screen, or it was still present when the timeout
+expired (which surfaces as `ActivityTimeoutException` / "Activity timeout exceeded"). Image matching
+compares a captured bitmap against the live screen, so it is sensitive to any rendering difference.
+
+What this looks like:
+- `Wait Image Vanish` times out because the image is still detected on screen
+- An image is never matched even though a human can see it
+- The behavior differs between the developer machine and the robot machine, or between runs
+
+What can cause it:
+- Display scaling / DPI differs between design time and run time, so the captured image no longer
+  matches pixel-for-pixel
+- Screen resolution, color depth, theme (light/dark), or font rendering differs on the robot machine
+- The underlying operation the image represents never completed, so the image genuinely never
+  vanishes (the wait is correctly reporting a stuck state)
+- The robot session is locked or in a disconnected RDP session, so the screen does not render
+- The accuracy/similarity threshold is too strict for the small rendering differences present
+- Anti-aliasing, transparency, or animation makes the region unstable frame to frame
+
+What to look for:
+- Whether the robot machine's display scaling, resolution, and theme match where the image was
+  captured
+- Whether the session was interactive and unlocked during the run
+- Whether the image genuinely should have vanished (did the underlying operation finish?)
+- Whether the same step works on the developer machine but not the robot
+
+## Investigation
+
+1. Confirm the activity is image-based and what it is waiting for (image to vanish / to be matched).
+2. Compare the robot machine's display scaling, resolution, color depth, and theme against the
+   environment where the image was captured.
+3. Verify the robot session was interactive and unlocked at run time.
+4. Determine whether the underlying operation that should make the image vanish actually completed.
+5. If matching is flaky, review the configured accuracy/similarity threshold against the rendering
+   differences observed.
+
+## Resolution
+
+- **If display scaling/resolution/theme differ:** align the robot machine's display settings with the
+  capture environment, or re-capture the image on the robot machine.
+- **If the session was locked/disconnected:** run the process in an interactive, unlocked session.
+- **If the underlying operation never finished:** fix that operation — the image not vanishing is a
+  correct symptom of the real problem, not an image-matching fault.
+- **If matching is too strict for minor rendering differences:** adjust the accuracy/similarity
+  threshold to a realistic value, or select a more stable image region.
+- Prefer selector-based automation over image-based where the application supports it, since image
+  matching is inherently environment-sensitive.

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/invoke-code-failed.md

@@ -0,0 +1,54 @@
+---
+confidence: medium
+---
+
+# Invoke Code Failed
+
+## Context
+
+`Invoke Code` failed either to compile the supplied snippet or while running it. The activity
+compiles the code (C#/VB) before execution, so failures split into compile-time and run-time.
+
+What this looks like:
+- A compilation error listing the offending line(s) in the snippet
+- "No compiled code to run" — there was no successfully compiled code to execute
+- An error that the language is not supported in the current runtime
+- A run-time exception thrown by the snippet itself (e.g. a null reference, an index out of range, an
+  external call failing)
+
+What can cause it:
+- Syntax errors in the snippet, or references to types/namespaces not imported in the project
+- An argument referenced in the snippet whose name/type/direction does not match the `Arguments`
+  defined on the activity
+- A language selected that the current runtime/project does not support
+- Missing assembly/namespace imports for the APIs the snippet uses
+- The snippet compiles but throws at run time because of the data it operates on or an external
+  dependency it calls
+
+What to look for:
+- The full compiler error text and the line it points to
+- The `Arguments` defined on the activity vs the identifiers used in the snippet
+- The project's imported namespaces/references vs what the snippet needs
+- Whether the failure is at compile time (before any logic runs) or at run time (a thrown exception)
+
+## Investigation
+
+1. Read the error: distinguish a compilation failure ("No compiled code to run" / compiler errors)
+   from a run-time exception thrown by the snippet.
+2. For compilation errors, locate the line the compiler names and the missing type/namespace or
+   syntax problem.
+3. Compare the snippet's referenced identifiers against the activity's `Arguments` (name, type,
+   direction) and against the project's imports/references.
+4. For run-time exceptions, identify which statement threw and what input/data it was operating on.
+5. Confirm the selected language is supported by the project/runtime.
+
+## Resolution
+
+- **If there are syntax/type errors:** fix the snippet syntax and add the required namespace
+  imports / assembly references in the project.
+- **If arguments don't match:** align the activity's `Arguments` with the identifiers, types, and
+  directions used in the snippet.
+- **If the language is unsupported:** switch to a language the runtime supports, or update the
+  project/runtime so the chosen language is available.
+- **If the snippet throws at run time:** fix the logic or guard the input/dependency it failed on,
+  the same as you would for any runtime exception in workflow code.

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/invoke-workflow-failed.md

@@ -0,0 +1,58 @@
+---
+confidence: medium
+---
+
+# Invoke Workflow / Start Triggers Failed
+
+## Context
+
+`Invoke Workflow File` (or `Start Triggers`, which invokes a workflow) faulted. The failure can be in
+locating the workflow, in passing arguments, in the session/isolation configuration, or inside the
+invoked child workflow itself.
+
+What this looks like:
+- The invoked workflow file cannot be found or loaded at run time
+- An argument mismatch — the arguments passed do not match the invoked workflow's argument names,
+  types, or directions
+- A validation error about isolated / elevated / target-session settings (e.g. a non-current target
+  session or elevated execution requires isolated execution)
+- An error that persistence is not supported in the current runtime
+- The child workflow ran and threw its own exception, which propagates up through the invoke
+
+What can cause it:
+- The workflow file path is wrong on the robot machine, or the `.xaml` was not published/included in
+  the package
+- Argument names/types/directions drifted between the caller and the invoked workflow (a renamed or
+  retyped argument)
+- Isolated/elevated/target-session options set in a combination the runtime does not allow
+- A `Start Triggers` placed somewhere other than directly inside a `Sequence` (its parent constraint)
+- The real error is inside the child workflow — the invoke is just the propagation point
+
+What to look for:
+- The invoked workflow path and whether it exists in the published package on the robot
+- The argument list on the invoke vs the invoked workflow's declared arguments
+- The isolated/elevated/target-session settings on the invoke
+- Whether the stack/inner exception points inside the child workflow rather than the invoke itself
+
+## Investigation
+
+1. Identify the invoke activity and the workflow file it targets; confirm that file is present in the
+   running package on the robot.
+2. Compare the arguments passed against the invoked workflow's declared arguments (name, type,
+   direction).
+3. Inspect the isolated / elevated / target-session settings for an unsupported combination.
+4. For `Start Triggers`, confirm it sits directly inside a `Sequence`.
+5. Read the inner/innermost exception — if it originates inside the child workflow, switch the
+   investigation to that activity/playbook.
+
+## Resolution
+
+- **If the workflow file is missing:** correct the path, or ensure the `.xaml` is included in the
+  published package.
+- **If arguments mismatch:** align the invoke's arguments with the invoked workflow's declared
+  arguments (names, types, in/out directions).
+- **If isolated/elevated/session settings are invalid:** set a supported combination (e.g. enable
+  isolated execution when required by elevated/non-current-session options).
+- **If `Start Triggers` has the wrong parent:** place it directly inside a `Sequence`.
+- **If the child workflow threw:** diagnose the failing activity inside the child workflow using its
+  own signature/playbook; the invoke is only relaying the error.

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/kill-process-failed.md

@@ -0,0 +1,49 @@
+---
+confidence: low
+---
+
+# Kill Process Failed
+
+## Context
+
+`Kill Process` failed while trying to terminate one or more processes on the robot machine.
+
+What this looks like:
+- "Encountered errors while trying to kill a process" — one or more matched processes could not be
+  terminated
+- The activity targeted a process name or process object that no longer exists, or that the robot
+  account is not allowed to terminate
+
+What can cause it:
+- No process matching the given name was running (already exited, or the name/case is wrong)
+- The robot account lacks the privilege to terminate the process (a process owned by another user, a
+  service, or a protected/system process)
+- Several processes matched the name and at least one of them failed to terminate, so the errors are
+  reported together
+- The process is in a state where it cannot be killed immediately (hung, being debugged)
+
+What to look for:
+- The process name or process object the activity targeted
+- Whether such a process was actually running at that moment, and under which user
+- Whether multiple instances matched
+- Whether `ContinueOnError` is set (which would suppress these failures)
+
+## Investigation
+
+1. Identify the target process name/object on the failing `Kill Process`.
+2. Determine whether a matching process was running when the activity executed, and under which user
+   account.
+3. Check whether multiple instances matched and whether only some failed to terminate.
+4. Confirm whether the robot account has rights to terminate that process (own user vs another user /
+   service / protected process).
+
+## Resolution
+
+- **If no matching process was running:** guard the kill (only kill when present), or accept that
+  there was nothing to terminate; check the name/case is correct.
+- **If access is denied:** run with an account that has privilege to terminate the process, or target
+  only processes the robot account owns.
+- **If some of several instances failed:** handle each instance, or narrow the target so it matches
+  only the intended process.
+- **If the goal is best-effort cleanup:** consider whether `ContinueOnError` is appropriate so a
+  non-critical kill does not fault the workflow — but only when the termination is genuinely optional.

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/ui-activity-configuration-error.md

@@ -0,0 +1,80 @@
+---
+confidence: high
+---
+
+# UI Activity Configuration Error — Invalid Property Combination
+
+## Context
+
+A classic UI activity failed validation because of an invalid combination of properties — not a
+runtime/element problem. These surface as a validation error in Studio (red icon) or as an
+`ArgumentException` at the very start of the activity, before any element is touched.
+
+What this looks like:
+- "Only one of the {0} and {1} options can be set." — two mutually-exclusive options are both
+  enabled (for example `SimulateClick`/`SimulateType` together with `SendWindowMessages` on `Click`
+  or `Type Into`)
+- A scope validation error stating that both a `Selector` and a `Browser`/`Window` were provided, or
+  that neither was provided, on `Attach Browser` / `Attach Window`
+- An `Open Browser` validation error about the communication method (e.g. WebDriver is only available
+  for certain browsers, or a custom browser requires WebDriver)
+- A leaf activity reports `ElementNotSetException` / "The target Element was not specified for this
+  activity" (often `---> UninitializedNodeException: The UiElement is not initialized`) at
+  `Target.FindByElement` / `ValidateSearchArgs` — yet the leaf's OWN `Selector` is set. Here the leaf
+  is the symptom; the originating fault is the enclosing scope failing to produce a context window.
+- The activity fails immediately/identically on every run, regardless of the application state
+
+What can cause it:
+- Two input methods enabled at once (Simulate + Window Messages) on the same input activity
+- A scope activity given both an explicit `Browser`/`Window` object and a `Selector` (they are
+  alternatives, not both)
+- A scope given neither a `Browser`/`Window` nor a `Selector`
+- A scope given the WRONG selector shape for its type — e.g. a browser `html` selector
+  (`<html app='...' title='...' />`) on a desktop `Open Application`, or a desktop/`wnd` selector on a
+  browser scope — plus a null `ApplicationWindow`/`Browser`. The scope resolves no top-level window, so
+  its context-window `UiElement` is never initialized and every child activity faults upstream of its
+  own selector.
+- `SearchScope` set together with an explicit `Browser`/`Window` object
+- A communication method incompatible with the chosen browser type on `Open Browser`
+
+What to look for:
+- The full text of the validation/argument error — it names the two conflicting options
+- The relevant boolean/input-method properties and scope inputs on the failing activity
+
+## Investigation
+
+1. Read the validation/argument error message — it identifies the two conflicting options or the
+   incompatible setting by name.
+2. Open the failing activity's properties and inspect the named inputs (input-method booleans, or
+   `Selector` vs `Browser`/`Window`, or browser type vs communication method).
+3. Confirm the failure is configuration-driven: it reproduces identically every run and occurs before
+   any element interaction.
+4. If the faulting activity is a LEAF (Click, Type Into, …) reporting "no target" but its own
+   `Selector` IS set: read the enclosing scope. Check its selector shape vs. its type (browser `html`
+   vs. desktop/`wnd`) and whether `ApplicationWindow`/`Browser` is null. A stack that throws
+   `UninitializedNodeException` inside `Target.FindByElement` and surfaces at `ScopeActivity.OnFaulted`
+   means the uninitialized node is the SCOPE's context window, not the leaf's target.
+
+## Resolution
+
+- **If two input methods are both enabled:** disable one so only a single input method is active.
+- **If a scope has both a Selector and a Browser/Window:** keep one — either pass the
+  `Browser`/`Window` object or supply the `Selector`, not both.
+- **If a scope has neither:** provide one of them so the scope has a target.
+- **If the scope has the wrong selector shape for its type (uninitialized context window):** fix the
+  SCOPE, not the leaf. For a browser target use a browser scope (`Use Application/Browser`,
+  `Open Browser`, `Attach Browser`); for a desktop target give the `Open Application` a native
+  top-level-window selector plus a valid `ApplicationWindow`. Leave the leaf's intact selector alone.
+- **If SearchScope conflicts with an explicit Browser/Window:** remove `SearchScope` when passing the
+  object directly.
+- **If the browser type and communication method are incompatible:** choose a supported combination
+  (a communication method the selected browser supports, or a browser the method supports).
+
+## What to present
+
+When the fault is scope-side (leaf reported "no target" but the real cause is the enclosing scope),
+state the contrast explicitly so the user fixes the right node:
+- The leaf's OWN selector is intact/valid — do not change it.
+- The ORIGINATING fault is the scope failing to produce a context window; name the misconfigured scope
+  and its offending inputs (selector shape vs. type, null window).
+- The fix targets the scope. The leaf "no target" message is the downstream symptom, not the cause.

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/ui-activity-timeout.md

@@ -0,0 +1,61 @@
+---
+confidence: medium
+---
+
+# UI Activity Timeout — Element or State Never Reached
+
+## Context
+
+A classic UI Automation activity ran for its full timeout without the element or state it was
+waiting for ever being reached, and threw `ActivityTimeoutException`. This is the typical signature
+of `Wait UI Element Appear` (the element never appeared) and `Wait Image Vanish` (the image was
+still present when the timeout expired), but any classic UI activity can time out waiting for its
+target.
+
+What this looks like:
+- `ActivityTimeoutException`, or an error message such as "Activity timeout exceeded"
+- The activity's duration is very close to its configured timeout (default is typically 30 seconds)
+- For `Wait UI Element Appear`: the awaited element never showed up
+- For `Wait Image Vanish`: the on-screen image never disappeared
+
+What can cause it:
+- The awaited element/state genuinely never occurs (the preceding action didn't take effect, the
+  page/dialog never opened, the long-running operation never finished)
+- The expected change happens later than the configured timeout (the timeout is too short for the
+  real workload)
+- For `Wait Image Vanish`: the image never vanishes because the underlying operation is stuck, or the
+  matched image is slightly different from what's on screen so the match logic behaves unexpectedly
+- The robot session is locked or in a disconnected RDP session, so the UI does not render/update
+- An upstream step that should have triggered the change failed silently
+
+What to look for:
+- Is the faulted activity actually a UI automation type? `ActivityTimeoutException` can also come from
+  non-UI waits — confirm the activity before applying this playbook
+- Is the duration within 1–2 seconds of the configured timeout (genuine timeout) vs. failing early
+  (different problem)?
+- Is it consistent or intermittent? Intermittent points to timing/load; consistent points to a
+  state that never occurs
+- Was the robot session interactive and unlocked during the run?
+
+## Investigation
+
+1. Confirm the faulted activity is a classic UI activity and note its timeout value.
+2. Compare the activity duration against the timeout to confirm it waited the full window.
+3. Determine what the activity was waiting for (which element to appear, which image to vanish) and
+   verify from logs/screenshots whether that change ever happened.
+4. Check the upstream step that should have caused the change — confirm it actually executed and took
+   effect.
+5. Confirm the robot session was interactive and unlocked (locked/disconnected sessions stop the UI
+   from updating).
+6. If intermittent, correlate failures with system load or slower-than-usual application responses.
+
+## Resolution
+
+- **If the awaited change never happens because an upstream step didn't take effect:** fix the
+  upstream step; the wait is correctly reporting that the expected state never arrived.
+- **If the workload is genuinely slower than the timeout:** raise the timeout to a realistic value
+  for the real workload — but only after confirming the change does eventually occur.
+- **If the session was locked/disconnected:** run the process in an interactive, unlocked session.
+- **If `Wait Image Vanish` never matches what's on screen:** verify the captured image still matches
+  the current UI (scaling, resolution, theme); see [image-target-not-found.md](./image-target-not-found.md).
+- Do not raise the timeout blindly — establish that the element/state can occur at all first.