SE Demo Data Prep

Purpose

This skill prepares a safe, customer-relevant demo plan for Dynamics 365 demos. It finds upcoming demo meetings, identifies the likely customer, gathers recent private work context, derives a demo dataset plan, previews all proposed CRM writes, performs only approved create/update operations, and produces a paste-ready demo script.

Required guardrails

• Treat calendar, email, Teams, transcripts, files, CRM, and WorkIQ results as private user data.
• Never send, post, share, or expose private context outside the chat unless the user explicitly asks and confirms the exact outbound content.
• Never use real customer-confidential figures, internal-only customer data, personal data, HR data, compensation data, security data, secrets, or credentials as demo filler.
• Prefer plausible synthetic values or [Add value] placeholders when a field needs a value.
• Do not delete CRM, Dynamics, Dataverse, file, email, Teams, or calendar data. Deletes are out of scope for this skill.
• Before any create or update operation, show a full preview and get explicit user approval.
• Approval is per demo meeting and per target environment. Never treat approval for one meeting or org as approval for another.
• If the target Dynamics 365 / Dataverse MCP server or org cannot be positively identified, stop and ask the user to connect or choose the correct environment.
• Never silently fall back to another org, tenant, environment, table, or MCP server.
• If context is sparse or ambiguous, ask the user for the missing scenario before writing any records.
• If multiple external domains appear on the invite, ask the user which organization is the demo customer before continuing.

Onboarding questions

Ask these the first time the user invokes the skill, unless the answers are already clear: 1. Which Dynamics 365 or Dataverse MCP server should this skill use for demo-data writes? 2. Which org/environment should be treated as the demo environment? 3. Are writes allowed only to demo/sandbox environments, or can the user approve writes to other environments? 4. What default demo horizon should be used: 7 days, 14 days, or another window? 5. Should demos be detected only by meeting subjects containing "demo", or are there other keywords to include? 6. Who owns maintenance for this skill and its CRM-write rules?

Persist safe preferences such as demo horizon, demo keywords, and preferred demo environment. Do not persist secrets, tokens, customer-private content, or sampled demo records.

Workflow

Step 1 - Find upcoming demo meetings

List the user's calendar for the configured demo horizon. Default to 14 days if the user has not chosen another window.

Filter candidate meetings where the subject or agenda contains demo-prep keywords such as: - demo - walkthrough - showcase - solution review - technical validation - proof of concept - POC

For each candidate meeting, capture only what is needed for this workflow: - subject - start/end time - organizer - attendee domains - external attendee names and titles when available - meeting body or agenda summary

If no candidate meetings are found, tell the user and offer to widen the search window or use a manually named customer/demo.

Step 2 - Identify the customer

For each candidate meeting: 1. Group attendees by email domain. 2. Exclude Microsoft-owned/internal domains. 3. Treat the dominant external domain as the likely customer only when unambiguous. 4. If there are multiple plausible customer domains, ask the user to choose. 5. If there are no external attendees, ask the user to name the customer or skip that meeting.

Do not expose attendee lists in outbound content. They are only for the user's private prep.

Step 3 - Gather recent customer context

For each confirmed customer, gather recent context from approved read-only sources. Use the narrowest useful date range, defaulting to the last 30 days.

Useful sources may include: - Teams messages and chats involving the customer or customer name - email involving the customer or customer domain - meeting transcripts or recaps involving customer participants - relevant OneDrive or SharePoint files the user has access to - CRM/Dynamics account, opportunity, contact, and activity records - WorkIQ when cross-source reasoning is needed

Extract only demo-relevant signals: - products, capabilities, or screens the customer asked about - pain points, objections, success criteria, and business process needs - vertical, segment, and use-case clues - demo constraints such as region, language, compliance posture, or timeline - CRM objects already available for reuse in a demo/sandbox

Before planning any write, summarize the gathered context in 3-5 bullets per meeting and state whether the evidence is strong, moderate, or sparse.

Step 4 - Derive the demo dataset plan

Map the scenario to the minimum required demo entities. Adapt table names and columns to the connected Dynamics 365 / Dataverse environment after describing schema with the MCP server.

Common scenario mapping:

Build a record plan with realistic synthetic demo values. Use values that match the customer's vertical and scenario without copying real confidential values from private communications.

Step 5 - Validate target environment and schema

Before any write: 1. List available Dynamics 365 / Dataverse orgs or environments from the configured MCP server. 2. Confirm the selected environment is the user-approved demo target. 3. List and describe required tables. 4. Verify required columns and relationships. 5. Query for existing demo records that can be safely reused.

If schema does not match the expected entity/table names, adapt the plan and show the user the adapted mapping before requesting write approval.

Step 6 - Preview and confirm writes

Show a Markdown table grouped by meeting and entity before creating or updating anything.

Required preview columns: - meeting - customer - target org/environment - action: create, update, or reuse - entity/table - record name - key fields - source rationale - risk note

Ask: Approve these Dynamics 365 demo-data writes for [meeting name] in [environment name]?

Do not proceed unless the user explicitly approves. If the user edits the plan, re-render the updated preview and ask for approval again.

Step 7 - Create or update approved records

After approval: - create missing approved records - update only approved stale/demo records - reuse existing suitable demo records when possible - do not delete anything - do not update records outside the approved table/entity list - continue through non-fatal per-record failures, but report each failure clearly

After writes, echo each created, updated, or reused record with: - entity/table - display name - GUID or record id when available - status: Ready, Created, Updated, Reused, or Failed

Step 8 - Produce the final demo prep output

For each demo meeting, render a paste-ready Markdown block with: 1. Meeting header: subject, date/time, customer org, and key attendees. 2. Scenario summary: 2-3 sentences grounded in the gathered context. 3. Dataset table: Entity, Name, Key Fields, Status. 4. Demo script: - opening hook - 3-6 numbered demo beats naming screens/features and records to use - specific values to call out - customer-tied closing 5. Safety note: confirm the dataset is synthetic/demo-safe and list any placeholders the user should fill.

If multiple demos are processed, separate each output block with a horizontal rule.

Failure handling

• If no demos are found, offer to widen the date range or let the user name a customer manually.
• If the customer cannot be identified, ask the user to choose or provide it.
• If private context is sparse, ask for the scenario before writing.
• If the MCP server is missing or the org is unclear, stop and ask for setup; do not write elsewhere.
• If schema validation fails, show the mismatch and ask whether to adapt or stop.
• If writes partially fail, report the failures and leave successful records intact.

Attribution

Submitted by Thymio Barbatsis.