fix: route v4 endpoints to objectName (#ENGCE-61098)

[mrstark14]

Why

Both references said a 4.0.0 (v4) connector activity is addressed by its activity name. The CLI addresses it by object name — and always has. The flag's own help text says so:

--activity-version <version>
  Activity metadata version: 1.0.0 (default, v3 elements endpoints, connection-scoped)
  or 4.0.0 (v4 elements endpoints, not connection-scoped). Both are addressed by object name.

integrationservice-tool/src/commands/resources.ts:756

The describe handler is explicit — there is no v4 branch on the positional at all:

// The positional is the object name for both 1.0.0 and 4.0.0.
const resourceName = objectName;

resources.ts:793

And the command's own built-in example passes an object name (resources.ts:94):

uip is resources describe uipath-salesforce-slack add_users_to_usergroup --activity-version 4.0.0

An agent following the old docs derived the positional from the node type's activity-name suffix (add-users-to-user-group-beta-) instead of add_users_to_usergroup, so describe missed and the node was configured from no metadata.

What

File	Change
uipath-platform/.../resources.md § --activity-version	Resource argument and cache key are the object name for v4, not the activity name. Dropped the "4.0.0 metadata has no objectName" claim — it does have one.
uipath-maestro-flow/.../connector/impl.md § 4.0.0 Activities, Step 3	Same correction for delta 2 and the Step 3 describe blockquote; delta 1 rewritten (below).

Delta 1 — where the objectName actually comes from

The v4 objectName is real, but it is not in model.context[], and it is not passed in --detail. configureActivity branches before the normal objectName resolution and reads it off the definition's configuration JSON:

const isV4Activity = isV4ActivityConfiguration(instanceParameters);
if (isV4Activity) {
    if (typeof instanceParameters.objectName !== "string" || !instanceParameters.objectName) {
        throw new InvalidDetailError(`"${node.type}" is a 4.0.0 activity but its definition's
            configuration carries no objectName — the local registry copy may be stale. …`);
    }
    objectName = instanceParameters.objectName;
} else {
    objectName = resolveObjectName(/* the --detail.objectName path */);
}

flow-tool/src/services/connector-service.ts:1336-1348

The v4 manifest declares the context entry with no value — which is exactly why the v4 path reads the configuration blob:

{ name: "objectName", type: "string" },   // connector-service.spec.ts:472

and the test states the contract directly:

configures without --detail.objectName, fetching metadata from the v4 endpoint by object name
connector-service.spec.ts:557

So delta 1 now says: read configuration.objectName; it is the describe positional; do not pass it in --detail; if it is absent the registry copy is stale (registry pull --force, drop the definitions[] entry, re-add).

Verification

Grepped both files — no activityName / activity-name remains in a v4 addressing context. The one surviving <activity-name> (impl.md:60) is the node-type suffix uipath.connector.<key>.<activity-name>, a different thing and correct as written.

Deliberately out of scope

Pre-existing v4 gaps this PR does not touch, all verified against the CLI:

• is resources describe --field is a hard exit-1 with --activity-version 4.0.0 (resources.ts:810-820), but impl.md Step 3a still tells the agent to run it whenever an api-type ObjectAction is present.
• node configure rejects --detail.filter (connector-service.ts:1443) and customFieldsRequestDetails (:1448) for v4; Steps 6a/6c present both unconditionally.
• detail.activityContext = { version, scriptRef } (connector-service.ts:1374) — the v4 stand-in for detail.objectName — is absent from the inputs.detail field list.
• resources.md: v4 cache entries land under the no-connection key (<connector-key>/_static/<object-name>.v4.schema.json); --connection-id is warned-and-ignored for v4, against the section's blanket "Always pass --connection-id"; and --activity-version exists only on describe, not on resources list / resources run.

[github-actions]

Claude finished @mrstark14's task in 2m 17s —— View job

---

Summary

Corrects v4 (4.0.0) connector activity documentation in two skill reference files: the describe positional argument for v4 activities is objectName (not activityName), and the cache key uses <object-name>.v4.schema.json. The maestro-flow delta item 1 is rewritten with clearer recovery guidance when objectName is missing from the configuration.

Change-by-Change Review

1. skills/uipath-maestro-flow/references/author/plugins/connector/impl.md

Severity: OK

Three changes, all correct and consistent:

• Line 38 — Delta item 1 rewritten from "No objectName in --detail" to "objectName source". The new text is more actionable: it tells the agent where to read objectName, explicitly says not to pass it in --detail, and adds a recovery path (re-pull registry + re-add) when the value is missing. Good improvement.
• Line 39 — Delta item 2 placeholder changed from <activity-name> to <object-name> in the is resources describe example. Consistent with the routing fix.
• Line 106 — Blockquote updated: positional is now objectName (was activityName), and the command placeholder matches. Internally consistent with § 4.0.0 Activities above.

The remaining <activity-name> on line 60 (uipath.connector.<connector-key>.<activity-name>) is the node-type format string, not the describe positional — correctly left unchanged.

2. skills/uipath-platform/references/integration-service/resources.md

Severity: OK

Three changes, all correct and consistent:

• Line 71 — Cache key changed from <activity-name>.v4.schema.json to <object-name>.v4.schema.json.
• Line 73 — Resource argument rule simplified: was "addressed by activity name — pass the activityName... (4.0.0 metadata has no objectName)" → now "addressed by object name — pass the objectName...". The parenthetical about 4.0.0 having no objectName is correctly removed since v4 now routes to objectName.
• Line 77 — Code example placeholder updated from <activity-name> to <object-name>. Matches the prose above it.

No remaining activityName or activity-name references in this file.

What's Missing

Nothing identified. Both files are fully consistent after the change. No flavor overrides exist for either file.

Area Ratings

Area	Status	Notes
Frontmatter	OK	No frontmatter changes
E2E Tests	OK	Documentation-only change; no new capabilities introduced
Skill Body	OK	No SKILL.md changes
References & Assets	OK	Both reference files are internally consistent and cross-consistent
Repo Hygiene	OK	No secrets, no cross-skill deps introduced, scoped to the fix

Issues for Manual Review

• Domain accuracy: The core claim — that v4 endpoints route to objectName rather than activityName — is a CLI behavior assertion this reviewer cannot verify. The author (or a domain expert) should confirm the CLI actually accepts objectName as the positional for --activity-version 4.0.0 describe calls.

Conclusion

Clean, well-scoped documentation fix. Both files are updated consistently. The rewritten delta item 1 in impl.md is a meaningful improvement — it gives agents a concrete recovery path instead of just stating a negative. No issues found; this looks good to merge once domain accuracy is confirmed.

---