0% found this document useful (0 votes)
5 views9 pages

Solution Structure

The document outlines the structure and components of a solution package in Power Platform, detailing the contents of Customizations.xml, Content_Type.xml, and Solution.xml. It explains the various sections such as Logic, Access & Security, Apps, Integration, Visual & UI, and Mapping, along with their specific roles and metadata. Additionally, it describes the solution identity, publisher information, root components, missing dependencies, and localized names within the solution package.

Uploaded by

dhakaravina22
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views9 pages

Solution Structure

The document outlines the structure and components of a solution package in Power Platform, detailing the contents of Customizations.xml, Content_Type.xml, and Solution.xml. It explains the various sections such as Logic, Access & Security, Apps, Integration, Visual & UI, and Mapping, along with their specific roles and metadata. Additionally, it describes the solution identity, publisher information, root components, missing dependencies, and localized names within the solution package.

Uploaded by

dhakaravina22
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Solution Package

[Link]

[Link] is the master metadata manifest. If a component


is part of your solution, its "ID card" or "registration papers" are kept in
this file.

Here is what each of those sections specifically contains (and what it


doesn't):

1. The "Logic" Sections


• <Workflows>: This contains the definitions for Classic
Workflows, Actions, and Business Rules.
• Note: It does not contain the logic for Power Automate
"Cloud Flows" (those are stored in separate JSON files in your
solution zip).
• <WebResources>: This is the metadata for your JavaScript, CSS,
and Image files.
• What’s inside: The Name (e.g., ravi_script.js), the Display
Name, and the Type.
• What’s NOT inside: The actual code. The code is in the
/WebResources/ folder we saw in your first screenshot.
2. The "Access & Security" Sections
• <Roles>: Contains Security Roles. It defines the permissions
(Read, Write, Delete) for every table in the solution for a specific
role (like "Asset Manager").
• <FieldSecurityProfiles>: If you have specific columns that only
"Admins" can see (Field Level Security), those rules are here.
3. The "Apps" Sections
• <AppModules>: This is the definition of a Model-driven App. It
defines which tables, dashboards, and views are included in that
specific app.
• <AppModuleSiteMaps>: This is the Navigation Menu (the left-
hand sidebar) for your Model-driven app.
• <CanvasApps>: Metadata about your Canvas App (its Name, ID,
and which environment it belongs to).
• Note: The actual "App" (the buttons and formulas) is in
the .msapp file.
4. The "Integration" Sections
• <Connectors>: Metadata for Custom Connectors you’ve built to
talk to external APIs.
• <connectionreferences>: This is a very important modern piece. It
acts as a "bridge." Instead of hard-coding your
username/password into a Flow, the Flow points to a "Reference,"
and the Reference points to your actual connection. This makes it
easier to move apps between Dev and Production.
5. The "Visual & UI" Sections
• <optionsets>: These are Global Choices. If you have a dropdown
(like "Country List") that you want to use on 10 different tables, it is
defined here once so you don't have to recreate it 10 times.
• <CustomControls>: Metadata for PCF Controls (Pro-code UI
components like a custom slider or a map view).
• <appaction_appactionrule_classicrulesset>: This is the
metadata for the Modern Command Bar (the new way to make
buttons using Power Fx instead of the old Ribbon XML).
6. The "Mapping" Sections
• <EntityMaps>: This defines "Data Mapping."
• Example: When you click "Convert to Order" on a "Quote,"
this metadata tells the system: "Take the 'Address' from the
Quote and put it in the 'Address' field on the Order."
• <EntityRelationships>: This defines the links between tables that
weren't already defined inside the <Entity> tags.
Content_Type.xml

1. The Root Element (<Types>)

The file starts with the <Types> tag.[2] The xmlns (XML Namespace)
points to the standard OpenXML schema.[2] This tells the platform that
this file follows the rules for Microsoft packaging.[2]

2. The <Default> Section (File Type Rules)

These lines define "global rules" for every file with a specific extension in
your solution.

• What it does: It tells the system, "Whenever you see a file ending
in .js, treat it as an application/octet-stream (binary data)."
• In your file: It defines rules for common web and app files:
o xml, json, xaml: Configuration and data files.[2]
o css, js: Web resources for styling and logic.[2]
o png: Images.
o msapp: This is the core file extension for a Canvas App.[2][3]

3. The <Override> Section (Specific Components)

This is the most important part of your file.[2] While <Default> sets
general rules, <Override> points to specific files inside your solution.
• WebResources: Most of your overrides start with
/WebResources/.[2] These are the custom scripts and logic files
you've added to your solution.
o Example: ravi_filterAssetsBasedOnUserRole... is a
JavaScript file (Web Resource) used for logic in your app.[2]
o The GUIDs: The long strings of numbers (like F111-8342-
7CED...) are unique IDs generated by the Power Platform to
ensure no two files conflict, even if they have similar names.
• CanvasApps: Toward the bottom, you see overrides for
/CanvasApps/.[2]
o These specifically point to Background Images (e.g.,
ravi_page2_883a1_BackgroundImageUri).[2] This shows that
your Canvas App has custom images or branding uploaded to
it.[2]

4. Why is everything application/octet-stream?

• In a standard web environment, a .js file might be text/javascript.[2]


• In Power Platform solution packages, application/octet-stream is
used as a generic binary container.[2] It tells the platform to "just
take this file as-is" and store it in the database (Dataverse) without
trying to read or execute the code inside it during the move.

[Link]
1. The Solution Identity

The first few lines define the basic "ID Card" of the solution:

• <UniqueName>: The internal name of the solution (e.g.,


AssetManagmentSystem). This cannot be changed once
created.
• <Version>: The current version number ([Link]). The
system uses this to know if it should "Upgrade" or "Update" an
existing app when you import it.
• <Managed>: This is a critical setting.
• 0 (Unmanaged): The solution is still in "Development" mode.
You can edit everything.
• 1 (Managed): The solution is "Locked." It is meant for
Production. Users cannot easily change the components.
Your snippet shows <Managed>1</Managed>, meaning
this is a Managed Solution.

2. The Publisher (<Publisher>)

This section tells the system who created the app.

• It includes the publisher’s name, their unique prefix (like cra7c or


ravi), and their contact details.
• The Prefix is important because it is added to the beginning of
every new table or column created (e.g., cra7c_AssetName).

3. Root Components (<RootComponents>)

This is the most important section for a developer. It is a complete list


of every "top-level" item inside the solution.

Instead of showing the whole design, it just lists the ID and Type. For
example:

• Type 1: Entity (Table)


• Type 2: Attribute (Column)
• Type 29: Web Resource (Javascript/CSS)
• Type 60: System Form
• Type 300: Canvas App

Example of what a RootComponent looks like:

codeXml

<RootComponent type="1"
schemaName="cra7c_AssetAllocation" />

This tells the system: "Go look in [Link] for a Table named
cra7c_AssetAllocation and install it."
4. Missing Dependencies (<MissingDependencies>)

This is the "Safety Check" list.


If your "Asset Management" app relies on a table that is not in this
solution (maybe a standard Microsoft "Account" table), it is listed here.

• When you import the solution, the Power Platform checks this list.
• If a dependency is missing in the target environment, the import
will fail with an error. It prevents you from installing an app that
won't work.

5. Localized Names and Descriptions


• <LocalizedNames>: The display name of the solution in
different languages.
• languagecode="1033": This is the LCID (Locale ID) for
English (United States). If you had a French version, you would
see a section for 1034.

You might also like