Caldova Demo Tenant Setup

Purpose

You claimed a CDX Caldova tenant and it arrives with licences but no Dynamics 365 apps installed. This skill takes it from empty to demo-ready.

It is written from a real end-to-end build (Aug 2026). Everything here was executed and verified, including the things that did not work — those are called out explicitly so you do not repeat the same dead ends.

Caldova is Microsoft's fictional pharmaceutical / life-sciences enterprise. The packaged demo narrative is supplier sourcing, procurement, RFP management, supplier risk and contract manufacturing (partner org in the scenarios: Allerveo). You can keep that narrative or reskin it to your own industry — see reference/04-demo-data-reskin.md.

🚀 START HERE — run the guided start

When a user invokes this skill, do not start executing and do not dump a questionnaire. Open reference/00-guided-start.md and follow it. It is the choreography for the first ten minutes:

1. Detect before you ask. pac auth list, pac env list, a record-count sweep, and a check for an existing ~/.caldova-demo-profile.json. Then tell the user what you found and branch:

2. Interview in six themed batches, not one wall of thirteen questions — who you sell to, workloads, data depth, the gated decisions, operating preferences, sign-ins. Content and rationale for each question live in reference/00-operator-profile.md.

3. Confirm the whole plan once, then run unattended.

4. Write ~/.caldova-demo-profile.json before the first build step, so a crash or a new session never re-interviews the user. Never write a password into it.

No tenant yet? Branch A covers claiming plus the MCAPS BYOT Azure subscription request. Those two are sequential, not parallel — the tenant must exist before the request has anything to attach to. And the launcher is not a progress bar: it can spin for 15–30 minutes after the tenant already exists. Verify in My Dashboard. Run the intake while it provisions.

Read this before you touch anything

First: confirm which identity you are operating as

Ask the operator for the Caldova admin UPN and sign in as that account before running anything.

Get the UPN from CDX → My Dashboard → the tenant row → Credentials. Then:

pac auth create --name caldova   # interactive browser sign-in as the Caldova admin
pac auth list                    # confirm the * is on the caldova profile

…and sign the browser in to the M365 admin portal and PPAC as that same account. Later, once the BYOT subscription lands, az login --tenant <caldova-tenant-id> too.

🔒 Ask for the UPN, never the password. All sign-ins are interactive browser prompts — the operator types their password into the Microsoft sign-in page. Do not request, store, echo or write a tenant password anywhere.

Why this is first: wrong-identity failures do not announce themselves. pac returns an empty environment list (looks like nothing was created), portals load with nothing in them, and file uploads land in the wrong OneDrive. If something is inexplicably empty, check identity before debugging anything else. Full detail in reference/00-claim-tenant.md § Step 2.5.

Phase 0.5 is mandatory: one intake, then run unattended

This skill is exportable. Whoever is running it is probably not the person who wrote it.

Design contract: ask everything at the start, then work alone. A full build contains four multi-hour waits and dozens of small decisions. Asking each one when you reach it pins the operator to the session for a day. reference/00-operator-profile.md collects all thirteen decisions in a single exchange — industry and accounts, which workloads, data depth, Sales Premium authorisation, live-send policy, journey shape, recovery policy, notifications, and the batched sign-ins.

Every worked example in this skill (the CPG brand families, the retail/grocery archetypes, the gen-ci-data.py product list) comes from one seller's territory. They are illustrations, not defaults. Inheriting them silently produces a demo that resonates with nobody.

State the privacy rule out loud: recommend fictional company names, because a demo tenant carrying real account names shows Customer B's pipeline to Customer A the moment it is demoed.

After intake, only three things justify interrupting the operator

1. An interactive password prompt — cannot be automated. Batch every sign-in at intake so this happens once, at a time of their choosing, rather than four hours in.
2. A destructive or commercial action not pre-authorised — deleting an environment, sending real email, accepting licensing terms.
3. A genuine dead end, after diagnosis, with every unblocked task already finished.

Everything else has a rule instead of a question:

If you catch yourself about to ask a mid-build question, it belongs in the intake. Add it to reference/00-operator-profile.md so the next operator is never asked it at that point again.

The single most important lesson: progress indicators lie

This recurs at every layer of the build. Tooling and portals report state confidently and wrongly, in both directions — claiming success that has not happened, and claiming in-progress long after work has finished.

Five separate pac commands returned confidently wrong answers:

And three UI surfaces do the same:

Only trust these verification methods:

The general rule for this whole playbook: a spinner is not evidence. Go look at the management surface.

Corollary — a form is not a spinner. If a portal is asking you something, answering it is the work, not a delay to wait out. This skill once told an operator CI – Data was not installed when it only needed a region selected. Never report a product unavailable until you have opened its own portal and completed whatever it asks for.

Never call an install failed before 60 minutes

Observed landing times: Sales Premium ~5.5 min, CS Demo Data ~20 min, Project Operations ~35 min, Field Service ~50+ min. pac application install frequently never returns even after the app has fully deployed, and hard-errors at exactly 60 minutes. I wrongly killed Field Service at 48 minutes; it had actually landed.

The Xrm.WebApi technique — use this constantly

Any open model-driven app page exposes Xrm in the top frame. Direct Dataverse reads/writes from there are dramatically more reliable than the admin UI widgets, which are hosted in cross-origin island-cluster iframes that intermittently fail with ERR_CONNECTION_CLOSED.

const base = Xrm.Utility.getGlobalContext().getClientUrl();
const r = await Xrm.WebApi.retrieveMultipleRecords('account','?$select=name&$top=50');
await Xrm.WebApi.updateRecord('account', id, { name: 'New Name' });

