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

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.

1. Dry-run? — offer by default.
2. 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.

1. 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.

1. Which dashboards to produce — Promotion Analysis, Tactic Analysis, or both. Default to both

if any measure on either has an override; otherwise ask explicitly.

How it works — phase list

1. Namespace detection — resolve NS via sf package installed list for consistency with

sibling skills, but never apply it to any /services/data/... path (those are never namespaced).

1. Phase 0 — Preflight & discovery: verify connectivity, pin API version v67.0, resolve the

installed app + asset ids (model, both dashboards, visualizations) by walking the app's asset list — never hardcode an id. Block with a pointer to consumer-goods-tpe-dashboard-configure if prerequisites are missing. Full detail: references/procedure.md.

1. Phase 1 — Resolve the 5-slot plan: deep-copy each base parameter/measurement with overrides

applied, print the plan, get explicit user confirmation before any writes.

1. Phases 2-4 — Clone parameters, measurements, visualizations, dashboards: run

scripts/clone-tpe-dashboards.js (preferred over hand-rolling individual REST calls) — see references/procedure.md for the full CLI usage, override-mode payload shapes, and every real-write gotcha the script encodes (label uniqueness, dataSource .type stripping rules, cloning every KPI-bound visualization not just one "designated" viz, cosmetic label-text replacement, upsert-by-measure-code).

1. Phase 5 — Verify: GET every created artifact back and confirm parameters, measurements,

visualizations, and dashboards all correctly reference the new suffixed clones, never a base apiName. Full detail: references/procedure.md.

Key rules (see references/procedure.md for the complete list)

• Never mutate a base-model artifact — every write is a new POST of a suffixed copy.
• Never create anything without explicit user go-ahead on the Phase 1 plan.
• Always produce all 5 slots' worth of clones, even with zero overrides.
• Never leave a cloned measurement's expression referencing a base parameter apiName.
• Never hardcode an artifact id, api-name, or namespace across orgs.
• Never assume only one visualization per dashboard needs cloning — clone every widget whose viz

references a slot measurement.

Reference map

Report

At the end of a run, give the user a structured status per phase (0-5): pass / blocked / pending, with the specific blocking reason where applicable, and the final list of created artifacts (slot → new parameter, base viz → new viz, base dashboard → new dashboard). Call out anything skipped due to dry-run or a declined confirmation.

When invoked via delegation (the calling skill used the Skill tool to reach this file, rather than the user directly — e.g. consumer-goods-tpe-dashboard-configure's customization step): this report is an intermediate result. Return it to the calling skill and let it continue with its own report — do not present this as the final answer to the user unless this skill was invoked standalone.