@uipath/skills 1.196.0 → 1.197.0

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/append-text-missing-container.md

@@ -0,0 +1,31 @@
+---
+confidence: high
+---
+
+# Append Text — "Activity is valid only inside WordApplicationScope"
+
+## Context
+
+What this looks like:
+- The App-Integration **`Append Text`** activity (`UiPath.Word.Activities.WordAppendText`) shows a **design-time validation error** / faults with `Activity is valid only inside WordApplicationScope` (or "must be placed inside a Use Word File")
+- The error fires before any text is appended
+
+What can cause it:
+- The App-Integration `Append Text` has **no file input of its own** — it appends to the document held open by a surrounding `Word Application Scope` / `Use Word File`. Dropped **outside** that container, it is invalid.
+
+What to look for:
+- Whether the `Append Text` node sits inside a `Word Application Scope` / `Use Word File` in the `.xaml`, or loose in the sequence.
+- Whether it's the **App-Integration** `Append Text` (needs a container) or the **standalone** `Append Text` under the **Word Document** category (takes its own file path).
+
+## Investigation
+
+1. Read the workflow `.xaml`. Confirm the `Append Text` node is the App-Integration activity and whether it is nested inside a `Word Application Scope` / `Use Word File`.
+2. Note whether the failure is design-time (validation) or runtime invalid-context — both point at the same missing-container cause.
+
+## Resolution
+
+- **Append to an open document** — place the `Append Text` activity **inside** a `Word Application Scope` (or `Use Word File`) that opens the target document, strictly within its **Do** body. The activity then appends to the container's open document.
+- **Append without a scope / without opening MS Word** — use the standalone **`Append Text`** under the **Word Document** category instead, which takes the **file path directly** in its own properties (no container, no Word install needed).
+- **Pick the surface deliberately** — App-Integration `Append Text` (scoped, Interop) for workflows already inside a Word scope; standalone Word Document `Append Text` for a one-off append by path.
+
+> Same container-vs-standalone pattern as [read-text-missing-container.md](./read-text-missing-container.md) — the App-Integration Word activities need a scope; the Word Document ones take a path.

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/append-text-zero-byte-file.md

@@ -0,0 +1,32 @@
+---
+confidence: medium
+---
+
+# Append Text — "Archive file cannot be size zero"
+
+## Context
+
+What this looks like:
+- `Append Text` (`UiPath.Word.Activities.WordAppendText`) — or the surrounding scope opening the document — faults with `Archive file cannot be size zero` (or a similar OpenXML/ZIP "cannot open / not a valid package" error)
+- The target `.docx`/`.doc` exists but is **0 bytes**
+
+What can cause it:
+- A `.docx` is a ZIP/OpenXML package and **must contain internal XML structures**. A **0-byte file** — typically created by *New → Text Document* then renaming the extension to `.docx`, or left behind by a failed/truncated download or interrupted write — is not a valid Word archive, so the open/append fails.
+
+What to look for:
+- The size of the target file on disk (0 bytes is the tell).
+- Whether the file was hand-created by renaming a `.txt`, or produced by an upstream download/write that may have failed.
+
+## Investigation
+
+1. Read the `Append Text` / scope node and resolve the target document path.
+2. Check the file size at that path on the execution host (ask the user / someone with host access if off-host). A 0-byte file is the cause.
+3. Determine how the file got there — a manually renamed empty file vs a truncated upstream output — so the fix addresses the source.
+
+## Resolution
+
+- **If the file is a hand-made empty placeholder** — delete the 0-byte file and let UiPath generate a valid template: check **Create if not exists** in the `Word Application Scope` properties (or use a real `.docx` saved from Word). On the next run the scope creates a structurally valid file.
+- **If the 0-byte file came from a failed upstream step** (download/write produced an empty file) — fix that step so it writes a complete `.docx`, and add a guard (check file size > 0) before appending.
+- **Never fabricate a `.docx` by renaming a `.txt`** — a true Word file needs the OpenXML package structure; the extension alone is not enough.
+
+> Distinct from a *corrupt-but-non-empty* document (orphaned-lock / half-written) — see [word-scope-file-corrupted.md](./word-scope-file-corrupted.md). The `Create if not exists` option is the same one covered in [word-scope-file-path-not-found.md](./word-scope-file-path-not-found.md) for generating an absent file.

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/export-pdf-com-hang.md

