Should We Reuse Standard Dynamics 365 / Dataverse Tables for Our In‑House Apps?
1) Why We’re Talking About This
We’re starting an important conversation: when we build apps internally, should we lean on the standard tables already in Dynamics 365 / Dataverse (like Account, Contact, Opportunity, Project), or should we keep spinning up new SharePoint lists or custom Dataverse tables?
We’ve also seen in new tools like CustomerVoice and CSMS that the links with projects and customers can sometimes feel contrived and difficult to handle, with broken or buried relationships. This highlights why we need to think carefully about our model.
This isn’t just a technical choice – it’s about making our data easier to find, easier to trust, and easier to connect to the rest of our systems.
2) The Big Picture
- Default mindset: Reuse what’s there. Dynamics and Dataverse already give us a structured model for common business concepts.
- Why? It saves us from creating duplicate data stores, makes integration smoother, and keeps security/audit trails consistent.
- When to customise: Only when there’s a clear need and we’ve confirmed the standard model doesn’t fit.
- SharePoint lists: Great for light registers and document tracking, but not for core data like People, Projects, or Opportunities.
3) What Happens Today
Right now, teams often set up new SP lists or custom tables to solve local needs. It works quickly, but:
- We end up with multiple versions of “the truth” for core things like customers or projects.
- IDs and relationships don’t line up cleanly across apps.
- Analytics and governance get harder, because the catalogue sees fragmented, duplicate entities.
4) Choices on the Table
| Option | Best For | Why It Helps | What to Watch Out For |
|---|---|---|---|
| Reuse Standard Tables | Core business data (Accounts, Contacts, Opportunities, Projects, Activities) | Consistency, built‑in relationships, security, APIs, timelines | Needs licensing and a bit of learning CDM conventions |
| Extend Standard Tables | When standard tables cover most but not all of what we need | Keeps everything integrated; avoids duplication | Avoid over‑customisation; apply change control |
| Custom Dataverse Tables | Brand‑new domains with no standard fit | Flexibility, still get Dataverse security/audit | Adds governance overhead; risks overlap |
| SharePoint Lists | Document‑centric or tactical, short‑term use | Easy, cheap, already in M365 | Weak on relationships, security, catalogue alignment |
5) A Reuse‑First Approach
Let’s flip our thinking:
- Look in the box first. Map needs to standard entities.
- Extend if needed. Add fields or relationships where that makes sense.
- Custom as a last resort. Only after we’ve proven it’s necessary.
- SP lists for the light stuff only. Great for registers, not for core entities.
6) Simple Decision Guide
Ask these questions:
- Does a standard entity already exist for this?
- Will we need relationships, audit, or security controls?
- Will the data be used in BI, APIs, or warehouse pipelines?
- Is this something we’ll need for the long haul?
- Can it be catalogued cleanly?
If most answers are “yes” → start with standard tables.
7) How It Maps in Real Life
- People → Use Contact (external) or System User/Employee (internal) with roles.
- Opportunities → Use Opportunity (already rich in relationships and history).
- Projects/Engagements → Use Project where licensed, or build a Dataverse entity that mirrors CDM naming and lookups.
- Survey Response / Interactions → Log as an Activity linked to Contact/Project/Case.
8) Why This Matters for Governance
- Reuse avoids duplicates and reduces catalogue clutter.
- Security roles apply consistently (field‑level, audit trails).
9) Risks and How We Handle Them
- Licensing costs → Start small (minimum SKUs), scale up if it works.
- Customisation creep → Use design guardrails and regular reviews.
- Data duplication → Check catalogue before building anything new.
10) What Success Looks Like
- Most new app data aligns to standard entities.
- No parallel SP lists holding the same “truth”.
- Catalogue completeness ≥95% for pilot scope.
- Smooth nightly data flow from Dataverse into the warehouse.
- Positive user feedback: the data is easier to find, connect, and trust.
11) Next Step
Run a 90‑day pilot where we commit to a reuse‑first approach, the Data Engineering team may already have a use case, focusing on People, Opportunities, and Projects. We’ll prove whether standard Dataverse entities work for us and report back with recommendations.