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.