--- name: "demo-data-Acme Catering" description: "Project skill for the ACME CATERING Catering CRM demo (Dynamics 365 Sales, demo org / CX26). Use whenever the user mentions Acme Catering demo data, the Acme Catering catering CRM demo, the Acme Catering RFP demo, the demo scenarios working document, or asks to build, refresh, re-date, verify, or extend the demo dataset for this engagement. Also use for questions about the five RFP demo scenarios, the demo agenda, or what data a scenario needs. Every read and write is locked to the Acme Catering demo environ" --- ## Purpose This is a **single-project skill** for one engagement: the **Acme Catering Catering CRM demo**. Acme Catering Sandwich Works issued a Catering CRM Tool RFP. Microsoft — with implementation partner **Lumovy** — is responding with **Dynamics 365 Sales Premium** plus Customer Insights, Copilot, Copilot Studio, Power BI, Power Automate, and Outlook/Teams integration. The customer published **five demo scenarios** and requires all five to be demonstrated thoroughly. This skill builds and maintains the **demo dataset** in the Acme Catering demo Dataverse org so that every customer-stated proof point can actually be shown, and produces a **paste-ready demo script**. Scope is D365 Sales-centred, with supporting Microsoft solutions in the story. --- ## The live working document — read this first, every run **Source of truth:** `https://microsoft-my.sharepoint.com/:w:/p/stacybe/cQoN8GC1E4nERKbnoJsJ-WUsEgUCu7IAq6P089FGJO6ivsTQQQ` — *"Demo Scenarios - Catering CRM Tool.docx"*, owned by **stacybe**, shared with the user. This is a **living document** that the team keeps editing. Its first section derives from the customer's RFP scenario brief; the rest is the Microsoft/Lumovy delivery plan and grows over time. ### Rules 1. **Always re-read it at the start of a run.** Never work from cached knowledge of it. Timings, owners, attendees, scenario wording, and scope change between runs. 2. **It outranks everything in `reference/`.** Where they disagree, the live doc wins and you should say so explicitly. 3. **Report what changed** since the snapshot in `reference/demo-scenarios.md` before planning data. 4. It contains **customer-private content** — real attendee names, titles, LinkedIn profiles, and Teams meeting join details. Use it for the user's private prep only. **Never copy it into disk files, demo records, outbound messages, or anything shared.** ### How to read it It is a Word file rendered in Word Online — a plain HTTP fetch returns a login page and `page.evaluate` on the body returns empty. What works: - `browser_navigate` to the URL, then **`browser_snapshot` with a `filename`** to write the accessibility tree to a file, then `grep`/`view` that file. The document text — headings, paragraphs, list items, and table cells — is present in the snapshot tree. - If a Graph download is attempted instead, note that an `az` CLI token will **403**; it lacks the needed Files scopes. - If the document cannot be read at all, **say so and stop** rather than planning from `reference/` alone. Ask the user to paste the current content. ### Writing back to it The user may ask to record demo-prep results in the doc. **Never edit it without an explicit, per-edit request and a preview of the exact text.** It is shared with colleagues. Default to producing a markdown block the user can paste themselves. --- ## Reference files Load these **after** the live doc, as background. They are static and derived from the RFP documents. | File | Contents | Read when | |---|---|---| | `reference/demo-scenarios.md` | The 5 scenarios, every required proof point, the agenda, and the data each scenario needs | Always | | `reference/team-assets.md` | What teammates have already built (Stacey Bertolino's canvas app etc.), which scenarios they cover, and the account/CSM names to reuse | **Always — before planning any data** | | `reference/demo-websites.md` | The two demo websites — Contoso Catering (first-party) and CaterCloud (third-party marketplace) — how to run them, the channel-contrast story, and the seeded records they depend on | Scenario 1, or any web-to-lead / first-party-vs-ezCater question | | `reference/scenario-3-draft.md` | Design draft for Scenario 3 (Ownership Change & Sales Credit Governance) — narrative, build spec with exact schema, run-of-show, discovery questions | Scenario 3 work | | `reference/scenario-3-built.md` | **What was actually built** for Scenario 3, the record IDs, and the three items still outstanding (flow, security role, forms/views) | Scenario 3 work — read before touching it | | `reference/change-log.md` | Every write this skill has already made to CX26, and what was deliberately left alone | **Always — before planning any data** | | `reference/Acme Catering-context.md` | Business context, solution architecture, personas, integration landscape, business rules, KPI targets | Planning data or writing the script | | `reference/dataset-blueprint.md` | Concrete synthetic seed records per scenario, catering product catalogue, hygiene rules | Building or extending the dataset | | `reference/environment.md` | Org details, auth setup, the commands that trigger login loops, the outstanding MCP blocker, CLI fallback commands | Any connectivity problem | > **Append to `reference/change-log.md` after every successful write run.** It is the audit trail. > **Name consistency:** where `reference/team-assets.md` lists account and CSM names already used in > a teammate's asset, **those names win** over the placeholders in `dataset-blueprint.md`. The demo > must tell one story across all five scenarios. --- ## Environment — pinned, never substituted | Setting | Value | |---|---| | Demo org | `https://.crm.dynamics.com/` (**CX26**) | | Tenant user | `nancyw@.onmicrosoft.com` | | MCP server | `dataverse-Acme Catering` | | CLI auth profile | `Acme Catering-demo` | **Never** write to `` (the other demo tenant), `microsoftsales` (MSX production), or any other org. If a result, URL, or record link shows an org other than ``, **abort immediately, tell the user, and write nothing.** > ⚠️ **Never run `dataverse mcp --validate`.** It forces interactive auth, loops on MFA, and > locks the user's screen — even when MCP is healthy. Verify with a cheap `dataverse data query` > instead. Full detail: `reference/environment.md`. **Current status (verified 2026-07-28):** the `dataverse-Acme Catering` MCP endpoint is **working** — all 16 tools resolve. The Dataverse CLI path also works and remains a valid fallback. If MCP tools are not visible in the session, Scout may need a restart to load the server. --- ## Guardrails ### Customer data - The RFP documents, the working doc, and the user's email/Teams/calendar are **private customer data**. Never expose them outside this chat. - **Never** use real Acme Catering customers, contacts, financials, attendee names, or contract values as demo data. All demo records are **synthetic**. - Use `.example` domains and `555-01xx` phone numbers. - Real attendee names stay in the live doc. Do not persist them to disk or into CRM records. ### Writes - **Preview every create/update and get explicit approval before executing.** No exceptions. - Approval is **per run and per record set**. Never carry approval forward. - **Never delete.** Not records, not tables, not sample data. Deletes are out of scope — if cleanup is genuinely needed, deactivate, or ask the user to delete manually. - Never write outside the approved entity list. - Reuse suitable existing records before creating new ones. - Continue through non-fatal per-record failures; report each one clearly. ### Schema - **Never guess logical names, option-set values, or lookup targets.** Describe the table first. Choice columns need numeric values, not labels. --- ## Workflow ### Step 1 — Sync with the live working document Read it (method above). Extract: demo date/time, agenda with timings and owners, scenario list and any wording changes, attendee roster, and any new sections the team has added. **Report deltas** versus `reference/demo-scenarios.md`. ### Step 2 — Establish the ask Determine whether the user wants: a full dataset build, one scenario, a gap check, a re-date after a schedule change, or just the demo script. If ambiguous, ask — do not assume a full rebuild. Also compute **days until demo day** and flag if it is close. ### Step 3 — Verify the environment Confirm connectivity to `` with a cheap read. Confirm whether MCP tools or CLI fallback are in play, and tell the user which mode you are in. ### Step 4 — Inventory what already exists **First read `reference/team-assets.md`** — teammates (primarily **Stacey Bertolino**) are building demo assets in parallel. Never rebuild something that already exists, and always reuse the account and CSM names already established in their assets. Then query the org for accounts, contacts, leads, opportunities, quotes, products, activities, and users. Identify what is reusable, what is stale, and what is missing. Map demo personas to **real enabled users** in the org — do not create users. If an asset lives in a **different environment** than CX26, flag the split to the user explicitly — it affects whether the presenter has to switch orgs mid-demo. ### Step 5 — Gap analysis against the proof points Walk the required-bullet list in `reference/demo-scenarios.md` **scenario by scenario, bullet by bullet**. For each, state: **Covered** / **Partial** / **Missing**, and name the record that covers it. This is the core value of the skill — do not shortcut it. ### Step 6 — Plan the dataset Fill gaps using `reference/dataset-blueprint.md`. Describe the target tables first and adapt to the org's real schema. Show the adapted mapping if it differs from the blueprint. **Date discipline:** all dates relative to the demo date from Step 1. Overdue must be genuinely overdue; recent orders genuinely recent. ### Step 7 — Preview and confirm Render a Markdown table grouped by scenario and entity: | Scenario | Action | Entity | Record name | Key fields | Owner | Proof point it enables | Risk | |---|---|---|---|---|---|---|---| Actions are `create`, `update`, or `reuse`. Then ask: > **Approve these Dynamics 365 demo-data writes to the Acme Catering demo org ( / CX26)?** Do not proceed without explicit approval. If the user edits the plan, re-render and re-ask. ### Step 8 — Execute approved writes Create, update, or reuse as approved. Never delete. Echo every record with entity, display name, GUID, and status: `Created` / `Updated` / `Reused` / `Failed`. ### Step 9 — Produce the demo-run output Deliver a paste-ready markdown block: 1. **Header** — demo date/time, org URL, which user to sign in as 2. **Coverage matrix** — each scenario's proof points and the record that demonstrates each 3. **Dataset table** — Entity, Name, Owner, Key fields, Status 4. **Run-of-show** — per scenario, in agenda order: the opening line, 3–6 beats naming the exact screens and records, the specific values to call out, and the value close (use the customer's own KPI targets from `reference/Acme Catering-context.md`) 5. **Gaps and placeholders** — anything still `[Add value]` or unresolved 6. **Safety note** — confirm the dataset is fully synthetic and names the org it lives in Offer to format Step 9 for pasting into the working document. Do not write to the doc unsolicited. --- ## Failure handling | Situation | Do this | |---|---| | Live doc unreadable | Say so, ask the user to paste current content. Do not silently fall back to `reference/` | | MCP server unavailable | Switch to CLI fallback, tell the user, continue | | Any auth loop or lock-screen prompt | **Stop immediately.** Kill spawned processes. Never retry the same command | | Wrong org detected | Abort, write nothing, tell the user | | Schema mismatch | Show the mismatch, ask whether to adapt or stop | | Partial write failure | Report failures, leave successful records intact, offer to retry only the failures | | Demo date has moved | Offer to re-date all relative dates before anything else | --- ## Attribution Derived from `se-demodata-prep` (submitted by Thymio Barbatsis); rebuilt as a project skill for the Acme Catering Catering CRM engagement.