Dear community,
currently I'm writing a technical documentation for a Dynamics system to which I took over responsibility and I would like to find out if previous developers modified standard fields. I'm familiar to document metadata exporter from XRM toolbox and I know how to identify custom entities and fields, but I struggle to identify those standard fields which have been modified.
For option sets I could check if they contain values matching the custom publisher prefix, but latest whit text fields this won't work. So for example if default length was adjusted.
Do you have some ideas how to find this?
Thanks in advance!
SteRe
@GuidoPreite have confirmed if you update the Display Name of out of the box (no prefix) column, the Columns ModifiedOn is updated.
Hi @SteRe , you right, that metadata contains the ModifiedOn and CreatedOn, I just checked in one of my trials.
I don't know if the ModifiedOn will be updated when you change a standard field (but I suppose yes) because for standard fields the default is "1900-01-01T00:00:00Z"
Hi @GuidoPreite @Fubar @cchannon thanks for your inputs!
It took some time until I head enough time to check the different approaches. Finally I went with the idea of my former colleagues to setup a cloud flow.
In here some details how this could be done
1. Entity metadata
to get the relvant information you can run an HTTP request with following setup:
<environment url>/api/data/v9.1/EntityDefinitions(LogicalName='<entityname>')/Attributes
Newer API versions might work as well, I did not check for differences. Replace <entityname> with the entity to be checked, for example account.
In you flow you will loop over the fields found. In this loop I've implemented a filter to reduce list of fields. For example I excluded fields where logical name starts with "msdyn" oder "msft". To find those custom fields or modified standard fields I used a comparison
ticks(items('Apply_to_each_Attribute')?['CreatedOn'] != ticks(items('Apply_to_each_Attribute')?['ModifiedOn']
So those two properties exist in data model to each field as meta attribute. The ticks() function converts the value into a date so it can be compared.
At least in UI there is no information about this, but it looks like if you get the meta data via API call there are some more information you can fetch.
"A colleague came up with the idea of setting up a flow to extract meta data and have some condition to check which fields have a different modified date then its creation date." afaik the metadata doesn't contain who and when tables and columns were created and modified, the only exception I know are system views, so by getting the created date of a system view you can get the created date of the table but not the modified date of a table or of a column.
Thanks a lot for your suggestions! I will check what can be implemented with low effort. All comparissons against a plan ootb system sounds like bigger effort - independent if checked based on data model in git or a standard installation.
But it brings some additional idea.... Based on a default system I could export the data model, extract it and push to git. On top I could do the same with my system and see the adjusted fields in the commit.
A colleague came up with the idea of setting up a flow to extract meta data and have some condition to check which fields have a different modified date then its creation date.
I'll check which of those options I can follow (just by time) and keep you updated what worked.
No standard tool etc. I would
The answer is not straightforward, but if you still have access to the environment where the customizations were made (i.e. where they are unmanaged) then you can use the Solution Layers Explorer XRM Toolbox tool to quickly view where unmanaged customizations have been applied.
Assuming that the environment where the customizations were made is not your production environment and that the customizations were then migrated to Prod via solution, you will then need to check the produciton environment to compare what you found in dev (that is, just because an unmanaged customization exists in dev does not mean that it was actually migrated to prod). This will be time-consuming, but it will give you a definitive picture of the customizations applied.
The Common Data Model https://microsoft.github.io/CDM/ will give you indication of the default properties of the tables and columns but I am not aware of a tool comparing this information with a customized environment.
stampcoin
17
mmbr1606
15
Super User 2025 Season 1
ankit_singhal
11
Super User 2025 Season 1