Man’s greatness lies in his power of thought. ~ Blaise Pascal
As the functionality in Dynamics 365 grows I find there are more options and check boxes which I have no idea what they do, today I came across a check box called Include entity metadata
Dynamics 365 developers should not be comfortable using functionality you don’t fully understand because it could cause you problems later and sometimes once you enable a setting it cannot disabled, such as setting entities values
- Business process flows
- An entity being an activity
Entity ownership can cause problems when you need to apply security to organisation entity – CRM Entity ownership – How do you decide?, you need to get the decision right first time or don’t make it organisational if you think there is a chance it will need security.
Dynamics professionals are craftsman (Are you a Dynamics Craftsman or a CRM developer?) their main tool is Microsoft Dynamics 365/CRM. You must become a master of Dynamics 365 and understand the nuances, limitations and capabilities.
If you don’t understand certain functionality, work out how it works and the underlying logic, keep asking questions until you can explain it to someone else.
Dynamics CRM/365 developers you should use the SDK rather than Google and you should always start with SDK.
Dynamics 365/CRM metadata has the potential to confuse people because it can prove a slippy subject for people to grasp and when explaining it you end up saying things like “it is data about data”.
To understand how metadata works in Dynamics CRM/365 read this article – CRM 2015 – Understanding CRM Metadata
A quick explanation on field metadata such as (I am only going to list some of the more interesting fields available not all of them)
A field itself holds a value but the metadata is
- Display name
- is it audited
- is it a manged field
The metadata doesn’t affect the value of the field but it changes the way it interacts with Dynamics 365.
What is entity metadata
If there is a checkbox for entity metadata, we need to understand what metadata there is for an entity.
On the entity form in the solution, the entity metadata is all the check boxes like notes, activities, queues, access teams etc. When this gets broken down in the solution packager to an xml file you can see all these check boxes have a field and a value.
When you don’t select include metadata The entity name in the entity xml element
If you select to include metadata you get the metadata
<fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”false”>
<condition attribute=”modifiedon” operator=”last-x-days” value=”10″/>
In the solution file you can also see what happens when you untick
<RootComponent type=”1″ schemaName=”appointment” behavior=”1″ />
<RootComponent type=”1″ schemaName=”appointment” behavior=”2″ />
Why and the When?
This functionality and check box was added with the subcomponents functionality. Before CRM 2016 you added the whole entity, forms, views and everything else to a solution file. CRM 2016.
You can only use subcomponents if the environment you are importing your solutions to includes the metadata.
In the blog post CRM 2016 – What’s the best way to organise solutions in Microsoft Dynamics CRM I discuss the different ways you can organise solutions.
If you choose a base solution method, you might have solutions imported into development environments as managed (to stop dependencies being created for them). You may then build on top of the base solution in separate environment and solution. You could add a managed entity, bring in no existing subcomponents and only add new fields. In this scenario you new solution wouldn’t need the entity metadata because it exists in the core solution.
It turned out to be obvious what was happening but it’s better to confirm you assumptions and don’t give them time to cause you problems.
Writing this post has helped me think through the process of building customisations on top of managed solutions