@uipath/skills 1.197.0 → 1.197.2

package/skills/uipath-troubleshoot/references/products/agents/playbooks/context-grounding-index-not-found.md

@@ -67,6 +67,8 @@ What to look for:
   uip context-grounding ingest --index-name "<index-name>" --folder-path "<folder-path>" --output json
   ```
 
+  Ingestion is async: after `ingest`, poll `uip context-grounding retrieve --index-name "<index-name>" --folder-path "<folder-path>" --output json` until `last_ingestion_status` is `Successful` before searching — the index is not queryable earlier.
+
   No agent republish needed — the runtime resolves by name.
 
 **If the index exists but is in a different folder — re-link the agent:**

package/skills/uipath-troubleshoot/references/products/integration-service/cns-error-codes-reference.md

@@ -0,0 +1,91 @@
+# CNS Error Codes (Connection Service)
+
+Connection Service — the Integration Service component that stores and resolves **connections, connectors, and triggers** — stamps a structured `CNS<code>` error code on every API failure. These are distinct from the `DAP-…` codes ([dap-error-codes-reference.md](./dap-error-codes-reference.md)): DAP codes come from the **connector activity runtime** on the robot; CNS codes come from the **Connection Service HTTP API** that the runtime, the portal UI, Maestro, and other UiPath services call. A single incident often carries both — e.g. a runtime `DAP-GE-3000` whose underlying service call failed with `CNS1006`. **When a CNS code is visible, prefer it — it is the more specific signal.**
+
+## Wire format
+
+Every failed Connection Service API call returns:
+
+```json
+{ "code": "CNS1045", "message": "<user-facing text>", "traceId": "<W3C trace id>" }
+```
+
+- `code` — the stable CNS error code (this catalog).
+- `message` — resolved user-facing text (safe to show; technical detail stays in service logs).
+- `traceId` — also returned as a response header; **always capture it** — it is the correlation key the owner team uses to find the request in telemetry.
+
+**Where these codes surface in RPA productivity activities:** the modern Microsoft 365 / Google Workspace activity packages resolve their Integration Service connection and fetch the OAuth token through this API at runtime — so a failing activity often carries the CNS body inside a `UiPath.ConnectionClient.Contracts.ConnectionHttpException` (raw, or quoted verbatim in the wrapped `Office365Exception`/`GSuiteException` message). The runtime token fetch is the single biggest customer-facing source of `CNS1008`/`CNS1006`/`CNS1045`. Activity-side routing lives in the [O365](../../activity-packages/o365-activities/investigation_guide.md) and [Google Workspace](../../activity-packages/gsuite-activities/investigation_guide.md) investigation guides.
+
+Code families:
+
+- **`CNS1xxx`** — client/validation errors (4xx): resolution failures, bad input, permissions, connector lifecycle, Solutions packages.
+- **`CNS2xxx`** — internal/server errors (5xx): dependency failures, plus the tenant-migration export/import family (`CNS2030`–`CNS2046`, internal tooling only).
+- **`CNS3xxx`** — governance and concurrency: `CNS3001` (policy forbidden), `CNS3002` (single-flight conflict).
+
+Status→code fallbacks: when a downstream dependency error reaches the middleware unwrapped, the status is mapped to a generic code — 503→`CNS2007`, 403→`CNS1044`, 401→`CNS1047`, 400→`CNS1048`, 404→`CNS1049`, 424→`CNS1101`, unknown→`CNS2006`, outbound timeout→`CNS2010`. These generic codes therefore say *less* than the specific ones — route on the message and failing operation too.
+
+> **⚠ Overloaded codes — never route on the code alone.** Several codes are reused across unrelated subsystems. The ones that bite:
+> - `CNS1025` "TriggerRequestInvalid" also fires from **connection** delete/rename for *"In S2S context, the folder key is required"*, and one 500-class notification branch.
+> - `CNS1001` "ConnectorKeyOrIdInvalid" is also thrown for an invalid **trigger** lookup on one path.
+> - `CNS1050` is **two different constants**: `EventModeNotSupported` (make-connection-call API) and `InvalidSolutionArchive` (corrupt Solutions package).
+> - `CNS1048`/`CNS1026` are generic catch-alls across governance, message-bus events, Solutions, and tenant lifecycle.
+> Always read the `message` and identify the failing operation before picking a playbook.
+
+## Telemetry (owner team)
+
+In the region's Connection Service App Insights (`cloud_RoleName` starts with `connection-service`):
+
+- Primary signal: `traces`/`exceptions` matching `Connection Service error reported: [StatusCode: …, ErrorCode: "CNS…", ErrorReason: "…"]`, with `customDimensions.ErrorCode` where populated. Query **both** traces and exceptions — errors logged with an exception land in `exceptions`, not `traces`.
+- Structured failure dimensions (rolling out behind the `EnableStructuredFailureTelemetry` flag): `FailureErrorCode`, `FailureDependency`, `FailureStatusCode`, `FailureIsTransient`, `FailureUserMessageKey` (e.g. `FolderAuth.403.CNS1045`), `FailureTechnicalMessage` — emitted on customEvents and a structured log line.
+- Volume triage: `union traces, exceptions | where cloud_RoleName startswith "connection-service" | extend ec = tostring(customDimensions.ErrorCode) | where ec startswith "CNS" | summarize count() by ec, bin(timestamp, 1h)`.
+
+30-day production baseline (one large region) for calibration — the top codes by volume: `CNS1005` (~97k, orphaned event callbacks — mostly benign background), `CNS1006` (~69k), `CNS1008` (~37k), `CNS1001` (~25k), `CNS1045` (~20k); everything else is under 1k/month. A code in the top five behaving at baseline is normal noise; a step change is an incident.
+
+## Fault ownership
+
+Same two-bucket discipline as the DAP codes — classify **who can fix it** first, then route:
+
+- **👤 Bucket A — customer/admin-resolvable:** wrong or deleted references, unauthenticated connections, missing folder permissions/scopes, governance policy choices, bad request payloads, Solutions package spec issues.
+- **🛠 Bucket B1 — service-side (escalate):** dependency failures (SQL, Orchestrator, Identity, message bus), event-callback processing, corrupt persisted config, connector deployment drift, stuck install pipelines.
+- **🛠 Bucket B2 — third-party provider:** `CNS1042`/`CNS1101` — the provider behind the connector is erroring or rate-limiting; wait/retry, escalate only if the provider is healthy.
+- **🔧 Internal ops tooling:** `CNS3002` and `CNS2030`–`CNS2046` — migration/backfill machinery; customers never trigger these directly.
+
+## Retry semantics
+
+Transience is derived from **status and dependency, not the code**: 408/429/502/503/504, and anything from the Db/Cache/MessageBus/Identity dependencies, is transient-classified (background flows auto-retry; interactive calls surface immediately). All other 4xx are permanent — retrying `CNS1045` or `CNS1006` will never succeed. **`CNS1075` is deliberately a non-retryable 409** so that runtime clients don't retry-loop on an unpublished connector. `CNS2010` (timeout) surfaces as 500 but is worth one retry.
+
+## Code → playbook map
+
+### 👤 Bucket A — customer/admin-resolvable
+
+| Codes | Root cause | Playbook |
+|-------|------------|----------|
+| `CNS1006` `CNS1000` `CNS1049` `CNS1003` | Connection not found from the caller's context — deleted, cross-workspace, no connections yet, stale auth session | [cs-connection-not-found.md](./playbooks/cs-connection-not-found.md) |
+| `CNS1008` `CNS1021` `CNS1061` | Connection not in authorized state — expired/revoked token, unauthenticated shell, wrong auth type | [cs-connection-not-authenticated.md](./playbooks/cs-connection-not-authenticated.md) |
+| `CNS1045` `CNS1044` `CNS1046` `CNS1047` `CNS1043` `CNS3001` | Folder permission / scope / client / governance-policy denial | [cs-permission-denied.md](./playbooks/cs-permission-denied.md) |
+| `CNS1001` `CNS1002` `CNS1004` | Connector reference wrong, missing, or disabled | [cs-connector-unavailable.md](./playbooks/cs-connector-unavailable.md) |
+| `CNS1020` `CNS1014` `CNS1025` `CNS1039` | Trigger CRUD — bad ID, delete blocked by active processes, malformed/S2S-folder-key request, bad interval | [cs-trigger-operation-failed.md](./playbooks/cs-trigger-operation-failed.md) |
+| `CNS1038` `CNS1007` `CNS1032` `CNS1033` | Duplicate name / duplicate-key create race / name validation | [cs-operation-conflict.md](./playbooks/cs-operation-conflict.md) |
+| `CNS1050` `CNS1055` `CNS1058` `CNS1059` `CNS1064` `CNS1066`–`CNS1069` `CNS1071` `CNS1072` `CNS1074` | Solutions package spec, connector-version reconciliation, shell connections | [cs-solutions-install-failed.md](./playbooks/cs-solutions-install-failed.md) |
+
+### 🛠 Bucket B1 — service-side (escalate if sustained)
+
+| Codes | Root cause | Playbook |
+|-------|------------|----------|
+| `CNS2003` `CNS2005` `CNS2006` `CNS2007` `CNS2009` `CNS2010` `CNS2012` `CNS2001` `CNS2008` `CNS1036` | A UiPath-internal dependency (SQL / Orchestrator / Identity / message bus / connector platform) failed | [cs-dependency-unavailable.md](./playbooks/cs-dependency-unavailable.md) |
+| `CNS1005` `CNS2000` `CNS1015`–`CNS1019` `CNS1024` `CNS1029` `CNS2011` | Inbound event-callback processing failed (machine-to-machine; customer sees "trigger didn't fire") | [cs-events-callback-failed.md](./playbooks/cs-events-callback-failed.md) |
+| `CNS1075` `CNS2045` | Connector deployment state broken / event catalog drift | [cs-connector-unavailable.md](./playbooks/cs-connector-unavailable.md) |
+| `CNS2004` | Persisted trigger config undeserializable | [cs-trigger-operation-failed.md](./playbooks/cs-trigger-operation-failed.md) |
+| `CNS1060` `CNS1063` `CNS1065` `CNS1056` `CNS1057` `CNS1070` | Solutions install pipeline failures | [cs-solutions-install-failed.md](./playbooks/cs-solutions-install-failed.md) |
+
+### 🛠 Bucket B2 — third-party provider
+
+| Codes | Root cause | Playbook |
+|-------|------------|----------|
+| `CNS1042` `CNS1101` | The provider behind the connector returned 5xx / rate-limited / rejected | [cs-dependency-unavailable.md](./playbooks/cs-dependency-unavailable.md) |
+
+### 🔧 Internal — no customer playbook
+
+- `CNS3002` — single-flight lock on migration/backfill jobs; ops waits or overrides ([cs-operation-conflict.md](./playbooks/cs-operation-conflict.md)).
+- `CNS2030`–`CNS2044`, `CNS2046` — tenant-migration export/import pipeline (S2S-gated internal endpoints; a customer cannot reach them). Failures here are handled by the owning ops workflow, not support triage.
+- **Defined but never thrown** (ignore if "seen" — the sighting is wrong): `CNS1051`(ConnectionCreateUpdateError twin) `CNS1052` `CNS1053` `CNS1054` `CNS1062` `CNS2033`.

package/skills/uipath-troubleshoot/references/products/integration-service/dap-error-codes-reference.md

@@ -0,0 +1,109 @@
+# DAP Runtime Error Codes (Integration Service)
+
+Integration Service emits a structured error code on every failure: `DAP-<LAYER>-<CODE>`, appended to the user message as _"Error code: DAP-RT-1101."_. Layers:
+
+- **RT** — runtime (execution failures; the agent's primary focus)
+- **GE** — general (connection / auth / migration)
+- **DT** — design time (Studio canvas; **out of scope** for runtime triage — surfaced directly to the user in Studio, never in execution telemetry)
+
+This reference maps each runtime/general DAP code to its **fault bucket** and its playbook. Classify the bucket first (who can fix it), then route to the playbook (how).
+
+## Telemetry customEvent fields
+
+At runtime the failure is also emitted as a telemetry `customEvent`. Read these fields before classifying — they are the primary evidence:
+
+| Field | Use for root-cause |
+|-------|--------------------|
+| `ErrorCode` | Numeric IS code — the primary classifier (maps to a playbook below). |
+| `ProviderErrorCode` / `ProviderErrorMessage` | The connector / 3rd-party API's own status + message (e.g. the underlying 401/403/429/5xx). **Decisive for `DAP-RT-1101`.** Its presence is also the main signal that the failure is a downstream provider response rather than an IS-side exception. |
+| `Error` | Exception type (`RuntimeException`, `GeneralException`). |
+| `ErrorMessage` | Human-readable IS message. |
+| `RequestId` | Correlation ID — trace the call to the connector. |
+| `ConnectionId` | Which connection failed (for auth / connection issues). |
+
+> **"Service error" is a classification you make, not a field to read.** There is **no `IsServiceError` field** emitted in the telemetry. Whether a failure is an *IS-side exception* (the platform/connector itself failed) or a *downstream provider response* (the third-party API returned a status) is a judgment you derive from the `ErrorCode` and message — chiefly from whether a `ProviderErrorCode` / provider status is present. Do not look for an `IsServiceError` value; decide it yourself.
+
+> If the failure surfaced through Maestro (BPMN service task), the same root cause also carries a Maestro IntSvc code (`102002`, `102003`, …). The DAP code is more specific — prefer it when present. The Maestro-keyed playbooks ([connection-invalid.md](./playbooks/connection-invalid.md), [connection-auth-expired.md](./playbooks/connection-auth-expired.md), [operation-failed.md](./playbooks/operation-failed.md), [trigger-not-firing.md](./playbooks/trigger-not-firing.md)) cover the same failures from the Maestro surface.
+
+## Fault ownership — the two-bucket decision
+
+Every IS runtime failure falls into one of two buckets. **Classify first, then explain.** Lead the user-facing answer with the bucket verdict — whether they can fix it themselves or must escalate to the owner team.
+
+### 👤 Bucket A — Customer-resolvable
+
+A configuration, credential, permission, or input problem on the customer's side. **The customer fixes it themselves.**
+
+> _Lead message:_ "This is a configuration/credential issue on your side. Here's what to change…" — then the specific fix from the playbook.
+
+### 🛠 Bucket B — Service-side (not customer-fixable → escalate)
+
+The customer cannot resolve it from their workflow. Two sub-cases:
+
+- **B1 — IS platform / connector defect** (an IS-side exception — no provider status returned): a bug in the activity pack or connector metadata. → _"This is a service-side issue, not something you can fix in your workflow. Contact the owner team (Integration Service)."_
+- **B2 — Third-party provider outage / instability** (a downstream provider response — provider status `429` or `5xx`): the upstream connector API is failing. → _"The upstream provider is rate-limiting or down. Wait and retry; escalate if sustained."_
+
+### Fast decision rule
+
+The `ErrorCode` → bucket tables below are the primary classifier — for most codes the bucket follows from the code itself. The distinction between an IS-side exception and a downstream provider response is **your classification**, derived mainly from whether a `ProviderErrorCode` / provider status is present (there is no `IsServiceError` field to read):
+
+1. **No provider status returned** (a config / connection / metadata / trigger-config / platform-token failure inside IS) → IS-side exception → take the code's bucket from the tables (**Bucket A** for the connection/input customer-config codes; **Bucket B1** for platform/connector defects).
+2. **A provider status was returned** (`ProviderErrorCode` present — e.g. `DAP-RT-1101`) → downstream provider response → read the status:
+   - **4xx auth/input** (`401` / `403` / `404` / `400` / `422`) → **Bucket A** (customer fixes it).
+   - **`429` / `5xx`** → **Bucket B2** (provider-side — wait / escalate).
+
+`DAP-RT-1101` is the catch-all that **always** needs the status-code split above.
+
+## Retry semantics
+
+IS auto-retries before surfacing a failure. Knowing this disambiguates transient vs sustained:
+
+- **Retried (max 2):** `429`, `423`, `5xx`. Token auto-refreshed on `401`.
+- **Not retried (non-transient):** `408`, `501`, `502`, `504`.
+- A `retry-exception` SRE alert means **retries were exhausted** — treat as a sustained provider/network problem (Bucket B2), not a transient blip.
+
+## Code → bucket + playbook map
+
+### 👤 Bucket A — Customer-resolvable
+
+| Code | Name | Root cause | Playbook |
+|------|------|------------|----------|
+| `DAP-GE-3000` | FailedToGetConnection | Connection deleted, inaccessible, or wrong one selected | [connection-not-resolved.md](./playbooks/connection-not-resolved.md) |
+| `DAP-GE-3005` | ConnectionDisabled | Connection is disabled | [connection-not-resolved.md](./playbooks/connection-not-resolved.md) |
+| `DAP-RT-1002` | ConnectionIdNull | No connection bound to the activity | [connection-not-resolved.md](./playbooks/connection-not-resolved.md) |
+| `DAP-RT-1003` | ArgumentIsRequired | A required input argument is missing | [missing-required-input.md](./playbooks/missing-required-input.md) |
+| `DAP-RT-1007` | PropertyIsRequired | A required property is empty | [missing-required-input.md](./playbooks/missing-required-input.md) |
+| `DAP-RT-1101` _(4xx)_ | RequestFailed — auth/input subset | Provider `401`/`403` (creds/scope), `404` (not found), `400`/`422` (bad payload) | [request-failed.md](./playbooks/request-failed.md) |
+
+### 🛠 Bucket B1 — IS platform / connector defect (escalate to owner team)
+
+Bugs in the activity pack or connector metadata; the customer cannot work around them. Typically an IS-side exception — no provider status is returned.
+
+| Code | Name | Root cause | Playbook |
+|------|------|------------|----------|
+| `DAP-RT-1000` | ActivityConfigurationNull | Corrupt/failed-to-deserialize config blob | [activity-configuration-corrupt.md](./playbooks/activity-configuration-corrupt.md) |
+| `DAP-RT-1004` | InvalidConfigurationVersion | Config schema version not understood by runtime | [activity-configuration-corrupt.md](./playbooks/activity-configuration-corrupt.md) |
+| `DAP-RT-1008` | InvalidActivityConfiguration | Activity configuration is malformed | [activity-configuration-corrupt.md](./playbooks/activity-configuration-corrupt.md) |
+| `DAP-RT-1100` | HttpMethodMissing | Generated activity has no HTTP method — incomplete connector metadata | [activity-configuration-corrupt.md](./playbooks/activity-configuration-corrupt.md) |
+| `DAP-RT-1053` | TriggerInvalidConfiguration | Trigger object name or operation null/empty — set by connector configuration, not customer-settable | [trigger-execution-failed.md](./playbooks/trigger-execution-failed.md) |
+| `DAP-RT-1001` | ServiceProviderNull | Runtime DI/service provider unavailable — internal error | [activity-configuration-corrupt.md](./playbooks/activity-configuration-corrupt.md) |
+| `DAP-GE-3004` | FailedToGetAccessToken | IS could not obtain a **first-party UiPath service** token (Orchestrator, Feature Flag service) — NOT a connection credential; often transient | [token-refresh-failed.md](./playbooks/token-refresh-failed.md) |
+| `DAP-GE-3001` | InvalidMigration | Activity failed to migrate to a newer schema version | [activity-configuration-corrupt.md](./playbooks/activity-configuration-corrupt.md) |
+| `DAP-RT-1005` | ApiResponseMismatch | Response shape ≠ activity output type — connector schema drift | [response-mapping-mismatch.md](./playbooks/response-mapping-mismatch.md) |
+| `DAP-RT-1155` `DAP-RT-1156` | DataTableFieldTypeMismatch / TypedDataTableNotConstructedProperly | Output couldn't map into the expected TypedDataTable | [response-mapping-mismatch.md](./playbooks/response-mapping-mismatch.md) |
+
+### 🛠 Bucket B2 — Third-party provider outage / instability (wait / escalate)
+
+A downstream provider response with status `429` or `5xx`, or a network-level failure. Not an IS bug and not customer-fixable.
+
+| Code | Name | Root cause | Playbook |
+|------|------|------------|----------|
+| `DAP-RT-1101` _(429/5xx)_ | RequestFailed — provider subset | Provider `429` (rate limited) or `5xx` (outage); `ProviderErrorCode` confirms | [request-failed.md](./playbooks/request-failed.md) |
+| `DAP-RT-1103` | HttpClientException | Network-level failure — UiPath IS endpoint unreachable from the robot (DNS/connectivity/firewall) | [http-client-exception.md](./playbooks/http-client-exception.md) |
+| `DAP-RT-1051` | TriggerExecutionFailed | Trigger evaluation call failed/empty — connector trigger endpoint issue | [trigger-execution-failed.md](./playbooks/trigger-execution-failed.md) |
+| `DAP-RT-1050` | TriggerDataMissing | Event payload missing expected event ID — malformed webhook/poll payload | [trigger-execution-failed.md](./playbooks/trigger-execution-failed.md) |
+
+> **Debug-only, never at runtime:** `DAP-RT-1052` (TriggerNoMatches) — emitted only when a project is executed in **debug mode** (the trigger filter matched zero events). It does **not** appear in runtime execution telemetry, so it is out of scope for runtime triage. See [trigger-execution-failed.md](./playbooks/trigger-execution-failed.md).
+
+### Design-time (DT) — out of scope
+
+`DAP-DT-2000`–`2349` (metadata fetch failures, unsupported activity/method, object-not-found, duplicate fields, …) fire in Studio while building a workflow and block the canvas. They do **not** appear in runtime execution telemetry. Do not author runtime playbooks for DT codes — they are surfaced to the user directly in Studio.

package/skills/uipath-troubleshoot/references/products/integration-service/overview.md

@@ -2,6 +2,10 @@
 
 Connector platform that provides pre-built integrations with third-party services (Salesforce, Outlook, SAP, Slack, etc.). Manages OAuth connections, exposes activities for use in automations and BPMN processes, and provides event-based triggers.
 
+> **Runtime errors carry a DAP code.** Every IS execution failure surfaces a structured `DAP-<LAYER>-<CODE>` code (e.g. `DAP-RT-1101`) plus a telemetry `customEvent`. When triaging a failure that carries a `DAP-…` code, start at [dap-error-codes-reference.md](./dap-error-codes-reference.md) — it maps each code to its **fault bucket** (👤 customer-resolvable vs 🛠 service-side/escalate) and its playbook, and lists the customEvent fields to read. **Classify the bucket first** (from the DAP code + whether a provider status is present — "service error" is your judgment, not a telemetry field), then route to the playbook.
+
+> **Service API errors carry a CNS code.** The Connection Service HTTP API (connections/connectors/triggers CRUD — called by the portal UI, the connector runtime, Maestro, and other UiPath services) returns `{ "code": "CNS…", "message": "…", "traceId": "…" }` on every failure. Start at [cns-error-codes-reference.md](./cns-error-codes-reference.md) for the code → bucket → playbook map. A runtime failure often carries both codes (e.g. `DAP-GE-3000` wrapping `CNS1006`) — **the CNS code is the more specific signal; prefer it when present.**
+
 Integration Service is used by both Orchestrator (standalone automations) and Maestro (BPMN service tasks). Connection failures here surface as errors in whichever product initiated the call.
 
 ## Organization Model
@@ -46,12 +50,14 @@ Projects and solutions store connection references as JSON files. The location d
 | Layout | Path pattern |
 |--------|--------------|
 | Standalone project | `<project-root>/connection/<connector-key>/<owner>.json` |
-| Solution (single folder) | `<project-root>/resources/solution_folder/connection/<connector-key>/<owner>.json` |
-| Solution (multi-folder) | `<project-root>/resources/<folder-name>/connection/<connector-key>/<owner>.json` |
+| Solution (single folder) | `<solution-root>/resources/solution_folder/connection/<connector-key>/<owner>.json` |
+| Solution (multi-folder) | `<solution-root>/resources/<folder-name>/connection/<connector-key>/<owner>.json` |
+
+> In a solution, `resources/` sits at the **solution root, beside the project folder** — not inside it. A glob rooted at the project folder will miss it; search the project folder's parent as well.
 
 Each `<connector-key>` subfolder contains one JSON file per connection, named after the connection's `resource.name` (typically the owner's email or username).
 
-**When investigating, glob `**/connection/<connector-key>/*.json` from the project root** — that catches all three layouts in one read. Do NOT assume the standalone path; solutions are common and the resource file may be several directories deep under `resources/`.
+**When investigating, glob `**/connection/<connector-key>/*.json` from the working-directory root** (the solution root when the project sits in a solution) — that catches all three layouts in one read. Do NOT assume the standalone path; solutions are common and the resource file may be several directories deep under `resources/`.
 
 Key fields:
 

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/activity-configuration-corrupt.md

@@ -0,0 +1,52 @@
+---
+confidence: medium
+---
+
+# Activity Configuration Corrupt (DAP-RT-1000 / 1001 / 1004 / 1008 / 1100 / DAP-GE-3001)
+
+> **Fault bucket: 🛠 B1 — IS platform / connector defect (escalate to owner team).** The activity pack or connector metadata is malformed, unversioned, or failed to migrate — the customer cannot fix the underlying defect in their workflow. Lead with: "This is a service-side issue (connector/activity-pack defect), not something you can fix in your workflow — contact the owner team (Integration Service)." Where a package downgrade or re-migration is available, offer it as an interim workaround, not the fix. See [dap-error-codes-reference.md](../dap-error-codes-reference.md#fault-ownership--the-two-bucket-decision).
+
+## Context
+
+What this looks like — the activity's stored configuration is incomplete, null, unversioned, or failed to migrate, so IS cannot build the request:
+
+| Code | Name | Specific cause |
+|---|---|---|
+| `DAP-RT-1000` | ActivityConfigurationNull | Activity configuration is null/empty — corrupt or failed-to-deserialize config blob |
+| `DAP-RT-1001` | ServiceProviderNull | Runtime DI/service provider not available — internal runtime error |
+| `DAP-RT-1004` | InvalidConfigurationVersion | Config schema version not understood by the runtime |
+| `DAP-RT-1008` | InvalidActivityConfiguration | Activity configuration is malformed |
+| `DAP-RT-1100` | HttpMethodMissing | Activity built without an HTTP method — incomplete connector metadata |
+| `DAP-GE-3001` | InvalidMigration | Activity failed to migrate to a newer connector schema version |
+
+What can cause it (cause IDs map to Resolution steps below):
+- **CA001** — Activity package upgraded and the old configuration didn't migrate cleanly (`3001`, `1000`, `1004`)
+- **CA002** — Connector metadata generated incomplete — no HTTP method, malformed schema (`1100`, `1008`)
+- **CA003** — Project/package corruption during publish or merge — the config blob is empty or malformed (`1000`)
+- **CA004** — Internal runtime fault — service provider not constructed (`1001`)
+
+What to look for:
+- No `ProviderErrorCode` / provider status — the failure is IS-side, before any provider call (the signal that this is **Bucket B1**; "service error" is your classification, not a field)
+- `ProviderErrorCode` and `ConnectionId` are typically absent — nothing reached the connection layer
+- Whether the failure started immediately after an activity package upgrade (points to a migration code — `3001`/`1004`)
+
+## Investigation
+
+1. **Confirm it is config-layer, not connection or provider** — no `ProviderErrorCode` / provider status. The connection ping is healthy; the problem is the activity definition / connector metadata.
+2. **Read the workflow source** — open the failing activity in the project. Verify the configuration blob is present and complete:
+   - **`DAP-RT-1100`:** check the HTTP method is set on the activity (`CA002`).
+   - **`DAP-RT-1000` / `1008`:** check the activity's configuration is not empty/null/malformed (`CA002`/`CA003`).
+3. **Check for a recent package upgrade** — compare the activity package version against the project history. A migration code (`3001`/`1004`) indicates a migration the package could not complete (`CA001`).
+4. `uip is activities list <connector-key>` — confirm the activity still exists and is supported in the installed package version.
+
+## Resolution
+
+**Primary: escalate.** These are connector/activity-pack defects on the IS side. Report the `DAP` code, `RequestId`, connector key, and package version to the Integration Service owner team. The customer cannot resolve the underlying defect from their workflow.
+
+Interim workarounds (try while the escalation is open, where applicable):
+
+- **`CA002` — `DAP-RT-1100` / `1008`:** open the activity and set the HTTP method / reconfigure the operation, then republish. If the connector metadata itself is incomplete, this only works if the field is settable in Studio — otherwise escalate.
+- **`CA003` — `DAP-RT-1000`:** re-create the activity from a clean state — delete and re-add it, reconfigure inputs, republish. If project corruption is suspected, restore from source control.
+- **`CA001` — migration codes (`DAP-GE-3001`, `DAP-RT-1004`):** re-open the project in Studio to run the activity migration, or downgrade to the previous connector package version if migration cannot complete; then re-validate and republish.
+- **`CA004` — `DAP-RT-1001` (ServiceProviderNull):** no customer workaround — internal runtime error. Escalate with the `RequestId`.
+- After any workaround, re-run to confirm the config-layer error clears before checking for downstream provider errors.

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/connection-invalid.md

@@ -26,9 +26,9 @@ What to look for:
 
 ## Investigation
 
-> **Hard precondition for steps 2–4:** before running any CLI command or drawing any conclusion, you MUST complete step 1 — either read the connection resource file or explicitly record that no project source is available. CLI evidence (`ping` returning 404, empty `connections list`) is **not sufficient** to distinguish "deleted connection" from "cross-workspace ownership"; only the resource file disambiguates them. Skipping step 1 makes any conclusion at step 2/3 ambiguous and forces the depth-verifier to reject the hypothesis.
+> **Hard precondition for steps 2–4:** before running any CLI command or drawing any conclusion, you MUST complete step 1 — either read the connection resource file or explicitly record that no project source is available. CLI evidence (`ping` returning 404, empty `connections list`) is **not sufficient** to distinguish "deleted connection" from "cross-workspace ownership"; only the resource file disambiguates them. Skipping step 1 makes any conclusion at step 2/3 ambiguous and fails the verification checklist.
 
-1. **Read the connection resource file** — if source code is available, glob `**/connection/<connector-key>/*.json` from the project root to handle all project layouts (standalone, single-folder solution, multi-folder solution — see "Connection Resource File" in [overview.md](../overview.md)). If multiple files match, pick the one whose `resource.key` matches the connection ID in the error. From the file, extract every one of:
+1. **Read the connection resource file** — if source code is available, glob `**/connection/<connector-key>/*.json` from the investigation working directory; if the project folder is inside a solution, ALSO glob from the project folder's **parent** — in a solution, `resources/` sits at the solution root beside the project folder (see "Connection Resource File" in [overview.md](../overview.md) for all layouts). Only after both globs return zero may the resource file be marked absent. If multiple files match, pick the one whose `resource.key` matches the connection ID in the error. From the file, extract every one of:
    - `spec.connectorName` — the exact display name to use in findings (do NOT guess from the activity package name)
    - `spec.connectorKey` — for CLI queries
    - `resource.name` — the **connection owner**. If this is an email, the connection lives in that user's personal workspace; if it differs from the runner's identity, the connection is cross-workspace.

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/connection-not-resolved.md

@@ -0,0 +1,47 @@
+---
+confidence: high
+---
+
+# Connection Not Resolved (DAP-GE-3000 / DAP-GE-3005 / DAP-RT-1002)
+
+> **Fault bucket: 👤 A — Customer-resolvable.** A connection/binding/permission problem on the customer's side (deleted, disabled, unbound, or wrong-folder connection). Lead with: "This is a connection configuration issue on your side — here's what to reselect/re-enable/rebind." See [dap-error-codes-reference.md](../dap-error-codes-reference.md#fault-ownership--the-two-bucket-decision).
+
+## Context
+
+What this looks like — three related codes, all meaning IS could not resolve a usable connection before calling the provider:
+
+| Code | Name | Specific cause |
+|---|---|---|
+| `DAP-GE-3000` | FailedToGetConnection | Connection could not be retrieved — deleted, inaccessible, or wrong connection selected |
+| `DAP-GE-3005` | ConnectionDisabled | Connection exists but is disabled; user must re-enable it |
+| `DAP-RT-1002` | ConnectionIdNull | No connection ID on the activity — unconfigured or broken binding |
+
+What can cause it (cause IDs map to Resolution steps below):
+- **CA001** — Connection was deleted or renamed after the process was published (`3000`)
+- **CA002** — Connection is in a different user's personal workspace or a folder the runner cannot reach (`3000`)
+- **CA003** — Runner's robot account lacks permission on the folder holding the connection (`3000`)
+- **CA004** — Connection was manually disabled, or auto-disabled after repeated auth failures (`3005`)
+- **CA005** — Activity has no connection bound — published without selecting a connection, or the binding was lost in migration (`1002`)
+
+What to look for:
+- `ConnectionId` in the customEvent — present for `3000`/`3005`, **null/absent for `1002`** (that absence is itself the diagnosis)
+- Whether the failure is debug-only (runs under user identity) or deployed (runs under robot account — may lack folder permission)
+
+> The Maestro-surfaced view of the same root causes is [connection-invalid.md](./connection-invalid.md) ("connection is invalid or you do not have access"). Prefer this playbook when a DAP code is present.
+
+## Investigation
+
+1. **Read the connection resource file** — if source code is available, glob `**/connection/<connector-key>/*.json` from the project root (see "Connection Resource File" in [overview.md](../overview.md)). Extract `resource.key` (connection ID), `resource.name` (owner), `resource.folders[*].fullyQualifiedName` (binding), and `spec.connectorName`.
+2. Branch on the code:
+   - **`DAP-RT-1002` (ConnectionIdNull):** confirm the activity in the workflow source has no `ConnectionId`/`ConnectionKey` bound. The fix is re-binding, not connection health — skip the ping checks.
+   - **`DAP-GE-3000` (FailedToGetConnection):** `uip is connections list <connector-key> --folder-key <folder-key>` — check whether the connection exists in the runner's folder. Compare the resource file's `resource.folders` and `resource.name` against the runner's job folder/identity to distinguish "deleted" from "cross-workspace / wrong folder."
+   - **`DAP-GE-3005` (ConnectionDisabled):** `uip is connections ping <connection-id>` — confirm it resolves but reports disabled.
+3. **Caller identity** — determine whether the failure is in debug (user) or deployed (robot account) mode. A robot account may lack `Connections.View` in the connection's folder even when the connection exists.
+
+## Resolution
+
+- **`CA005` — `DAP-RT-1002`:** open the activity, select the correct connection, and republish. If lost during package migration, re-bind every affected activity.
+- **`CA001` — `DAP-GE-3000`, connection missing in folder:** create a connection using the exact `connectorName` from the resource file; if `authenticationType` is `AuthenticateAfterDeployment`, authenticate it after creating.
+- **`CA002` — `DAP-GE-3000`, cross-workspace / wrong folder:** create a connection in the runner's workspace (or a shared folder for shared processes), update the workflow to reference its ID, and republish.
+- **`CA003` — `DAP-GE-3000`, robot lacks permission:** grant the robot account at least `Connections.View` in the folder where the connection resides.
+- **`CA004` — `DAP-GE-3005`:** re-enable the connection in the Integration Service UI. If it was auto-disabled after auth failures, re-authenticate first (see [connection-auth-expired.md](./connection-auth-expired.md)) or it will disable again.

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/connector-general-exception.md

@@ -8,7 +8,7 @@ confidence: high
 
 What this looks like — robot exception `UiPath.IntegrationService.Activities.Runtime.Exceptions.GeneralException` with a `DAP-GE-` error code. The job faults at the moment the connector activity tries to resolve its connection (before the external API is called). The message carries the code:
 
-- `Failed to retrieve connection. Consider using a different connection. Error code: DAP-GE-3000.` — and a `-`-delimited detail that names the real cause:
+- `Failed to retrieve connection. Consider using a different connection. Error code: DAP-GE-3000.` — this base sentence (including "Consider using a different connection") is **generic boilerplate that appears on EVERY DAP-GE-3000 regardless of sub-cause**. It is NOT evidence that the connection was deleted or is broken — do not diagnose from it. The `-`-delimited detail that follows the code is the classifier that names the real cause:
   - `- Connection [<id>] is invalid or you do not have access to it` — connection missing, deleted, or not accessible from the runner's identity/workspace.
   - `- User '<user-id>' does not have Connections.View permissions in [Connection: <id>]` — RBAC: the runner (robot account in deployed mode) lacks `Connections.View` in the folder where the connection lives.
   - `- Bad Gateway` (or other upstream text) — Integration Service / Identity returned a 5xx while resolving the connection.
@@ -40,4 +40,4 @@ The error code already names the cause class; the remaining work is confirming o
 - **DAP-GE-3005 (disabled):** re-enable the connection in the Integration Service UI (or `uip is connections edit <connection-id>`). If it auto-disabled, re-authenticate — see [connection-auth-expired.md](./connection-auth-expired.md).
 - **DAP-GE-3000, invalid / no access / cross-workspace:** this is the activity-side surfacing of [connection-invalid.md](./connection-invalid.md) — follow its Resolution (create a connection in the runner's workspace and repoint the activity, or deploy to a shared folder with a shared connection).
 - **DAP-GE-3000, Connections.View:** grant the robot account at least `Connections.View` in the folder where the connection resides, **or** move/recreate the connection in a folder the robot can access (the runtime message names the connection's folder GUID and states both options verbatim).
-- **DAP-GE-3000, Bad Gateway / 5xx:** transient platform error — retry the job. If it persists, check Integration Service / Identity status before treating it as a config problem.
+- **DAP-GE-3000, Bad Gateway / 5xx:** transient platform error — retry the job. Do NOT recreate the connection, re-bind folders, or re-publish: the connection is fine, only the platform's resolution call momentarily failed. If it persists, check Integration Service / Identity status before treating it as a config problem.

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/cs-connection-not-authenticated.md

@@ -0,0 +1,46 @@
+---
+confidence: high
+---
+
+# Connection Service — Connection Not in Authorized State (CNS1008, CNS1021, CNS1061)
+
+> **Fault bucket: 👤 A — customer-resolvable.** The connection exists and the caller can see it, but it is **not in a usable authentication state**: its OAuth token expired or was revoked, it was created but never authenticated, or an operation was attempted that its auth type cannot serve. The fix is re-authenticating (or correctly configuring) the connection. This is the service-API sibling of the Maestro-surfaced [connection-auth-expired.md](./connection-auth-expired.md) — use that playbook's token-expiry investigation flow; this page adds the CNS code semantics.
+
+## Context
+
+What this looks like:
+- HTTP `400` from Connection Service when a caller asks for the connection's access token or tries to use/enable something bound to it
+- Error body `{ "code": "CNS1008", "message": "…", "traceId": "…" }` — the `CNS1008` message often embeds the raw provider auth-failure JSON
+- Runtime symptom: activities that previously worked start failing at the token step; enabling a trigger fails with "State update of trigger … is not allowed"
+
+| Code | Name | Exact meaning | HTTP |
+|------|------|---------------|:---:|
+| `CNS1008` | ConnectionStatusInvalid | Token acquisition failed because the connection is not in the *authorized* state — expired/revoked OAuth grant, failed refresh, or never authenticated | 400 |
+| `CNS1021` | ConnectionAuthTypeUnsupported | The connection's authentication type cannot serve an access-token request (e.g. a non-OAuth connection asked for an OAuth token) | 400 |
+| `CNS1061` | TriggerOnInvalidConnectionError | Attempt to enable/update a **trigger** whose underlying connection is not active — the trigger is fine; the connection is the problem | 400 |
+
+What can cause it:
+- The third-party provider expired or revoked the refresh token (password change, admin revocation, provider-side session policies)
+- The connection was created via a Solutions package with "authenticate after deployment" and nobody authenticated it yet
+- A bring-your-own-app OAuth configuration changed (client secret rotated) so refresh now fails
+- `CNS1021`: an automation or API client requests a bearer token from a connection using PAT/basic/API-key auth — a design mismatch, not a degradation
+
+What to look for:
+- The connection's status in the Integration Service UI (Failed / needs attention vs Connected)
+- Whether the failure started at a point in time after working fine (token expiry/revocation) vs never worked (unauthenticated shell / wrong auth type)
+- For `CNS1061`: which connection the trigger is bound to — the error names the trigger, but the connection is what needs fixing
+
+## Investigation
+
+1. **Ping the connection** (`uip is connections ping <connection-id>` or the UI's check) — a failed ping with `CNS1008` confirms the auth state; no need to dig further before re-authenticating.
+2. **Check the connection's state and auth type** in the tenant's Integration Service → Connections page. A "Failed" state with a re-authenticate action is the expected signature for `CNS1008`.
+3. **For `CNS1061`**: resolve the trigger → connection binding first (the trigger detail page names the connection), then treat it as `CNS1008` on that connection.
+4. **For `CNS1021`**: this is not transient and re-auth won't change it — identify *what is requesting a token* from a connection whose auth type doesn't issue tokens. Usually a wrong connection was selected for an activity/integration that requires OAuth.
+5. **If re-auth fails immediately again**, follow [connection-auth-expired.md](./connection-auth-expired.md) — provider-side app configuration (redirect URI, rotated secret, revoked app consent) is the usual cause; for bring-your-own-app setups verify the OAuth app config matches on both authorize and token-exchange legs.
+
+## Resolution
+
+- **`CNS1008`:** re-authenticate the connection from the Integration Service UI (or complete first-time authentication for shell connections deployed via Solutions). Then re-run the failed job / re-enable the trigger.
+- **`CNS1061`:** re-authenticate (or replace) the underlying connection, then retry the trigger state change. Enabling the trigger before fixing the connection will keep failing.
+- **`CNS1021`:** switch the consumer to a connection whose auth type supports the operation (typically OAuth), or recreate the connection with the correct authentication type. There is nothing to "repair" on the existing connection.
+- **Escalate only** if a freshly re-authenticated, Connected-state connection still returns `CNS1008` on token acquisition — that points at a token-persistence/refresh defect on the service side; provide the `traceId` and connection ID.

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/cs-connection-not-found.md

@@ -0,0 +1,53 @@
+---
+confidence: high
+---
+
+# Connection Service — Connection Not Found / Invalid (CNS1006, CNS1000, CNS1049, CNS1003)
+
+> **Fault bucket: 👤 A — customer-resolvable.** The caller asked Connection Service for a connection that does not exist *from the caller's context*: wrong ID, deleted connection, a connector with no connections yet, a connection living in someone else's personal workspace, or a folder the caller cannot see. The fix is on the customer's side — create/select the right connection or move it where the runner can reach it. This is the **service-API view** of the same failure the connector activity surfaces as `DAP-GE-3000` — the full workspace/folder disambiguation procedure in [connection-not-resolved.md](./connection-not-resolved.md) and [connection-invalid.md](./connection-invalid.md) applies; this page adds the exact CNS code semantics.
+
+## Context
+
+What this looks like:
+- HTTP `404` (occasionally `400`) from a Connection Service API call, error body `{ "code": "CNS1006", "message": "Connection [<guid>] is invalid or you do not have access…", "traceId": "…" }`
+- At runtime it usually reaches the user wrapped by the activity layer (`DAP-GE-3000` "Failed to retrieve connection") or by Maestro (IntSvc `102002`/`102008`)
+
+Code semantics — these are NOT interchangeable:
+
+| Code | Name | Exact meaning | HTTP |
+|------|------|---------------|:---:|
+| `CNS1006` | ConnectionIdInvalid | The specific connection ID does not exist **or the caller has no access to it** — deleted, wrong tenant, or cross-workspace | 404 / 400 |
+| `CNS1000` | ConnectionForConnectorNotFound | The connector exists but has **zero connections** in the caller's scope ("Connector [x] does not have any connections") — hit on the *default-connection* lookup | 404 |
+| `CNS1049` | NotFound | Generic not-found; the notable specific case: the connection lives on a **personal workspace** that is not shared with the caller ("Connection '…' is on a personal folder…"). Also used as passthrough when a downstream dependency 404s. | 404 |
+| `CNS1003` | SessionIdInvalid | The OAuth **authentication session** (create/re-auth flow) is stale or expired — not the connection itself | 404 |
+
+What can cause it:
+- The connection was deleted (or its folder was) after a process/trigger was configured against it
+- The process was published with a connection from the author's **personal workspace**; the runner (robot account) cannot see it → `CNS1049`/`CNS1006`
+- Automation references a hard-coded connection ID from a different tenant/environment (e.g. dev → prod promotion without rebinding)
+- `CNS1000`: an activity or API asked for a "default connection" for a connector nobody has connected yet in that tenant/folder
+- `CNS1003`: the user left an OAuth consent window open too long, or retried a stale create-connection session — harmless, just restart the flow
+
+What to look for:
+- The connection GUID in the message — search it in the tenant's Integration Service UI and across folders
+- Whether the caller is a robot account (deployed run) vs the user (debug) — access differs
+- Whether the same GUID works from the author's account (points at workspace/folder scoping, not deletion)
+
+## Investigation
+
+1. **Extract the connection ID and caller identity** from the error (`traceId` body field correlates the request). Determine whether the caller was a user, a robot account, or an S2S client.
+2. **Follow the ownership procedure from [connection-invalid.md](./connection-invalid.md)** — read the project's connection resource file (`**/connection/<connector-key>/*.json`), extract `resource.name` (owner) and `resource.folders` (binding), and compare against the runner's folder. That procedure is authoritative for disambiguating *deleted* vs *cross-workspace* vs *wrong folder*.
+3. **Map the code to the scenario:**
+   - `CNS1000` → nothing to hunt for; no connection exists for that connector in scope. Create one.
+   - `CNS1049` with the personal-folder message → the connection exists but lives in a personal workspace; sharing/moving is the fix, not recreating.
+   - `CNS1006` → the ID itself doesn't resolve for the caller; distinguish deleted vs cross-tenant vs no-access via step 2.
+   - `CNS1003` → ignore the connection entirely; the *authentication session* expired. Retry the connect/re-auth flow from the start.
+4. **If the caller lacks access but the connection exists**, check folder permissions next — a FolderAuth 403 surfaces as a different code (`CNS1045`, see [cs-permission-denied.md](./cs-permission-denied.md)); a 404 here means the folder scoping itself hides the connection.
+
+## Resolution
+
+- **Deleted / never existed:** create a new connection for the connector in the folder where the automation runs, and rebind the activity/trigger to it.
+- **Personal-workspace connection (`CNS1049`):** move the connection to a shared folder the robot can access, or recreate it in the correct folder. Do not publish processes bound to personal-workspace connections for unattended runs.
+- **`CNS1000` on default-connection lookup:** create at least one connection for the connector in that tenant/folder (and mark it default if the flow relies on the default).
+- **`CNS1003`:** restart the connection creation / re-authentication flow; the session token is single-use and short-lived. No escalation needed unless it repeats immediately on a fresh attempt.
+- **Escalate only** when the connection verifiably exists in the right folder with the right permissions and `CNS1006` still fires — then it is a resolution defect; hand the owner team the `traceId`, connection ID, and caller identity.

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/cs-connector-unavailable.md

@@ -0,0 +1,48 @@
+---
+confidence: high
+---
+
+# Connection Service — Connector Unavailable (CNS1001, CNS1002, CNS1004, CNS1075, CNS2045)
+
+> **Fault bucket: 👤 A for `CNS1001`/`CNS1002`/`CNS1004` (wrong/missing/disabled connector — customer fixes the reference or enables the connector) · 🛠 B1 for `CNS1075`/`CNS2045` (the connector's deployment state on the platform side is broken — escalate).** The *connector* (the integration template) is the problem here, not any connection. If the error names a connection GUID instead of a connector key, you are in [cs-connection-not-found.md](./cs-connection-not-found.md), not this page.
+
+## Context
+
+What this looks like:
+- HTTP `404`/`400` (or `409` for `CNS1075`) from Connection Service, message naming a **connector key**, e.g. *"Connector [uipath-atlassian-bitbucket] is invalid"*
+- Automations or API calls referencing a connector by key/ID fail before any connection is touched
+
+| Code | Name | Exact meaning | HTTP | Bucket |
+|------|------|---------------|:---:|:---:|
+| `CNS1001` | ConnectorKeyOrIdInvalid | The connector key/ID does not resolve in this tenant — typo, not-installed custom connector, or deprecated key. ⚠ Also **reused** for an invalid *trigger* lookup on one path — read the message. | 404 (400 on favourites paths) | 👤 A |
+| `CNS1002` | ConnectorKeyOrIdMissing | Create-connection request omitted the connector | 400 | 👤 A |
+| `CNS1004` | ConnectorDisabled | Connector exists but is disabled in the tenant | 400 | 👤 A (admin) |
+| `CNS1075` | ConnectorNotDeployed | The connector's backing deployment was unpublished/superseded on the platform — the connection references a connector build that is no longer live. Deliberately surfaced as **409, non-retryable**. | 409 | 🛠 B1 |
+| `CNS2045` | ConnectorDoesNotExist | Event-configuration flow could not find the connector element / valid event type for a connection ("Invalid event type shell received") | 400 | 🛠 B1 |
+
+What can cause it:
+- Hard-coded connector keys promoted across tenants/environments where the (custom) connector isn't installed
+- A custom connector was deleted or renamed while automations still reference it
+- Admin disabled the connector, or a governance policy did (a governance block is `CNS3001` — see [cs-permission-denied.md](./cs-permission-denied.md))
+- `CNS1075`: a connector publish/unpublish race on the platform — the tenant's connection points at a connector version no longer deployed. Known after custom-connector re-publish flows.
+- `CNS2045`: connector catalog drift — an event type or element referenced by an existing trigger/connection no longer exists in the connector's current version
+
+What to look for:
+- The connector key in the message — check the tenant's Integration Service → Connectors catalog for exactly that key
+- Whether the connector is a **custom** connector (customer-built keys) vs a UiPath first-party key — custom keys explain cross-tenant not-found
+- For `CNS1075`: whether a custom-connector publish/import happened recently in the tenant
+
+## Investigation
+
+1. **Confirm the connector's presence**: open the tenant's connector catalog (or `uip is connectors list` where available) and search the exact key from the message. Present → move to state checks; absent → the reference is stale/wrong.
+2. **`CNS1004`**: connector present but disabled — identify who/what disabled it (tenant admin action or policy). If the intent is to use it, enable it; if the disable was a policy, route to governance.
+3. **`CNS1075`**: do not advise retrying — the 409 is deliberately non-retryable. Verify whether the connector shows as published in the catalog. This state means platform-side deployment metadata and the connection disagree; collect the connection ID, connector key, and `traceId`.
+4. **`CNS2045`**: identify the trigger/connection whose event configuration references the missing element or event type, and whether the connector was recently upgraded — the event type may have been removed between versions.
+5. **The `CNS1001`-on-trigger trap**: if the failing operation is a *trigger* lookup and the message doesn't mention a connector, the code was reused for "trigger not found" — triage as [cs-trigger-operation-failed.md](./cs-trigger-operation-failed.md).
+
+## Resolution
+
+- **`CNS1001`/`CNS1002`:** fix the connector reference — install the custom connector in the target tenant, correct the key, or rebind the automation to an existing connector. For environment promotions, make connector installation part of the deployment checklist.
+- **`CNS1004`:** tenant admin enables the connector (Integration Service → Connectors), or the automation moves off a deliberately disabled connector.
+- **`CNS1075`:** escalate to the Integration Service owner team with the connector key, connection ID, and `traceId` — republishing the connector version or repairing the deployment mapping is a platform action. If the customer owns the custom connector, re-publishing the connector version from their side often restores the mapping.
+- **`CNS2045`:** if a connector upgrade removed the event type, recreate the trigger against a currently supported event type; if nothing changed on the customer side, escalate as connector-catalog drift.