/consumer-goods-tpe-dashboard-custom-kpi-configure

name: consumer-goods-tpe-dashboard-custom-kpi-configure
description: "Customize the Trade Promotion Effectiveness (TPE) Analytics dashboards' generic KPI slots (Promotion Measure 1-3, Tactic Measure 1-2) with customer-chosen KPI measure codes and display names, without touching the shipped base model. Use when a customer/admin wants to \"customize TPE dashboards\", \"change the KPIs on the Promotion/Tactic Analysis dashboard\", or \"swap in our own measure codes on the TPE dashboard\"."
metadata:
  version: "1.0"
  domains:
    - "Consumer Goods"
  relatedSkills:
    - "consumer-goods-tpe-dashboard-configure"
  cliTools:
    - tool: ["node"]
      semver: ">=20.0.0"
    - tool: ["sf"]
      semver: ">=2.0.0"

Customize TPE Dashboard KPIs

Headlessly clones the base TPE Analytics semantic-model parameters, visualizations, and dashboards under a customer-chosen suffix, so a customer's own KPI measure codes appear on the Promotion/Tactic Analysis dashboards without ever mutating the shipped base model. Driven entirely by `sf` CLI + REST against an already-authenticated org. Requires `consumer-goods-tpe-dashboard-configure` to have already installed the TPE Analytics app and the Extended TPM Analytics SDM — this skill never installs those, only customizes on top of them.

Persona: a **Salesforce TPM System Admin** customizing TPE dashboards for their org's own KPIs.

There is no native "clone" endpoint for any of the three artifact types this skill touches (semantic-model parameters, visualizations, dashboards) — every clone is the same three-step pattern: **GET** the base artifact, **deep-copy** its JSON and apply overrides, **POST** the copy as a new artifact. Base-model artifacts are never mutated in place.

The 5 KPI slots — two artifacts per slot, not one

The shipped Extended TPM Analytics SDM exposes 5 generic **List-type parameters** that the standard dashboards bind to: Promotion Measure 1-3 (`Promotion_Measure_{1,2,3}_prm` / `_value`) and Tactic Measure 1-2 (`Tactic_Measure_{1,2}_prm` / `_clc`). **Never assume Tactic mirrors Promotion's `_value` naming** — resolve both slots' measurement apiNames from the live model per slot, never by pattern. See `references/payload-shapes.md` for the confirmed apiNames and JSON shapes.

Each slot is **two SDM artifacts**: the **parameter** (`*_prm`, a `List` type with `allowedValues` menu entries and a `defaultValue`) and the **calculated measurement** (what visualizations actually query; its `expression` links back to the parameter by apiName). **Customizing a slot means cloning both** — the parameter gets the customer's KPI as a new/selected `allowedValues` entry, and the measurement's `expression` is rewritten to reference the cloned parameter's new apiName.

This skill always produces clones of **all 5 slots (10 artifacts)**, whether or not a given slot has a requested override — an unmentioned slot is still cloned as an exact copy of the base artifacts (only apiName/label suffixed).

Two override modes per slot (see `references/procedure.md` for exact `--overrides` shapes):

• **APPEND mode** (default): upserts one `{measureCode, displayName}` entry into the base menu by

measure code — same code relabels in place, new code appends.

• **REPLACE mode**: a full `allowedValues` array supplied by the customer becomes the entire menu.

Either way this skill assumes the underlying measure data is already populated by prior `setup-rtr-datacloud-export`/data-kit setup — it does not create that underlying data itself.

Inputs to collect first

Ask before starting. Do not guess.

1. **TPM System Admin username** — verify connectivity via `node ./scripts/sf-rest.js org-status --target-org <username>` (never `sf org display --json` directly — that leaks a live `accessToken`). Non-`Connected` ⇒ stop, ask the user to log in. 2. **Dry-run?** — offer by default. 3. **Suffix** — distinguishes cloned metadata from the base model (e.g. `Cust`). Suggest `Cust` as a default. Applied to every new artifact's API name/label — never reuse a base-model API name. 4. **Per-measure overrides** — walk the customer through the 5 measures via `AskUserQuestion`, **batched by dashboard** (Promotion Measure 1-3 in one call, Tactic Measure 1-2 in a second call — never all 5 in one call, the tool caps at 4 questions per call), never using the internal term "slot" toward the user. **Never ask a separate plain free-text follow-up question to collect the list** — a plain-text message doesn't block the next tool call, so if you fire another `AskUserQuestion` for the next measure before the customer's reply lands, their answer races ahead and lands on the wrong question. Instead, collect the full list **inside the same blocking question**: every `AskUserQuestion` question automatically gets a "Type Something" free-text option appended after your listed options — no need to add your own placeholder option for it, and never rely on a bare canned option label (e.g. "Replace with custom list") to actually carry the list, since selecting it only returns that label text, not the customer's data. Word the question and its second option's description to point the customer at "Type Something" explicitly, e.g. option 2 = "Replace with custom list", description: "Select **Type Something** (last option, below) and type comma-separated `{measureCode}: {displayName}` pairs, plus which one should be default." **A menu can have more than one entry — always collect the full array, never just one pair** (a single-pair answer is still an array of length 1). This collected array maps directly to that slot's REPLACE-mode override (`{"allowedValues":[...], "defaultValue": "<first displayName unless the customer says otherwise>"}`) — see `references/procedure.md`'s override-mode shapes. Confirm the resolved list per measure back to the user before Phase 0. 5. **Which dashboards to produce** — Promotion Analysis, Tactic Analysi