CRMPro (forward sync)

CRMPro is Commercient’s forward sync agent: it reads the customer’s ERP data out of the gateway database and pushes it into their CRM or e-commerce platform. (Its counterpart, TxDownloaderPro, runs the other way — CRM back toward the source. They are different products; write both names in full.) CRMPro runs per customer on a schedule and takes its behaviour from configuration and flags held in the database, so operating it means changing that state — which is what the crmpro_* admin tools are for.

What you can do without opening the portal: see the sync grid (one process per ERP-view→CRM-object pair) and read any process in full, including its source-view SQL and its field mapping; turn a single object’s sync on or off; turn the customer-wide sync on or off; create, change and delete processes; look up CRM connections, live CRM objects and their fields, and the ERP tables/views a process can be built from; import the default templates; and diagnose a run from the sync history, the error view, the sync flags and the agent’s own self-report.

From the CLI, everything runs against a named tenant profile:

dlake crmpro processes --profile <tenant>            # the sync grid
dlake crmpro process 123 --profile <tenant>          # one process in full
dlake crmpro status --profile <tenant>               # is customer-wide sync on?
dlake crmpro history 123 --profile <tenant>
dlake crmpro errors --profile <tenant>
dlake admin crmpro_update_process_field --profile <tenant> \
    --recordId 123 --fieldName Is_Active --value false

dlake crmpro --help lists the shorthand group; the full tool set is always reachable as dlake admin crmpro_<tool>, with --help generated from each tool’s schema. Naming the tenant with --profile on every call is what stops a command landing on the wrong customer.

Three things worth knowing before you change anything:

• The whole group is Admin-only — the key must belong to a user holding the Admin role (see Admin Control Plane (MCP)). A 403 here is an account question, not a scope you can widen.
• Nothing takes effect until the next run. CRMPro reads its configuration and flags at startup, so an edit lands on the next run — there is no “apply now”.
• A run can be triggered on demand. The customer’s server also runs the Commercient Receiver, a WebSocket client that stays connected to the Commercient service and starts a product’s sync when a run command arrives from it — so a change does not have to wait for the product’s scheduled task. It reaches that server only while the Receiver task exists there; the Sync Agent CLI’s status reports it as Commercient Receiver: Created / Not Created, and Not Created means on-demand runs cannot reach that machine and only the scheduled task will run it.
• The master switch is customer-wide. crmpro_set_sync_enabled moves every process in the tenant; to stop one object, change that process instead.

Deeper operating guidance — the flag table, field mapping, cursors and the tables behind the tools — lives in the dlake-crmpro skill that ships with the CLI, and the HubSpot-specific values a process needs are in dlake-crmpro-hubspot.