Dataverse best practices for architecture

In this next post as part of my series on solution architecture for the Power Platform, continuing to look at data we’ll focus on some best practices for designing architectures for Dataverse and developing on Dataverse in general! Catch up… So if you haven’t… READ MORE [https://lewisdoes.dev/bl
bike chain number one
Photo by Miguel Á. Padriñán on Pexels.com
In: Low Code Lewis Content 🚀

In this next post as part of my series on solution architecture for the Power Platform, continuing to look at data we’ll focus on some best practices for designing architectures for Dataverse and developing on Dataverse in general!

Catch up…

So if you haven’t yet read the previous posts in this series, be sure to catch up before continuing to read here! Check out the post below…

Okay… now let’s dive into a few best practices to consider!

Continuous development

So my first tip to you friends relevant to Dataverse even more so than other database offerings is to continue to keep on top of developments to your data schema! This should not be something you design and forget about. Microsoft can publish their own enhancements to the Common Data Model, so more so with Dataverse than any other data platform or development language, keep on top of this thing!

Community tools

When working with Dataverse there’s a bunch of community tools available in XrmToolBox that you can use to do things like generate ERD diagrams of a Dataverse schema. Solution architects, check this out!

https://www.xrmtoolbox.com/

When working with ERD generators and tools similar, ensure you don’t include every column of every table included in your solution in the ERD. Microsoft out the box tables in the Common Data Model have LOADS of columns you probably wont use in your solution so it’s not necessary to include these. ERDs should be easy enough to understand without extra jargon in the way to have to filter through.

Stop avoiding the Common Data Model

So friends, stop avoiding the Common Data Model. Use the out the box tables and extend them where you can. You’ll find when it comes to a time you want to implement the use of a Dynamics 365 solution or add-ins the Dynamics 365 or the Power Platform from Microsoft that they’re built to work with the tables in the common data model, so its in your best interest to attempt to use these tables where possible.

Some things to avoid…

So friends before we wrap up, here’s some extra tips and tricks and things to avoid when implementing using Dataverse…

  • Use global or non-global choices correctly and as appropriate
  • Set the data ownership for tables correctly and utilise business units and teams for security structure
  • Don’t over do it on creating tables, use the Common Data Model
  • If you’ve got too many columns on a table think about whether some should’ve been in a different table
  • Reconsider the use of the boolean / yes/no data type to use choices.
  • Don’t create poor user experiences by not using all of the tools available for model-driven apps in Dataverse.

What’s coming up?

So friends, this’ll be the last post around a few considerations for data topics when architecting Power Platform solutions. In my next posts we’ll look specifically at the lifecycles of the solutions we’re implementing and planning for ALM (application lifecycle management). Stay tuned! 🚀

Written by
Lewis Baybutt
Microsoft Business Applications MVP • Power Platform Consultant • Blogger • Community Contributor • #CommunityRocks • #SharingIsCaring
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to LewisDoesDev.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.