If you have worked with Dynamics (or Dataverse or Common Data Service) for sometime you have probably said some variation of “Well, Dynamics is weird”. This tends to come up for me when troubleshooting odd issues. It is so easy to assume a feature will function one way but then upon further inspection that is not quite the case.
To be clear, I do not mean this is a bad way. It’s just that there are a few features that may behave a bit odd and that knowledge only comes from spending time living with them for a while.
So today I want to walk through a few items that I have called weird in the past and talk about why that is.
Activities
Activities are weird. Security for Activities is especially weird!
Activities are not regular entities. They are but they also are not. There are two main reasons they are weird.
- Regarding – Activities automatically get the lovely Regarding field. This magical field allows you to connect that record with any activity-enabled entity. This is great for flexibility but causes some confusion in reporting or integrations.
- Security – all Activities fall under the same security. If I have organization read to the Activity entity this means I can see all Calls and Appointments and Letters, etc. Of course, this is still based on the owner of that Activity so it doesn’t have to be a free for all.
Now it is very interesting when these two points come together. For example, you may have a situation where you want to track complaints or similar. Naturally this could fit as an Activity because you may want to be able to easily link this with an Account, Contact or Opportunity (insert magical regarding field). However this gets tricky because you may not want these to be visible to everyone. Out of the box, this custom Complaint Activity would be accessible to everyone who can read/create Activities. Not a show stopper, but some additional conversation might be needed to determine if this is the best solution.
Don’t even get me started on the Opportunity Close records! Those are activities but they don’t show up as Activities and need special care when searching.
Connections
Connections are weird. These are cool because you can link two records together. However, creating random linkages can cause confusion.
When you start using connections you also create Connection Roles. These Roles have related roles for the opposite side of the relationship (for example, a “Parent” could be linked to a “Child”). This adds nice structure but can be a bit strange when users are entering this data. More on Connections and Connection Roles here.
How these really get interesting is when we start talking about reporting and automation. When you create a connection it is not just one record it’s actually 2! It will create one record for each side of the relationship. However there is no way to quickly see what side was created first.
There was a time in my life when I was young and optimistic where I wanted to use Connections to track referrals. Unfortunately additional data points needed to be captured along with the referral and then reporting needed to be done on these records. What do you do when your one referral is actually two records? How should your custom fields be updated? Can we ensure those appear correct when viewed from both sides? Should one record be identified as primary? As you can see, this can quickly get complicated and confusing.
Addresses
Addresses are also weird. If you have never used the “More Addresses” area then maybe this does not apply to you but it is interesting nontheless.
On Accounts and Contacts they have Address fields already included out of the box. Then you have the option to also show the “More Addresses” area where additional addresses can be stored. What is not as obvious, is that all the addresses entered into Address 1 or Address 2 on the Account and Contact forms is actually still stored in the Address Table.
So when you enter in an Accounts Primary address, this is stored in the Account table and also in the Address table with an Address Number = 1.
This might not matter for many vanilla scenarios but if you start having automation that moves or copies addresses then this background is important to keep in mind.
Additionally, If your users will be entering additional addresses and want to see them all in one place, then you will have to edit the Address Associated View to ensure all are displayed. (In older versions we were not able to modify this view but it appears to be editable now.)
To Sum Up: Dynamics is Weird but We Love It Anyway
These are just a few of the items that make me say “well, that’s weird”. Digging in to these odd scenarios always uncovers interesting information. Hopefully this will help on your Dynamcis / Power Platform journey as well.
What else do you think is weird in Dynamics?
Connections have a field called “Is Master”. This is used to defined the primary direction of the connection. You can use this to filter connections, such that only 1 connection is returned.
Thank you!
I thought this was the case but didn’t see it when I was prepping this post.
This solves a few of our issues with connections and limits the view but we still have complications around the rest of the data.
Are you using connections? Do you find them confusing? 🙂
I used to say that you should never use connections in place of actual relationships, until I discovered a business that could not agree on how data was connected. After a very long time we settled on connections, because that gave the business the power to manage the relationships. If they needed more it was quick to add another connection role and deploy it.
The pitfall came when they had to report on it, but Power BI is smart enough to handle joining tables, so it works out.