# Phase 6 — Reskinning the demo data to your industry

> 🛑 **Do not start this without Phase 0.** Read `reference/00-operator-profile.md` and run the
> five-question interview first. Every layer below consumes its answers. The CPG examples in this
> file are from **one** seller's territory (Retail & Consumer Goods, US East) — they are worked
> examples, not defaults, and inheriting them silently produces a demo that resonates with nobody.
>
> The minimum you need before reading on: **industry, segment, account archetypes, workloads in
> scope, audience roles**, and an approved reskin plan.

## What ships by default

The stock Dynamics 365 CE demo data is a **coffee-equipment retailer**. A fresh environment
with the demo-data packages installed contains roughly:

| Entity | Count | Content |
|---|---|---|
| accounts | 8 | Fabrikam, Trey Research, Northwind Traders, Alpine Ski House, A. Datum, Fourth Coffee, Coffee Lab APJ, Graphic Design Institute |
| contacts | 13 | Cafeteria Managers, Purchasing Managers |
| leads | 16 | "10 Airpot XL Coffee Makers for …" |
| opportunities | 22 | "5 Café A-100 Automatic" |
| incidents (cases) | 17 | Steam arm broken, machine won't heat |
| products | 62 | Espresso machines, grinders, airpots, accessories |
| knowledgearticles | 118 | **Three unrelated datasets** — see below |
| competitors | 3 | Fourth Coffee, Relecloud, VanArsdel |

The knowledge base is the worst of it: 118 articles spanning **coffee machines** (Contoso
SmartBrew 3000), **Contoso Flowers** (a florist), and **telecom** (SIM cards, roaming, iPhone).
Three completely different demo scenarios layered on top of each other.

---

## Decide two things first

### 1. Real company names or fictional?

If your territory is real named accounts, using them means that when you demo **to** one of
them, they see a competitor's pipeline, deal sizes and contacts on screen.

**Recommendation: fictional.** Invent companies that map to your territory *archetypes*.
You keep the industry resonance without the cross-account awkwardness. This is why Microsoft
ships fictional demo data in the first place.

> This decision belongs in the Phase 0 interview, not here — by the time you are editing records
> it is late to be asking. See `reference/00-operator-profile.md`. State the exposure once,
> clearly; if the operator still wants real names, that is their call.

### 2. Does this conflict with the packaged narrative?

Caldova ships as a **pharmaceutical / life-sciences** company (supplier sourcing, procurement,
RFP management, Allerveo). If you reskin the CRM to a different industry, your Sales and Service
data will tell a different story than Chapters 1–3 of the setup guide. That is fine if these are
your own demos — just make the choice deliberately.

---

## The methodology

Work through **five layers**. Skipping any of them leaves visible artefacts.

### Layer 1 — Accounts and competitors

Rename in place (keeps all relationships intact). Also update `revenue`, `numberofemployees`,
`websiteurl` and `description` so the records look plausible at the scale you are claiming.

### Layer 2 — Products

The largest bulk edit. Update `name` **and** `productnumber` — SKU codes matching the old
industry are an obvious tell.

Build a coherent brand architecture rather than renaming SKUs at random. Example for a CPG
manufacturer — **this is one industry's worked example, derived from a Phase 0 profile. Build the
equivalent for the operator's industry rather than reusing these names:**

| Brand | Category |
|---|---|
| Vireo | colas, sparkling, still water, iced tea |
| Kestrel | energy drinks |
| Orchard Press | juice and smoothies |
| Saltbrook | salty snacks |
| Nomad | protein bars |
| Brightly | household cleaning |
| Nova Care | personal care |

The pattern that transfers is the **structure**, not the names: 5–8 brand families, each owning a
category, with SKU codes that encode brand + variant + size. `reference/00-operator-profile.md`
has a brand-architecture axis suggested per industry.

Suffix duplicate SKUs with a channel marker like `(Trade)` and give them distributor case
descriptions — that is what the duplicate product records in the stock data actually represent.

### Layer 3 — Transactional records

Opportunities, leads, cases. Rename to motions that make sense in your industry.

For CPG/retail the natural set is: new item authorization, category reset, distribution
expansion, promotional programs, club pack launches, annual volume commitments; and for cases:
short shipments, damaged pallets, promo pricing not applied at POS, trade spend deductions,
planogram compliance, EDI setup, lot code / recall queries.

**Other industries:** `reference/00-operator-profile.md` carries opportunity-motion and case-type
starters for retail, financial services, manufacturing, healthcare/life sciences and public
sector. If the operator's industry is not listed, build the set with them before writing records —
generic deal names ("New Deal Q3") are the single most obvious tell that a demo tenant was never
really reskinned.