Use it for bulk edits, verification sweeps and anything the UI makes tedious.

⚠️ Batch your loops at 50–60 records. Every Xrm.WebApi call is a separate HTTP round trip, and creating a record in a terminal state costs two (create, then update statecode). A 300-record loop runs for minutes and will hit the automation tool's execution timeout mid-loop, leaving a partial write you may not notice. Verify the tally after every batch, and never schedule a whole class of record last — if that batch is the one that dies, the gap is invisible until something downstream fails.

Phase order

Run these in order. Later phases depend on earlier ones.

Phase 0.5 costs ten minutes and needs no tenant, which makes it the right way to spend a Phase 0 wait — and running it early is what buys the operator an unattended build. Its answers feed Phases 5.5, 6, 7 and 9, so collecting them late means asking questions those phases have already stalled on.

Ordering note: although numbered 0.5, treat the intake as the actual first action whenever the tenant already exists. Everything downstream reads from its decision record.

Phase 3 is the one everyone misses. A fresh environment has zero connections and every connection reference unbound, which silently blocks every first-party agent. Their admin pages just spin on "Loading" forever with no error. Do this before touching agents.

Phase 7 is irreversible. Customer Insights installs cannot be cancelled mid-cycle and may consume production licensing. Read reference/06-customer-insights.md before starting it.

Quick start

# 1. Authenticate AS THE CALDOVA TENANT ADMIN (interactive browser sign-in)
#    Ask the operator for the admin UPN: admin@caldova<NNNNNNNN>.onmicrosoft.com
#    Get it from CDX > My Dashboard > tenant row > Credentials
pac auth create --name caldova

# 2. Confirm the caldova profile is the ACTIVE one (look for the *)
pac auth list

# 3. Confirm which app templates the tenant licences
pac admin list-app-templates

Step 2 is not optional. If a previous profile is still active, every subsequent command silently targets the wrong tenant.

Then follow reference/01-environment-provisioning.md.

Do not create the environment with pac admin create --templates. It does not reliably set the "Enable Dynamics 365 apps" flag, and that flag is irreversible. Use the PPAC wizard. Details in the reference file.

Known-good outcome

A finished environment from this playbook has:

• ~18–22 published apps (count varies with which optional packages you install) — Sales Hub, Sales Team Member, Copilot Service workspace, Copilot Service admin center, Field Service (+ Mobile, + Connected), Project, Project Operations (+ Team Member), Resource Scheduling, Channel Integration Framework, D365 App for Outlook, Agentic Simulations, Power Pages Management, Power Platform Environment Settings, Solution Health Hub
• 8 connections, all Connected, with all connection references bound
• Customer Service agents configured (Case Management, Customer Intent, Knowledge)
• Environment Type = Production (no SANDBOX badge)
• Custom branded app header
• Demo data matching your industry

Run scripts/verify-environment.js to confirm all of the above in one call.

Honest limitations

One thing this playbook could not solve:

1. Publishing the first-party agents. 38 of 44 Copilot Studio agents ship as Draft and would not publish. PvaPublish API → 409 Conflict / ExternalServiceException, pac copilot publish → OrganizationServiceFault, Copilot Service admin center Publish → "Unable to publish Copilot Studio agents", and the Copilot Studio Publish button is disabled with agent status stuck on "Setting up…". Three independent paths failing identically = server-side provisioning state. Waiting 25+ minutes did not clear it. If you hit this, raise support referencing the PvaPublish 409. Agents still function for demo purposes where the admin surface enables them directly (Case Management, Customer Intent and Knowledge agents were all configured successfully).

That is the only unsolved item. Chapters 2 & 3 are no longer a dead end — see below.

Chapters 2 & 3: the Azure subscription gate

Full request procedure, states to wait for, and the tenant-scoping caveat live in reference/00-claim-tenant.md § Step 3. Summary below.

The Caldova CDX page (https://cdx.transform.microsoft.com/caldova) carries two Add-On experience cards, both fronted by * * * PRE-REQ: MUST ADD NEW AZURE SUB VIA MCAPS BYOT * * *:

This is not a permanent block — it is a procurement step:

1. Request a NET NEW Azure subscription via the MCAPS BYOT process → https://aka.ms/MCAPSBYOT. It must be net new; an existing subscription attached to another tenant will not do.
2. Wait for it to reach Status Completed / step AzTsPreReqsCompleted in the CDX tenant detail page, under Subscriptions. It appears there automatically once provisioned — you do not attach it by hand.
3. Only then do the Get Add-On buttons on the two cards actually work.

Verified Aug 2026: subscription ME-Caldova<NNNNNNNN>-{{USER_ALIAS}}-1 landed on the CDX tenant page with AzTsPreReqsCompleted / Completed, releasing both add-ons.

Do not change any tenant passwords. The CDX page states in caps that passwords must remain exactly as issued or the add-on experiences will not work. This is easy to trip over if you have been hardening the tenant.

Note the add-on subscription lives in the Caldova tenant, not your corporate tenant, so az login --tenant cadd283e-... as the Caldova admin is required before any az work against it.

Supporting documentation on that page

• Seller FAQ - Caldova Tenant
• STEP 1 - Caldova Demo Experience One-Time Setup Guide
• STEP 2 - Caldova Demo Experience Chapter Narrative

Reference files

JavaScript scripts are browser-console code. Paste into DevTools on any open model-driven app page, or run through Playwright. The Python script runs standalone.

⚠️ gen-ci-data.py ships with a CPG product portfolio and company list. Those are worked examples from the original build. Replace them with the operator's brand architecture from Phase 0 — a CDP dataset that disagrees with the CRM reskin breaks the exact cross-system unification demo it exists to prove.