What Information Is in the customizations.xml?

If you unpack a solution export, you find next to a "solution.xml" mainly one file: the "customizations.xml". For small solutions it is a few kilobytes, and for grown solutions it can reach several megabytes. It holds practically the entire system configuration.

The rough structure

Greatly shortened, the skeleton looks like this:

<ImportExportXml>
  <Entities>
    <Entity><EntityInfo>...</EntityInfo> ... </Entity>
  </Entities>
  <Workflows> ... </Workflows>
  <optionsets> ... </optionsets>
  <WebResources> ... </WebResources>
  <Roles> ... </Roles>
  <SiteMaps> ... </SiteMaps>
</ImportExportXml>

The file has a root element and below it a series of blocks, each holding one component type. The most important ones:

• "Entities" with the tables and everything attached to them
• "Workflows" for classic workflows, business rules, business process flows and Power Automate flows
• "optionsets" for global option sets
• "WebResources" for JavaScript, HTML, images and similar
• "Roles" for security roles with their privileges
• "SolutionPluginAssemblies" and "SdkMessageProcessingSteps" for plug-ins
• "AppModules" for model-driven apps

Not everything is in this file. Canvas apps and some newer components such as environment variables or custom APIs have folders of their own in the export. Processes appear twice. In the "Workflows" block there is one entry per process with name, type, status and primary table. The actual definition sits in the folder of the same name: as JSON for Power Automate flows, as ".xaml" for classic workflows and business rules. Which of them count as outdated is covered in outdated customizations.

What sits below a table

The "Entities" block is usually the largest part. Below each table you find the attributes with their technical name, data type, requirement level and the description, if one is maintained. Next to them are the saved queries for the views and the form definitions.

It is remarkable how much can be derived from this without touching the environment. Whether a field is used on a form is in the form definition. Whether a relationship also deletes the dependent records when the parent record is deleted is in the relationship block.

Two traps when reading

Nested XML in XML. The form definitions are stored as separate XML inside a text field. So you first read the outer tree, and then you check the inner content once more to validate the structure. Fortunately the solution import does exactly that for us.

Several containers with the same name. Below a table there is not one "forms" element but several. Each carries a type attribute for main form, quick view, quick create and card. If you only read the first one, you miss the rest. The same pattern shows up in other places, for example with email templates that sit one level deeper than expected.

What is not in there

What is missing is just as important. The "customizations.xml" describes the configuration, not the data and not the state of the environment.

It does not say how many records a table holds, how often a flow runs, how many users have a role or when a check was last carried out. The content of plug-in assemblies also stays closed, because compiled code sits there.

For an analysis this means a clear boundary. Everything that can be derived from structure and configuration is accessible. Everything that concerns runtime behavior is not.

Why reading it pays off

The export is the only view of a solution that needs no access to the environment. If you receive a foreign solution without access to the environment, you often get exactly that: a ZIP file. You can answer more from it than most people expect. That ranges from the quality of the documentation and the technologies in use to the dependencies that must be met at import.