### Layer 4 — The fields everyone forgets ← most important section

Renaming the `name` field is **not enough**. Stale content hides in:

| Entity | Field | What was in it |
|---|---|---|
| `opportunity` | `description` | "Adding coffee machines to HQ" |
| `product` | `description` | Full espresso-machine marketing copy |
| `lead` | `jobtitle` | "Cafeteria Manager" |
| `lead` | `emailaddress1` | `harrison@fabrikam.com` |
| `lead` | `websiteurl` | `http://www.northwindtraders.com/` |
| `lead` | `companyname` | old account name |
| `contact` | `emailaddress1` | `alex@treyresearch.net` |
| `contact` | `jobtitle` | "Cafeteria Manager" |

Generate emails and websites from your new fictional domains. Use a `.example` TLD so nothing
resolves to a real site.

### Layer 5 — Knowledge articles

Split by `statecode`, because effort should follow visibility:

| statecode | State | Priority |
|---|---|---|
| 3 | **Published** | Highest — surfaces in search and feeds the Knowledge agent |
| 0 | Draft | High — visible in KB lists |
| 4 | Expired | Low |
| 5 | Archived | Low |

Give the Published set genuine multi-section HTML content that matches your case titles — this
is what a Customer Service demo actually shows. Rotate the Drafts through a topic list. Replace
Archived/Expired with neutral "superseded/retired" stubs so nothing off-narrative can surface.

> Published articles **are** writable via `Xrm.WebApi` even at `statecode = 3`. You do not need
> to unpublish first.

---

## Verify with a regex sweep

The only way to know you got everything. Run after each layer:

```js
const old = /fabrikam|trey ?research|northwind|alpine ?ski|adatum|fourth ?coffee|coffee ?lab|
graphic ?design|proseware|lucerne|consolidated ?messenger|relecloud|vanarsdel|caf[eé]|espresso|
coffee|airpot|grinder|barista|crema|flower|bouquet|florist|SIM card|roaming|iphone|smartbrew|contoso/i;
```

Check `name`/`title`, `description`, `content`, `emailaddress1`, `websiteurl`, `jobtitle`,
`companyname`, `keywords` across `account`, `contact`, `lead`, `opportunity`, `incident`,
`product`, `competitor`, `knowledgearticle`.

`scripts/verify-environment.js` does this. Target: **0 hits in every entity.**

---

## What you cannot fix from Dataverse

- **Cached Copilot summaries** on leads and opportunities still quote old product names until
  they regenerate. Harmless, and they refresh on their own.
- **Account addresses** (street/city) are left as-is by this methodology — reskin them too if
  your demo zooms into an address.

---

## Reference volumes

For scale: a full reskin of the stock dataset was **199 record updates** across accounts,
competitors, products, opportunities, leads, cases and contacts, plus **118 knowledge articles**.
All of it via `Xrm.WebApi` in batches, with zero failures. Budget 30–45 minutes.

---

## 🔴 The reskin leaks — it misses the CONFIGURATION layer

The reskin covers **transactional** data (accounts, leads, opportunities, cases, products) and stops
there. A set of **configuration** records keep their stock Contoso names, and every one of them is
visible in the UI during a demo:

| Object | Stock value found | Why it shows |
|---|---|---|
| Public queues | `Contoso Coffee Questions`, `Contoso Coffee Support` | Queue picker, case routing, agent dashboards |
| Case subjects | `Auto-drip`, `Clogged tubes`, `Water supply`, `Temperature`, `Machine parts`, `Unexpected shutdown` | **Subject dropdown on every case form** |
| Price list | `Contoso Coffee Price List` | Quote / order / invoice headers |

Coffee-machine fault codes on a beverage company's cases is exactly the detail a customer notices.
**Audit these after any reskin:**

```js
const g = async u => (await (await fetch(base+'/api/data/v9.2/'+u,
  {headers:{Accept:'application/json'}})).json()).value;
await g("queues?$select=name&$filter=queueviewtype eq 0");   // public queues only
await g("subjects?$select=title&$top=20");
await g("pricelevels?$select=name");
```

They are all plain `PATCH` renames — cheap to fix, high visual payoff. Caldova's became
`Caldova Trade & Order Support` / `Caldova Consumer Care`; subjects became
`Product quality`, `Delivery shortage`, `Packaging damage`, `Cold chain / temperature`,
`Trade promotion dispute`, `Invoice & pricing query`.

> **Generalise this:** after reskinning, sweep for the old brand name across *config* entities, not
> just records. Anything that renders in a dropdown, view name or queue list is worth checking.