Consumer Goods Sync Management Configure

Setting up CG Cloud Mobile Sync means running all three acts in order — Act 1 (Setup Sync), Act 2 (Assign Users), Act 3 (Plan & Verify) — NOT just installing the sync artefacts. Installing the baseline is one step of Act 1; finishing it is not finishing the setup.

Guide an admin/implementer through setting up Consumer Goods (CG) Cloud Mobile Sync for a customer org so a sales rep can install the CG Cloud Mobile App and see the day's planned visits offline. The moving parts live in the managed package Sync Management App (its namespace is resolved at runtime — see ns_prefix in Session state) plus CG Cloud core / Retail Execution settings.

This skill automates as much as a real transport can trigger — a Headless-360 / generic-core call (SOQL, sObject REST, Connect, Tooling), an sf deploy, or a global @RestResource /v1/* endpoint in the package. A public package method is not enough: in a managed package public is namespace-private (unreachable from a subscriber org), so only global/webservice/@RestResource members are triggerable. Where neither a generic core capability nor an invokable package action can complete a step, the skill reports what's needed — and who provides it — and stops that step; it never fakes a capability.

Scope & definition of done — READ THIS FIRST

"Set up CG Cloud mobile sync" / "set up sync for Retail Execution" / "configure Consumer Goods mobile sync" with no narrowing qualifier means run ALL THREE ACTS, in order: Act 1 → Act 2 → Act 3. It does not mean "install the artefacts." If you are about to run only the install for an unqualified request, that is the bug this section prevents — start at Act 1, step 1 (readiness).

You are NOT done after installing artefacts. Setup is complete only when Act 3's end state is reached (the activated config listed, verified across the four objects, and checked against the baseline files). A run that ends after the install is a partial run — say so plainly.

Act 1 is not "install-only." It has hard readiness gates before the install — the namespace gate (A1.1) and Retail Execution enablement (A1.2) — and a verify after it (A1.4). Installing the baseline into a non-RE-enabled org produces a config that can never sync, so readiness is checked first; a hard miss is reported-and-stopped, not written around. The baseline install is the sync configuration (the root Sync_Config__c and its values come from the baseline CSVs) — there is no separate "create config" step.

A step the skill can't complete is a stop-that-step signal, not stop-the-whole-run. Report the boundary and who provides the missing piece (the CG Cloud platform / Retail Execution, or the org admin), then continue with every unblocked step. Only a hard readiness miss halts the sequence: the sync metadata absent (neither a package install nor an org namespace resolves), RE cannot be enabled and isn't already on, or — under Default_IOU — the target user's missing default mobility IOU.

The only legitimate subset run is when the admin's own ask is narrow (e.g. "sync's already installed, just assign Chantelle", "just verify what's activated") — see the routing table. When the ask is unqualified or you are unsure, run the full 1→3.

The transport contract — every automatable step is core or Sync Management App

This is the honesty spine. Before running a step, know its transport, and never fake success for a step no transport can complete:

• core — a generic Salesforce / Headless-360 capability: direct SOQL via execute_api → GET /query?q=...; the CG Cloud core RetailExecutionSettings get→set org-preference triad; sObject-REST writes (POST /services/data/vXX.0/sobjects/<Entity>); Schema/Tooling describe reads.
• Sync Management App — an action triggered inside the package. The real headless surface is a global @RestResource /v1/* endpoint, chiefly the three /v1/syncconfig/* routes: /install (GET discover + POST install — A1.3), /configs (GET deployed configs + strategy — A3.1 list), /assignment (GET/POST/DELETE user→config binding — A2.3). Not Sync Management App: public Apex methods (namespace-private) and Visualforce actions.

When neither transport can complete a step, report what's missing, name who provides it, and stop that step — do not guess an API name or write around it. The genuine non-automatable points are few: the advanced-RE pilot GA gate (A1.2, platform-owned, no API) and IOU-membership creation (A2.2, a CG Cloud core / RE task the skill only reads). Deep transport rules: references/transports-and-namespace.md.

Mandatory pre-write plan — state this before your FIRST write

Before you execute a single write (enable RE, install a baseline, create a mapping row), post a short plan that makes your scope decision explicit and reviewable:

1. The full journey is three acts — Act 1 (Setup Sync), Act 2 (Assign Users), Act 3 (Plan & Verify).
2. Which acts/sub-acts you will run, and which you will skip — for every skip, quote the exact words in the admin's request that narrow the scope ("the request said 'set up sync'" is NOT a narrowing qualifier); for any step you can't complete, name who provides the missing piece.
3. The target org, confirmed explicitly (never silently inherited), and the resolved ns_prefix you will use for package objects.
4. Where you will start. For an unqualified request this is Act 1, step 1 (readiness: namespace + RE) — never the install.
5. Persist this plan to report.md in the working directory — writing that file is the very first action you take, before any org write. Append each Act's outcome (steps run, transport tag, read-back result, blocked steps) as you complete it, and write a final verdict at the end. This file — not the chat transcript — is the run's deliverable; it must exist even if the run stops early. Contract: "Write the run report to disk" in references/verify-and-smoke.md.

Entry point — route on the admin's actual ask

Default rule: unless the ask explicitly narrows the scope, treat it as the full setup and run Acts 1→2→3 in order. When in doubt, run the full journey.

Session state (track across the conversation)

• target_org_alias — the org being configured; confirmed explicitly before any write.
• ns_prefix — namespace prefix (with trailing __), discovered at runtime by A1.1 (never hardcoded), resolved once and used for every package-object path. Two sources: the installed managed package (InstalledSubscriberPackage.NamespacePrefix) or the org's own registered namespace (Organization.NamespacePrefix, source-deployed DE/packaging org).
• api_version — the Salesforce REST API version for raw-HTTP URLs. Never hardcode. Resolve once via GET /services/data, take the highest version. execute_api calls are versionless.
• org_ready — bool; true when A1.1's namespace gate passes AND A1.2 (RE enabled) passes. A hard miss on either halts the run.
• installed_config_id / installed_version — from the baseline install (A1.3). The install is the config — no separate "config created" flag.
• act1_complete, act2_complete, act3_complete — bool per Act; run strictly 1→2→3. For an unqualified request, all three must be true (minus reported non-automatable steps) before reporting complete.
• resolution_strategy — the config root's Business_Area_Resolution_Strategy__c (Default_IOU vs Custom_User_Field); decides whether A2.3 is IOU-implicit (via A2.2) or an explicit mapping write.
• blocked_steps — running list of steps the skill could not complete, each with the boundary and who provides the missing piece.
• report_path — the run's deliverable on disk: a report.md in the working directory. Created before the first org write (starting with the pre-write plan) and appended at each Act boundary, so a partial or interrupted run still leaves a faithful record. Reporting only in chat does not satisfy this — the record must exist as a file.

Per-sub-act transport map (compact)

Single source of truth for which transport each step uses. Full detail (API names, fallbacks, owners): references/transports-and-namespace.md, references/readiness-and-enablement.md, references/sync-management-app-install-backbone.md, references/verify-and-smoke.md.