/consumer-goods-sync-management-configure

name: consumer-goods-sync-management-configure
description: "Use this skill to set up Salesforce Consumer Goods (CG) Cloud Mobile Sync end-to-end for the Sync Management App managed package — it runs all three acts in order (Act 1 Setup Sync, Act 2 Assign Users, Act 3 Plan & Verify), not just installing the baseline, so a sales rep can see the day's planned visits offline. Use it when asked to \"set up CG Cloud mobile sync\", \"configure Consumer Goods mobile sync\", \"set up sync for Retail Execution\", \"install the sync baseline\", \"assign a user to the sync configuration\", \"verify the sync setup\", or \"why can't my rep see their planned visits offline\" when sync setup or the baseline install is suspected. DO NOT TRIGGER for general CG Cloud mobile-app troubleshooting unrelated to sync setup, for authoring new or custom sync baselines (this installs only shipped baselines discovered at runtime), or for building or customizing the mobile app UI itself — those are out of scope."
metadata:
  version: "1.0"
  cliTools:
    - tool: ["sf"]
      semver: ">=2.0.0"

**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