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

| Topic | File |

|---|---|

| Full phase-by-phase procedure, script CLI usage, all real-write gotchas, complete Rules list | references/procedure.md |

| Confirmed live JSON shapes for parameters, calculated measurements, visualizations, dashboards, and POST body shapes for all 4 create endpoints | references/payload-shapes.md |

| Org REST helper (strips accessToken; org-status subcommand) | scripts/sf-rest.js |

| Deterministic driver for Phases 2-4 | scripts/clone-tpe-dashboards.js |

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.