@@ -0,0 +1,46 @@
+---
+confidence: medium
+---
+
+# Export to PDF — COM Interop Hang / Crash / COMException
+
+## Context
+
+What this looks like:
+- Activity `Export to PDF` / `Save Document as PDF` (`UiPath.Word.Activities.WordExportToPdf`) **freezes / hangs**, the job crashes, or it faults with a `System.Runtime.InteropServices.COMException`
+- May be intermittent — succeeds on some runs, hangs/crashes on others
+
+What can cause it:
+- `WordExportToPdf` drives Microsoft Word via **COM Interop**. An **orphaned `WINWORD.EXE`** from a previous run left locked in memory blocks the new export, or the **input document is still open / locked** by another user, process, or a prior un-disposed scope. Word can't service the export call → hang or `COMException`.
+
+What to look for:
+- Orphaned `WINWORD.EXE` processes on the robot host (Task Manager, no visible window).
+- Whether the input document is open elsewhere or held by a sync/AV client.
+- Whether the surrounding `Word Application Scope` disposes cleanly on every path (an un-disposed scope leaves WINWORD.EXE behind).
+
+## Investigation
+
+1. Confirm the faulted activity is `Export to PDF` and capture the HRESULT if a `COMException` was thrown.
+2. Ask the user (or someone with desktop access on the robot host, as the robot's Windows user) to check for orphaned `WINWORD.EXE` instances and whether the input document is open/locked elsewhere at run time.
+3. Check whether prior runs left Word processes behind (a sign the scope isn't disposing).
+
+## Resolution
+
+- **Clear stale Word sessions** — add a **Kill Process** activity with `ProcessName = "WINWORD"` **immediately before** the Word automation / export sequence to clear hung background instances. Ensure the `Word Application Scope` disposes on every path so it doesn't orphan WINWORD.EXE. As a one-time cleanup, end stray `WINWORD.EXE` (`Stop-Process -Name WINWORD -Force`).
+- **Ensure the input is free** — confirm the source document is fully closed and not locked by another user/application before exporting.
+- **If COM errors persist after the above** — bypass the native activity and do the conversion in an **Invoke Code (C#)** step using Word Interop directly (import `Microsoft.Office.Interop.Word`):
+  ```csharp
+  // Arguments: argInputFile (String), argOutputFile (String)
+  var wordApp = new Microsoft.Office.Interop.Word.Application();
+  try {
+      var doc = wordApp.Documents.Open(argInputFile);
+      doc.ExportAsFixedFormat(argOutputFile, Microsoft.Office.Interop.Word.WdExportFormat.wdExportFormatPDF);
+      doc.Close(false);
+  }
+  finally {
+      wordApp.Quit();
+  }
+  ```
+  The `finally { wordApp.Quit(); }` guarantees Word is released even on error — addressing the orphaned-process root cause directly. Requires desktop Word installed on the host.
+
+> Related COM failures: a modal dialog blocking Word (password / recovery / activation) → [word-scope-hangs-background-prompt.md](./word-scope-hangs-background-prompt.md); `RPC_E_SERVERCALL_RETRYLATER` busy signal → [replace-text-com-busy.md](./replace-text-com-busy.md); a startup `REGDB_E_CLASSNOTREG` (no desktop Word) → [word-scope-com-not-installed.md](./word-scope-com-not-installed.md).

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/export-pdf-missing-output-dir.md

@@ -0,0 +1,32 @@
+---
+confidence: medium
+---
+
+# Export to PDF — "Command Failed" Because the Output Directory Doesn't Exist
+
+## Context
+
+What this looks like:
+- Activity `Export to PDF` / `Save Document as PDF` (`UiPath.Word.Activities.WordExportToPdf`) faults with a **generic `Command Failed`** error (no specific cause in the message)
+- The output `.pdf` is never written
+
+What can cause it:
+- The output path points at a **folder that does not exist** on the execution machine. `WordExportToPdf` does **not** auto-create intermediate directories — if the target folder isn't there, the underlying save fails and surfaces only as a generic `Command Failed`.
+
+What to look for:
+- The output path's folder vs what exists on the robot host — a path like `C:\Output\2026\Invoices\file.pdf` where `C:\Output\2026\Invoices\` was never created.
+- A dynamically built output folder (date-stamped, per-customer) that is assumed to exist but isn't created by any prior step.
+
+## Investigation
+
+1. Read the `Export to PDF` node from the `.xaml` and capture the literal output path expression. Resolve it to a concrete path for the failing run.
+2. Check whether the **parent folder** of that path exists on the execution machine (ask the user / someone with host access if off-host). A missing parent folder is the cause.
+3. Confirm no earlier activity in the workflow creates that folder.
+
+## Resolution
+
+- **Create the folder before exporting** — add a **Create Folder** activity (target = the output directory) **immediately before** the `Word Application Scope` / export step, so the directory is built dynamically at runtime. `Create Folder` is a no-op if the folder already exists, so it is safe on every run.
+- **Or build the path from a guaranteed-existing root** — point the output at a directory the robot always has (e.g. the project output folder), or have the provisioning step pre-create the target tree.
+- After adding `Create Folder`, re-run and confirm the `.pdf` is written.
+
+> The generic `Command Failed` carries no detail — a missing output directory is the most common cause, but also rule out an invalid/un-suffixed path (see [export-pdf-output-path-format.md](./export-pdf-output-path-format.md)) and a busy/locked Word COM session (see [export-pdf-com-hang.md](./export-pdf-com-hang.md)).

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/export-pdf-output-path-format.md

@@ -0,0 +1,35 @@
+---
+confidence: medium
+---
+
+# Export to PDF — Malformed Output Path / Missing .pdf Extension
+
+## Context
+
+What this looks like:
+- Activity `Export to PDF` / `Save Document as PDF` (`UiPath.Word.Activities.WordExportToPdf`) fails to save, or throws an unexpected exception while writing the file
+- The output file is missing, has no extension, or lands at a wrong/garbled path
+
+What can cause it:
+- The output **File Path** is built from **unformatted dynamic pieces** — e.g. a folder variable concatenated to a filename without a separator, or **without a `.pdf` suffix**, producing an invalid target (no extension, doubled/missing backslashes, trailing spaces).
+
+What to look for:
+- The output-path expression in the `.xaml`: is it a clean absolute path ending in `.pdf`, or a raw string concatenation?
+- Missing separator between folder and file, a filename with no `.pdf`, or an unresolved/empty variable segment.
+
+## Investigation
+
+1. Read the `Export to PDF` node and capture the exact output-path expression. Evaluate what it resolves to for the failing run.
+2. Check the resolved string: does it end in `.pdf`? Is there exactly one separator between folder and filename? Are all variable segments populated (no empty/`null` pieces)?
+
+## Resolution
+
+- **Build the path explicitly with a `.pdf` suffix.** Use `Path.Combine` and an explicit extension rather than bare string concatenation, e.g.:
+  ```vbnet
+  Path.Combine(targetFolderVar, fileNameVar & ".pdf")
+  ```
+  or, if concatenating, ensure the separator and suffix: `targetFolderVar & "\" & fileNameVar & ".pdf"`.
+- **Validate the pieces** — confirm `fileNameVar` has no extension already (avoid `name.pdf.pdf`), no illegal filename characters, and no trailing whitespace; confirm `targetFolderVar` is an absolute path.
+- Re-run and confirm the `.pdf` is created at the intended path.
+
+> If the path is correct but the **folder** doesn't exist, the symptom is the generic `Command Failed` — see [export-pdf-missing-output-dir.md](./export-pdf-missing-output-dir.md).

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/read-text-doc-format.md

@@ -0,0 +1,30 @@
+---
+confidence: medium
+---
+
+# Read Text — Standalone System Activity Fails on Legacy .doc Files
+
+## Context
+
+What this looks like:
+- The standalone **`Read Text`** activity under **`System > File > Word Document`** reads `.docx` files fine but **errors or returns nothing** on older `.doc` files
+- Surfaces as a read/parse exception, an empty result, or a format-not-supported error when the input is a binary `.doc`
+
+What can cause it:
+- The standalone System Word Document `Read Text` activity is optimized for the **OpenXML `.docx`** format. The legacy binary **`.doc`** format is not reliably supported, so it fails or extracts nothing.
+
+What to look for:
+- The target file's extension/format — `.doc` (legacy binary) vs `.docx` (OpenXML).
+- Whether the activity is the **standalone System** Read Text (the OpenXML-limited one) rather than the scoped Word-pack activity.
+
+## Investigation
+
+1. Confirm the input file is a legacy `.doc` (not `.docx`) — check the actual format, not just the extension (a renamed file can mislead).
+2. Confirm the failing activity is the standalone `System > File > Word Document` `Read Text`, which is the OpenXML-limited surface.
+
+## Resolution
+
+- **Read `.doc` through the Interop container** — wrap the file in a **`Use Word File`** container (or legacy `Word Application Scope`) and read it with the Word-pack `Read Text` activity inside that scope. The Microsoft Word Interop framework the container uses opens and reads both `.doc` and `.docx` seamlessly (it converts the legacy format on open).
+- **Or convert up front** — if you must stay on the standalone System activity, convert the `.doc` to `.docx` first (open-and-save-as via a Word scope, or a conversion step), then read the `.docx`.
+
+> The Interop path requires desktop Word installed on the host (see [word-scope-com-not-installed.md](./word-scope-com-not-installed.md)). The standalone System activity does not need Word but is `.docx`-only.

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/read-text-missing-container.md

@@ -0,0 +1,29 @@
+---
+confidence: high
+---
+
+# Read Text — Activity Outside Its Container (Validation Warning / Runtime Error)
+
+## Context
+
+What this looks like:
+- The modern `Read Text` activity (from the `UiPath.Word.Activities` pack) shows a **design-time validation warning** ("activity must be placed inside a `Use Word File`") or **faults at runtime** as invalid / missing parent
+- Common messages: `Read Text` must be inside a `Use Word File` (or legacy `Word Application Scope`); a validation error preventing the run, or a runtime "activity is not valid in this context"
+
+What can cause it:
+- The modern Word-pack `Read Text` activity has **no file input of its own** — it reads the document held open by a surrounding `Use Word File` / `Word Application Scope` container. Dropped **outside** any container, it has nothing to read and is invalid.
+
+What to look for:
+- Whether the `Read Text` node is nested inside a `Use Word File` / `Word Application Scope` in the `.xaml`, or sits loose in the sequence.
+- Whether the activity is the **modern pack** Read Text (needs a container) or the **standalone System** Read Text (takes its own file path).
+
+## Investigation
+
+1. Read the workflow `.xaml`. Confirm the `Read Text` node is the modern Word-pack activity and whether it is inside a `Use Word File` / `Word Application Scope`.
+2. Note whether the failure is design-time (validation warning in Studio) or a runtime invalid-context fault — both point at the same missing-container cause.
+
+## Resolution
+
+- **If you want to read from an already-open document** — move the `Read Text` activity **inside** a `Use Word File` container (or a legacy `Word Application Scope`) that opens the target file. The activity then reads the container's open document.
+- **If you want a stand-alone read with no container** — use the native **`Read Text`** activity under **`System > File > Word Document`** instead. It takes the **file path directly in its own properties**, so no scope is required.
+- **Pick one surface deliberately** — the pack Read Text (scoped) for workflows already inside a Word scope; the System Word Document Read Text (standalone) for a one-off extraction by path.

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/read-text-protected-view.md

@@ -0,0 +1,32 @@
+---
+confidence: medium
+---
+
+# Read Text — Protected View Blocks Reading a File From an Untrusted Source
+
+## Context
+
+What this looks like:
+- Reading a Word document (via `Read Text` inside `Use Word File` / `Word Application Scope`) **faults trying to open/access the file**, or hangs, when the file came from **email, the internet, or an external/network server**
+- The same file opens and reads fine when it originated locally; only externally-sourced copies fail
+
+What can cause it:
+- Word opens files carrying a **Mark-of-the-Web** (downloaded / received from outside the machine) in **Protected View** — a read-only sandbox. The Interop read against a Protected-View document is blocked, surfacing as an access exception (or, unattended, a hang on the Protected View bar that nobody can dismiss).
+
+What to look for:
+- The file's origin — downloaded, email attachment, copied from a network/external share (carries Mark-of-the-Web) vs created locally.
+- Whether the failure is specific to externally-sourced files.
+
+## Investigation
+
+1. Confirm the failing document came from an external source (email/internet/remote share) and that locally-created files read fine — that isolates Protected View / Mark-of-the-Web.
+2. Ask the user (or someone with desktop access on the robot host, as the robot's Windows user) whether the file opens in Protected View when double-clicked.
+
+## Resolution
+
+- **Unblock the file (preferred, per-file)** — clear the Mark-of-the-Web before reading: `Right-click > Properties > Unblock`, or `Unblock-File <path>` in PowerShell as a workflow pre-step.
+- **Add the folder to Trusted Locations** — `File > Options > Trust Center > Trust Center Settings > Trusted Locations` on the execution machine (as the robot's Windows user), so files in that folder skip Protected View.
+- **Disable Protected View on the execution machine** — `File > Options > Trust Center > Trust Center Settings > Protected View` and uncheck the relevant rules (files from internet / Outlook / unsafe locations). Apply only on a controlled robot host, since it lowers a safety control.
+- **If unattended and hanging rather than erroring** — the Protected View bar is an invisible blocking dialog; see [word-scope-hangs-background-prompt.md](./word-scope-hangs-background-prompt.md).
+
+> Related: [word-scope-file-corrupted.md](./word-scope-file-corrupted.md) covers Protected View / Mark-of-the-Web blocking a *write/save*; this playbook covers it blocking a *read*.

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/replace-text-com-busy.md

@@ -0,0 +1,35 @@
+---
+confidence: medium
+---
+
+# Replace Text in Document — "Application is busy" / COM Interop Retry Failure (0x8001010A)
+
+## Context
+
+What this looks like:
+- Activity `Replace Text in Document` / `Replace Text` (`UiPath.Word.Activities.ReplaceTextInDocument` modern, `UiPath.Word.Activities.WordReplaceText` classic) faults with a COM HRESULT
+- Error message contains one of:
+  - `The message filter indicated that the application is busy. (Exception from HRESULT: 0x8001010A (RPC_E_SERVERCALL_RETRYLATER))`
+  - `Call was rejected by callee. (Exception from HRESULT: 0x80010001 (RPC_E_CALL_REJECTED))`
+- Often intermittent — the same workflow succeeds on one run and faults on the next
+
+What can cause it:
+- Microsoft Word (WINWORD.EXE) is **busy or unresponsive** when the activity issues its COM call: another WINWORD.EXE is open in the background, the document is locked by another user/session, or Word is stalled on a modal pop-up dialog
+- When the surrounding scope runs with `Visible = False`, a blocking dialog is invisible but still wedges the COM call
+
+What to look for:
+- Extra WINWORD.EXE instances in Task Manager on the robot host.
+- Whether the document is also open in an interactive desktop window.
+
+## Investigation
+
+1. Capture the exact HRESULT (`0x8001010A` / `0x80010001`) and confirm the faulted activity is `Replace Text in Document` / `Replace Text` inside a `Word Application Scope` / `Use Word File` container.
+2. Ask the user (or someone with desktop access on the robot host, signed in as the robot's Windows user) to check for orphaned WINWORD.EXE processes and whether the target document is open in another window.
+3. Re-run with the scope `Visible = True` and observe whether Word shows a blocking dialog (recovery sidebar, macro/trust prompt, license activation) during the run.
+
+## Resolution
+
+- **If a stray / orphaned WINWORD.EXE is holding Word busy** — add a `Kill Process` activity with `ProcessName = "WINWORD"` to clear locked sessions: at the **very start of the workflow** to clear any pre-existing WINWORD before the run, and/or immediately **before** the Word scope. Ensure the scope disposes so Word always closes cleanly, and confirm the file is not open in another desktop window (by you, another user, or a background process) during the run.
+- **If a modal dialog is blocking** — surface it by running `Visible = True`, then clear the source (a **password prompt** on a protected document, a recovery/trust prompt, license activation). Dismiss it, supply the password, or add the folder to Trusted Locations. See [word-scope-hangs-background-prompt.md](./word-scope-hangs-background-prompt.md) for the dialog-by-dialog breakdown.
+- **If the document is locked by another process** — stop the concurrent accessor (a second job, a sync/AV client, an interactive session); see [word-scope-file-corrupted.md](./word-scope-file-corrupted.md) for the lock-clearing steps.
+- **As a resilience guard** — wrap the operation in a `Retry Scope` so a transient `RPC_E_SERVERCALL_RETRYLATER` retries rather than faulting the job on the first busy signal.

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/replace-text-file-locked.md

@@ -0,0 +1,33 @@
+---
+confidence: medium
+---
+
+# Replace Text in Document — File Lock / "File is Read-Only" on Save
+
+## Context
+
+What this looks like:
+- Activity `Replace Text in Document` / `Replace Text` faults when the surrounding scope tries to persist the edit
+- Error message contains one of:
+  - `The process cannot access the file because it is being used by another process`
+  - `The file is read-only` / `Cannot save the document because it is read-only`
+
+What can cause it:
+- The `Word Application Scope` / `Use Word File` container tries to **save changes while the same file is being accessed elsewhere** — most often when `Auto Save` is on and the document is touched by another activity in the same loop iteration, or a second job/sync client holds the handle
+- A `Save As` / rename to the **same path** while the file is still open inside an active loop
+
+What to look for:
+- Whether `Auto Save` is enabled on the `Use Word File` scope.
+- Whether the scope (or a save/rename) runs inside a loop over the same file path.
+
+## Investigation
+
+1. Read the scope and the `Replace Text in Document` node from the `.xaml`. Capture the file path, whether `Auto Save` is enabled, and whether the scope or any save/rename sits inside a `For Each` / `While` over the same path.
+2. Check the robot host for a second process holding the file (orphaned WINWORD.EXE, a concurrent job, a sync/AV client) and whether the file's read-only attribute is set.
+
+## Resolution
+
+- **If Auto Save races another access in a loop** — uncheck **Auto Save** in the `Use Word File` properties so the document is written once on scope exit rather than continuously, removing the save-vs-access race.
+- **If a `Save As` / rename reuses the same path inside a loop** — write to a distinct output path per iteration (build it with `Path.Combine`) instead of overwriting the open file; avoid `Save As` to the exact path the scope still holds open.
+- **If another process holds the file** — clear the lock before the scope (`Kill Process` for `WINWORD`, stop the concurrent job, exclude the folder from sync/AV); see [word-scope-file-corrupted.md](./word-scope-file-corrupted.md) for the full lock-clearing steps.
+- **If the file's read-only attribute is set** — clear it (`attrib -R <path>` or `Set-ItemProperty <path> -Name IsReadOnly -Value $false`) or copy to a writable working location before editing.

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/replace-text-headers-textboxes-skipped.md

@@ -0,0 +1,30 @@
+---
+confidence: medium
+---
+
+# Replace Text in Document — Headers, Footers, and Text Boxes Not Replaced
+
+## Context
+
+What this looks like:
+- Activity `Replace Text in Document` / `Replace Text` finishes **without error**, but text inside **headers, footers, or floating text boxes / shapes** is left unchanged — only the main body got the substitution
+- Placeholders in the body are replaced correctly; the same placeholder in a header or text box survives
+
+What can cause it:
+- **Older versions of `UiPath.Word.Activities`** scan only the primary body text. Content stored in header/footer story ranges or in floating shapes (text boxes) is outside the scanned range, so those placeholders are never matched.
+
+What to look for:
+- Where the surviving placeholder lives (header / footer / text box vs body).
+- The `UiPath.Word.Activities` version in `project.json`.
+
+## Investigation
+
+1. Confirm the unreplaced placeholder is in a **header, footer, or text box / shape**, while body placeholders did replace — that locates the gap to non-body story ranges.
+2. Check the `UiPath.Word.Activities` version in `project.json` against the latest release.
+
+## Resolution
+
+- **Update the package** — open `Manage Packages` in Studio and update `UiPath.Word.Activities` to the latest version, then rebuild. Newer versions natively replace inside headers, footers, and text shapes.
+- **If you cannot upgrade** — substitute the header/footer/text-box content explicitly (e.g. address the header story range directly, or move the placeholder into the body), or do the replacement in code over the document XML, which covers all story ranges.
+
+> This is a silent miss — the activity throws nothing. Trace the **output document content** (including headers/footers/text boxes), not just the absence of an exception. For a body-text silent miss caused by run-splitting rather than the package version, see [replace-text-silent-no-substitution.md](./replace-text-silent-no-substitution.md).

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/replace-text-length-limit.md

@@ -0,0 +1,30 @@
+---
+confidence: high
+---
+
+# Replace Text in Document — Input String Length Limit (256 Characters)
+
+## Context
+
+What this looks like:
+- Activity `Replace Text in Document` / `Replace Text` faults or silently truncates when the `Search` or `Replace` value is long
+- Error message is an `ArgumentException`, or there is no error but the written value is **cut off** at 256 characters
+
+What can cause it:
+- Classic versions of the activity enforce a **hard 256-character limit** on both the `Search for` and `Replace with` input fields. A value over 256 characters raises `ArgumentException` or is truncated.
+
+What to look for:
+- The length of the `Replace` (and `Search`) expressions at runtime — over 256 characters is the trigger.
+- The `UiPath.Word.Activities` package version (the limit is a classic-version constraint).
+
+## Investigation
+
+1. Read the `Replace Text in Document` node and evaluate the actual length of the `Search` and `Replace` values for the failing run. Confirm one exceeds 256 characters.
+2. Check the `UiPath.Word.Activities` version in `project.json` — the 256-char limit is present in classic/older versions and relaxed in current ones.
+
+## Resolution
+
+- **If the replacement text exceeds 256 characters** — update the `UiPath.Word.Activities` dependency to the latest version (the limit is relaxed in current releases), then rebuild.
+- **If you cannot upgrade the package** — do the substitution in code instead: read the document text into a `String`, replace with `myString.Replace(...)` / regex in an `Assign`, and write the result back, which has no 256-character cap.
+- **If the replacement text is long by nature** (e.g. a legal clause, a multi-sentence paragraph) — don't use `Replace Text` at all. Place a **Bookmark or Form Field** at the insertion point in the template and fill it with the `Set Bookmark Text` activity, which has no length cap and preserves the bookmark's formatting. Keep `Search` placeholder keys short.
+- **If the value is being truncated silently** — same fix; verify the output document content after the write rather than trusting a no-error run.

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/replace-text-loop-template-overwrite.md

@@ -0,0 +1,31 @@
+---
+confidence: medium
+---
+
+# Replace Text in Document — Placeholder Replaced Once, Then Missing in Loop Iterations
+
+## Context
+
+What this looks like:
+- Activity `Replace Text in Document` / `Replace Text` works on the **first** iteration of a loop and then does nothing (or the output is wrong) on every subsequent iteration
+- No exception is necessarily thrown — later rows simply come out with the placeholder gone / the first row's value baked in
+
+What can cause it:
+- The workflow opens and edits the **template file in place** inside the loop. Once the placeholder (e.g. `[Name]`) is replaced on iteration 1, the literal placeholder **no longer exists in the file**, so iteration 2 finds nothing to replace. Every later row inherits the mutated document instead of a clean template.
+
+What to look for:
+- Whether the `Use Word File` / `Word Application Scope` inside the loop points at the **same template path** every iteration.
+- Whether a fresh copy of the template is made per iteration (it usually is not — that's the bug).
+
+## Investigation
+
+1. Read the loop body from the `.xaml`. Confirm the Word scope's file path is the template itself (same path each iteration), not a per-iteration copy.
+2. Confirm the symptom: iteration 1 succeeds, later iterations leave the placeholder missing / stale. The template on disk is mutated after the first run.
+
+## Resolution
+
+- **Copy the template per iteration** — at the **start of each loop iteration**, use a `Copy File` activity to create a fresh temporary copy of the template (a unique per-row output path, e.g. built with `Path.Combine`), and point the `Use Word File` / `Word Application Scope` at **that temporary file** instead of the template. Each row then starts from a clean, unmodified template.
+- **Never edit the source template in place** — treat the template as read-only; generate a new output document per row.
+- **Source:** the placeholder is consumed by the first replacement; the fix is a fresh template copy per iteration.
+
+> Distinct from [replace-text-silent-no-substitution.md](./replace-text-silent-no-substitution.md) (placeholder split across Word XML runs — fails on *every* row, including the first) and [replace-text-file-locked.md](./replace-text-file-locked.md) (`IOException` from Auto Save racing a shared file in a loop). Here the first row succeeds and the cause is template mutation, not a run-split token or a file lock.

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/replace-text-multiline-formatting.md

@@ -0,0 +1,31 @@
+---
+confidence: medium
+---
+
+# Replace Text in Document — Multi-line Replacement Loses Formatting / Collapses to One Line
+
+## Context
+
+What this looks like:
+- Activity `Replace Text in Document` / `Replace Text` completes, but the replacement text **loses its formatting** or **wraps into a single line** instead of preserving the intended paragraph breaks
+- The `Search` placeholder is replaced, but the multi-line/styled result does not render as expected
+
+What can cause it:
+- The `Replace` value is a **raw string containing standard environment line breaks** (`Environment.NewLine` / `\r\n`). The activity inserts the text as a flat run, so OS line breaks do not become proper Word paragraph breaks and any intended formatting is dropped.
+
+What to look for:
+- Whether the `Replace` expression embeds `Environment.NewLine` / `vbCrLf` / `\n` to build multi-line content.
+- Whether the expected output is rich/multi-paragraph (styled) rather than a simple token swap.
+
+## Investigation
+
+1. Read the `Replace` expression. Confirm it carries line breaks or formatting intent (multi-paragraph text), not a simple single-line value.
+2. Confirm the symptom is layout/formatting (collapsed lines, lost styling), not a missing replacement.
+
+## Resolution
+
+- **Keep replacement strings simple** — use `Replace Text` only for plain, single-line token swaps. Avoid passing `Environment.NewLine`-laden strings and expecting Word paragraph formatting.
+- **For complex multi-line / styled content** — do not use `Replace Text`. Use **Bookmarks or Form Fields** with the `Set Bookmark Text` activity (preserves the bookmark's formatting), or a copy-paste simulation approach when preserving nested multi-line paragraphs is mandatory.
+- **If you must inject paragraphs via Replace** — split the content and insert paragraph breaks through the Word object model rather than relying on raw `Environment.NewLine` in the `Replace` field.
+
+> For long replacement text that hits the 256-character input cap (a different failure), see [replace-text-length-limit.md](./replace-text-length-limit.md) — the Bookmarks / Form Fields path applies there too.

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/replace-text-silent-no-substitution.md

@@ -0,0 +1,32 @@
+---
+confidence: medium
+---
+
+# Replace Text in Document — Placeholder Not Replaced (No Error, No Change)
+
+## Context
+
+What this looks like:
+- Activity `Replace Text in Document` / `Replace Text` runs and the job **succeeds with no exception**, but the placeholder (e.g. `[Name]`, `{{Customer}}`) is left untouched in the output document
+- Re-running does not help; the search term visibly matches the template text by eye
+
+What can cause it:
+- Word stores text as runs in its internal XML. A placeholder that was **typed, then partially edited (backspaced, retyped, or reformatted) in place** gets split across multiple runs. The displayed text reads `[Name]`, but in the XML it is fragmented (e.g. `[Na` + `me]`), so the activity's exact-string search never matches the contiguous term
+- A formatting change mid-placeholder (bold on one character, a different font) also splits the run
+
+What to look for:
+- Whether the placeholder was edited in place in the template (a tell: it was typed with corrections).
+- Whether part of the placeholder carries different formatting from the rest.
+
+## Investigation
+
+1. Confirm the activity reports success and the `Search` value exactly matches the on-screen placeholder (character-for-character, including brackets and case).
+2. Inspect the template: select the whole placeholder and check the formatting is uniform across every character. If unsure, inspect the document XML (`.docx` → rename to `.zip` → `word/document.xml`) and look for the placeholder split across multiple `<w:t>` runs.
+
+## Resolution
+
+- **If the placeholder is split across runs** — in the Word template, fully highlight the placeholder, delete it, and **retype it in one continuous motion** without backspaces or mid-word formatting changes, so it lands in a single run. Save the template and re-run.
+- **Make templates robust** — author placeholders by typing them cleanly once (or paste as plain text), keep uniform formatting across the whole token, and avoid editing them character-by-character afterwards.
+- **If you cannot control the template** — read the document text into a string, replace with `myString.Replace(...)` / regex in an `Assign`, and write it back, which operates on the flattened text rather than run boundaries.
+
+> This is a silent failure — the activity throws nothing. Trace the **output document content** (or add a post-replace `Word`-read + assertion) rather than relying on the activity not faulting.

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/replace-text-version-mismatch.md

@@ -0,0 +1,30 @@
+---
+confidence: medium
+---
+
+# Replace Text in Document — TargetInvocationException / Studio Crash on Drop
+
+## Context
+
+What this looks like:
+- Studio errors **immediately when the `Replace Text in Document` / `Replace Text` activity is dropped** onto the designer panel, or while opening a workflow that contains it
+- Error message contains `System.Reflection.TargetInvocationException` (often wrapping an inner type/version load error), or Studio becomes unstable / crashes
+
+What can cause it:
+- A **version mismatch between Studio and the `UiPath.Word.Activities` package** — an older Studio loading a newer package dependency (or vice versa) cannot construct the activity's designer, so the reflection call that instantiates it throws
+
+What to look for:
+- The Studio version vs the installed `UiPath.Word.Activities` version.
+- Whether the crash is design-time (on drop / open) rather than at runtime.
+
+## Investigation
+
+1. Confirm the failure is **design-time** (on dropping the activity or opening the workflow in Studio), not a runtime job fault — this distinguishes it from the runtime "Cannot create unknown type" package gap.
+2. Compare the installed `UiPath.Word.Activities` version against the Studio version's supported range.
+
+## Resolution
+
+- **If Studio and the package are mismatched** — open `Manage Packages`, select `UiPath.Word.Activities`, and upgrade or downgrade to a version compatible with the installed Studio (a known-stable release for that Studio version), then reopen the workflow.
+- **If upgrading the package is required by other activities** — upgrade Studio to a version that supports the newer package instead, so the whole dependency set is compatible.
+
+> This is a **design-time** Studio crash from a version mismatch. For the **runtime** `Cannot create unknown type WordApplicationScope` fault (the robot lacks the package version at execution), see [word-scope-cannot-create-unknown-type.md](./word-scope-cannot-create-unknown-type.md).

package/skills/uipath-troubleshoot/references/activity-packages/word-activities/playbooks/word-com-interop-failures.md

@@ -0,0 +1,52 @@
+---
+confidence: medium
+---
+
+# Word COM / Office Interop Failures & Word Process Crashes
+
+## Context
+
+This playbook covers **environmental / host-level** failures of the Word COM (Office Interop) layer that the `UiPath.Word.Activities` package depends on. It is **not specific to one activity** — any operation that drives a real `WINWORD.EXE` through Office Interop can surface these, including the `Use Word File` (`WordProcessScope`) / `Word Application Scope` container itself and the activities inside it (`Add Picture`, `Replace Text`, `Get Text`, `Set Bookmark Content`, `Export to PDF`, etc.). When the failure is genuinely activity-specific (a misplaced activity, a missing bookmark, a bad image path), use that activity's own playbook instead — this one is for the COM/host layer that is common to all of them.
+
+What this looks like:
+- `System.InvalidCastException: Unable to cast COM object of type 'System.__ComObject' / 'Microsoft.Office.Interop.Word.ApplicationClass' to interface type 'Microsoft.Office.Interop.Word._Application'` (or `_Document`), carrying an `(Exception from HRESULT: 0x…)`.
+- `The application is busy` / a call-rejected or retry HRESULT.
+- **Microsoft Word (`WINWORD.EXE`) itself faults and closes** mid-operation, and the activity then throws a COM cast / RPC error on its async-completion path (e.g. `UiPath.Word.Activities.WordInteropActivity.EndExecute`).
+- The job runs fine in Studio on the developer's machine but faults only on a specific robot host — a strong tell of an **environmental** difference, not a source bug.
+
+## Causes
+
+Name the confirmed sub-cause exactly. Do NOT assert a cause unless the investigation decision tree arrived at it.
+
+- **E1. COM type library / class not registered.** `0x8002801D` (`TYPE_E_LIBNOTREGISTERED`, "Library not registered") or the sibling `0x80040154` (`REGDB_E_CLASSNOTREG`, "Class not registered"). The cast to the Word `_Application` interface fails **during Word COM startup** (`WordApplicationScopeRuntime.EnsureWordApplication`), before any document work. Typically follows a partial or failed Office update/repair that left the interop type library unregistered.
+- **E2. Bitness mismatch.** A 32-bit/64-bit mismatch between the Studio/Robot process and the installed Office. Produces the same class of COM startup cast/registration failure as E1.
+- **E3. Word busy or blocked.** `0x8001010A` (`RPC_E_SERVERCALL_RETRYLATER`, "The application is busy"), `0x80010001` (`RPC_E_CALL_REJECTED`), or `0x80010100` (`RPC_E_SYS_CALL_FAILED`). An orphaned/hung `WINWORD.EXE` from a prior run holds the COM server, or Word is blocked on a modal dialog (Protected View / Mark-of-the-Web "file from the internet", activation, recover/repair prompt). Often intermittent.
+- **E4. Word process crash mid-operation (COM error is a downstream symptom).** `WINWORD.EXE` faults and closes *during* an operation. The activity's async-completion path then runs `QueryInterface` against the COM server / apartment that the dying process already tore down, and surfaces `0x8001010E` (`RPC_E_WRONG_THREAD`, "interface marshalled for a different thread") and/or an `InvalidCastException` on the Word `_Document` interface. **The HRESULT is the aftermath, not the originating fault — diagnose the crash, not the marshalling error.** Triggers: a host Office instability (any of E1–E3), or an operation that pushes Word past a resource/render limit on this install. One known Add-Picture-specific trigger is **inserting a very large but otherwise valid image at full resolution** — `Add Picture` exposes no resize property, so a multi-megapixel image is handed to Word un-downscaled. *(The large-image trigger is a suspected/contributing pattern observed in the field, not a documented defect — confirm it with the faulting module per Investigation.)*
+
+## Investigation
+
+1. **Decode the HRESULT and locate the faulting frame** from the job error and stack.
+2. **Decision tree** (stop at the first match):
+   - Cast to the Word **`_Application`** interface failing in `EnsureWordApplication` / `WordApplicationScopeRuntime` during **startup**, with `0x8002801D` or `0x80040154` → **E1** (or **E2** if Studio/Robot and Office bitness differ — check both before concluding).
+   - "Application is busy" / call-rejected / retry-later (`0x8001010A`, `0x80010001`, `0x80010100`) → **E3**. Check the robot host for an orphaned `WINWORD.EXE`, and for a modal/Protected-View state (especially if inputs came from `Downloads` / the internet — see Mark-of-the-Web).
+   - Cast to the Word **`_Document`** interface with **`0x8001010E` (`RPC_E_WRONG_THREAD`)** on an async-completion frame (`WordInteropActivity.EndExecute`), **and/or the user reports that Word faulted and closed** → **E4**. The marshalling error is downstream of a process crash.
+3. **For E4 — recover the crash forensics (decisive).** Pull the Windows **Application event log** record for the `WINWORD.EXE` crash — Event ID **1000** (`Application Error`), **1001** (Windows Error Reporting / APPCRASH bucket), or a `.NET Runtime` record — and read the **faulting module name + version** and **exception code** (e.g. `0xc0000005` access violation). The faulting module discriminates the trigger: a graphics / GDI+ / image-codec module points at an image-insert/render crash; an Office install / interop / loader module points at E1–E3; an RTF-import / document-conversion module points at a document-state interaction. If no crash record exists because the host's WER `ReportArchive` is saturated (e.g. another process is in a crash loop), restore WER retention or attach **ProcDump** to `WINWORD.EXE` (`procdump -e -ma WINWORD.EXE`) before reproducing. *(ProcDump and the WER archive are standard Microsoft/Sysinternals host tooling, not UiPath-documented steps.)*
+4. **Capture the host Office state** for E1–E4: Office edition/channel and **bitness** (`File > Account > About Word`) versus the Studio/Robot process bitness; whether multiple Office installs coexist; and any orphaned `WINWORD.EXE` (Task Manager / `Get-Process WINWORD`).
+5. **Confirm the workflow is not the cause.** If the activity is correctly scoped and its inputs are valid, and the same workflow succeeds in Studio on the developer's machine, the fault is environmental/host — do not edit the XAML.
+
+## Resolution
+
+Apply the fix for the identified sub-cause. The workflow itself usually needs no change.
+
+- **E1 — type library / class not registered:** run an **online repair** of Microsoft Office on the robot host (`Settings > Apps > Microsoft Office > Modify > Online Repair`) to re-register the Office/Word COM type libraries. No workflow change required.
+- **E2 — bitness mismatch:** reinstall Office at the same architecture as the Studio/Robot process (both 32-bit or both 64-bit).
+- **E3 — busy / blocked:** kill any orphaned `WINWORD.EXE` (Task Manager / `Stop-Process -Name WINWORD -Force`) so the scope opens a clean instance, and ensure no `Try/Catch` swallows the scope's `Dispose`; dismiss/avoid modal and Protected-View states — if inputs are downloaded files, **unblock** them (`Right-click > Properties > Unblock` or `Unblock-File`) to clear the Mark-of-the-Web banner.
+- **E4 — Word process crash:** this is a crash, not a marshalling bug.
+  1. Apply the E1–E3 host remediation (repair Office, match bitness, clear orphaned `WINWORD.EXE`) — a destabilized Office install is the most common crash cause.
+  2. If a specific operation reproducibly crashes Word with **valid** inputs, reduce what you hand Word. For `Add Picture` crashing on a large image, **pre-resize the image to a sane size before inserting it** (the activity has no resize property), use a smaller image, or insert via **`Paste Chart/Picture Into Document`** (clipboard) instead of the file-path insert.
+  3. Capture the faulting module (Investigation step 3) to confirm the trigger before committing to a fix.
+- **Fallback (any cause) — avoid Office Interop entirely:** migrate to the file-based `Word Document` activities (Studio panel under **System > File > Word Document**), which manipulate the `.docx` through the document object model without launching Word.
+
+**Prevention.** Treat a Word COM HRESULT (`0x8002801D` / `0x80040154` / `0x8001010A` / `0x8001010E`) — or a job that succeeds in Studio but faults only on a robot host — as an **environment problem on the host**, not a workflow defect. Investigate Office repair, bitness, orphaned processes, and (for crashes) the faulting module; do not edit the XAML.
+
+If a COM failure persists after all environmental causes are ruled out, capture a `Verbose` robot log plus a Process Monitor trace and/or a **ProcDump** crash dump of `WINWORD.EXE` during the failure (and the offending input file, e.g. the image), and open a UiPath support case.