Data modeling for a story
Model only the sentences the demo will say — reuse standard tables, add cfg_ customs where capital markets is not standard, and compose vanilla D365 because the packaged industry model is gone.
- Apply the maxim — model the demo's sentences, not the industry
- Decide when to reuse a standard table and when to add a cfg_ custom
- Explain why you compose vanilla D365 plus customs in 2026
Now you model Contoso’s world — but only the part of it the demo will talk about. Reuse Account, Contact, Opportunity, and Case where the story is standard; a mandate pursuit really is an opportunity. Add custom tables only where capital markets is not standard: a won mandate as a living record, the strategies you sell, the consultants who gatekeep, the onboarding projects and their KYC items, the RFP responses in flight, and the meeting notes that ground the Copilot beats.
Here is the model, rendered exactly. Hover any table to trace what it touches:
Standard tables in solid fill; cfg_ custom tables outlined. Hover a table to trace its relationships.
Every table on that canvas exists because a demo beat says its name. That is the
maxim, and it is a discipline: if no beat will show cfg_ConsultantCoverage, it
does not get built, however true-to-life it would be.
The data-modeler drafts 03-model/ as reviewable files — table and column specs
you read like code before anything touches the environment. Its Dataverse access
is describe-only, so modeling stays a paper exercise until the operator acts.
Discipline lives in the details: one solution, the cfg_ publisher prefix on
every custom table, and the whole thing exported back into the repo so the model
is versioned alongside the findings it serves.
Choosing the starting model
Microsoft’s current financial-services overview describes platform capabilities,
industry guidance, and accelerators. It does not establish that every packaged
industry component is available or retired.⊙
Check the particular component’s documentation before promising it. This
teaching example deliberately uses standard Dynamics 365 tables plus the
cfg_ tables its story needs; that is a design choice, not a claim that every
engagement must use the same model.
In the field
Ask the data-modeler to draft the cfg_ tables for one workload — say onboarding
and KYC. Review the spec as files. Then check the discipline: is there a single
solution, is every custom table prefixed, and does each one map to a beat you
could name out loud?
- 03-model/ — the table and column spec, reviewable as files
- One solution with the cfg_ publisher prefix, exported to the repo