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
Comments
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.