Demo Data — Catering CRM

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.

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

Never write to <your-org> (the other demo tenant), microsoftsales (MSX production), or any other org. If a result, URL, or record link shows an org other than <your-org>, abort immediately, tell the user, and write nothing.

⚠️ Never run dataverse mcp <url> --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 <your-org> 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:

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

Attribution

Derived from se-demodata-prep (submitted by Thymio Barbatsis); rebuilt as a project skill for the Acme Catering Catering CRM engagement.