3.2 Application Explorer & Element Designers

Application Explorer & Element Designers

Quick Answer: The Visual Studio Application Explorer (formerly the MorphX AOT) offers two primary views: Classic View (elements grouped strictly by type across the entire environment) and Model View (elements grouped hierarchically by Package and Model). Developers query metadata using powerful search syntax such as type:table, name:Cust*, model:ApplicationSuite. Modifying standard objects is accomplished by right-clicking the base element and selecting Create extension. Element designers enforce strict extension rules: you can add new fields, field groups, and indexes, but you cannot delete base elements or narrow field constraints. All elements are serialized to disk as granular, source-control-friendly UTF-8 XML files and validated by the Best Practice (BP) compiler framework.

---

1. Application Explorer Architecture: Classic View vs. Model View

The Application Explorer window (accessed via View -> Application Explorer or Ctrl+Alt+E) is the primary navigation portal for all metadata in Dynamics 365 Finance and Operations.

+------------------------------------+-------------------------------------+
| CLASSIC VIEW                       | MODEL VIEW                          |
| (Grouped by Element Type)          | (Grouped by Package -> Model)       |
+------------------------------------+-------------------------------------+
| [-] AOT                            | [-] AOT                             |
|   [+] Data Model                   |   [+] ApplicationSuite (Package)    |
|       [+] Tables                   |   [-] ContosoCustomizations (Package)|
|           CustTable (AppSuite)     |       [-] ContosoCustomizations     |
|           InventTable (AppSuite)   |           [+] Data Model            |
|           ContosoTable (Contoso)   |               [+] Tables            |
|       [+] Table Extensions         |                   ContosoTable      |
|           CustTable.ContosoExt     |               [+] Table Extensions  |
|   [+] User Interface               |                   CustTable.Contoso |
|   [+] Business Logic               |           [+] Business Logic        |
|       [+] Classes                  |               [+] Classes           |
+------------------------------------+-------------------------------------+

Classic View

• Structure: Organizes the entire Application Object Tree (AOT) by functional element type: Data Model (Tables, Views, Queries, Maps, EDTs, Enums), User Interface (Forms, Menus, Menu Items), Business Logic (Classes), Analytics, and Security.
• Behavior: Every element across all installed packages in the environment is visible in a flattened tree. Next to each element name, the owning model is indicated in square brackets (e.g., CustTable [ApplicationSuite]).
• Primary Use Case: Global searches, inspecting standard base objects, and exploring available system types when the specific owning model is unknown.

Model View

• Structure: Organizes elements hierarchically: Package -> Model -> Element Category -> Element Type -> Element Name.
• Behavior: Allows developers to collapse unneeded Microsoft packages (such as ApplicationSuite or ElectronicReporting) and focus solely on the custom models being modified.
• Primary Use Case: Day-to-day development within a dedicated custom model. It provides immediate visibility into what artifacts belong to that specific model and prevents accidental modifications to unintended packages.

Comparison: Classic View vs. Model View

---

2. Advanced Search & Filtering Query Syntax

Application Explorer contains a powerful search engine at the top of the window. Relying on simple keyword searches is inefficient and often times out because the AOT contains over 100,000 metadata artifacts. Developers must master property-based query syntax.

Core Filter Tokens

Combining Filters

Filters are combined using commas (,), which represent a logical AND condition:

• Find all customer-related tables in ApplicationSuite:

  type:table, name:Cust*, model:ApplicationSuite
  

• Find all table extensions created in your custom model:

  type:tableextension, model:ContosoCustomizations
  

• Find all classes with "Invoice" in the name across the entire AOT:

  type:class, name:*Invoice*
  

• Find recently modified forms in a specific custom model:

  type:form, model:ContosoCustomizations, modified:recent
  

Exam Trap: Do not use SQL wildcards (%) or Boolean words (AND, &&) in the Application Explorer search bar. Use standard asterisks (*) for wildcards and commas (,) for conjunctions.

---

3. Visual Element Designers: Creating vs. Extending Elements

When working in Visual Studio, developers either create base elements (brand-new custom objects) or extension elements (extensions of existing Microsoft or partner objects).

Creating Extension Elements

To extend an existing element:

1. Locate the base element in Application Explorer (e.g., CustTable in ApplicationSuite).
2. Right-click the element and select Create extension (or Create extension in new project).
3. Visual Studio automatically creates an extension file named <BaseElementName>.<ExtensionModelName> (e.g., CustTable.ContosoCore) and places it into the active project's bound model.

What Can and Cannot Be Done in Table Extension Designers

+-------------------------------------------------------------------------+
| TABLE EXTENSION DESIGNER PERMISSIONS (e.g., CustTable.ContosoCore)      |
+-------------------------------------------------------------------------+
| [YES] ALLOWED (Additive & Expanding)                                    |
|   + Add new custom fields (e.g., Contoso_CreditScore)                   |
|   + Add custom fields to standard Field Groups                          |
|   + Create brand-new custom Field Groups                                |
|   + Add new Indexes (unique or non-unique)                              |
|   + Add new Table Relations                                             |
|   + Add new Mappings to Maps                                            |
|   + Increase EDT string length (if property allows)                     |
+-------------------------------------------------------------------------+
| [NO] PROHIBITED (Destructive & Narrowing)                               |
|   - Cannot delete existing base fields                                  |
|   - Cannot change the data type of existing base fields                 |
|   - Cannot reduce string length of existing fields                      |
|   - Cannot delete standard relations or standard indexes                |
|   - Cannot modify base validation logic directly in designer            |
+-------------------------------------------------------------------------+

Form Extension Designers

• Permitted: Adding new controls (Tabs, TabPages, ButtonGroups, Buttons, Grids, StringControls) into existing form control extension points; adding new data sources; modifying control properties like Visible or Enabled (subject to form patterns).
• Prohibited: Deleting standard controls; reordering base controls outside their designated group; removing base data sources; violating the target form's applied Form Pattern.

Enum Extensions

• To add an enum value to a standard base enum, the base enum's IsExtensible property must be set to True.
• If IsExtensible = False, the enum cannot be extended via designer. The developer must submit an extensibility request to Microsoft to toggle the flag in a future platform update.

---

4. Underlying XML Serialization of Metadata

Every element in the AOT is persisted on disk as a clean UTF-8 XML document. When a table extension is created, Visual Studio does not duplicate the base table's definition; it writes an XML delta document containing only the custom modifications.

Sample Table Extension XML (CustTable.ContosoCore.xml)

<?xml version="1.0" encoding="utf-8"?>
<AxTableExtension xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Name>CustTable.ContosoCore</Name>
  <Fields>
    <AxTableField xmlns="" i:type="AxTableFieldString">
      <Name>Contoso_LoyaltyTier</Name>
      <ExtendedDataType>ContosoLoyaltyTierId</ExtendedDataType>
      <HelpText>@ContosoCore:LoyaltyTierHelp</HelpText>
      <Label>@ContosoCore:LoyaltyTierLabel</Label>
      <StringSize>20</StringSize>
    </AxTableField>
  </Fields>
  <Indexes>
    <AxTableIndex>
      <Name>Contoso_LoyaltyIdx</Name>
      <AllowDuplicates>Yes</AllowDuplicates>
      <Fields>
        <AxTableIndexField>
          <DataField>Contoso_LoyaltyTier</DataField>
        </AxTableIndexField>
      </Fields>
    </AxTableIndex>
  </Indexes>
  <PropertyModifications />
</AxTableExtension>

Advantages of Granular XML Metadata

1. Version Control Integration: Git and TFVC can merge XML files seamlessly. If Developer 1 adds a field to CustTable in ModelA and Developer 2 adds a field in ModelB, there is zero file contention because each extension is an entirely separate XML file on disk.
2. Clean Continuous Integration: Build agents compile metadata directly from the XML sources without requiring an active AOS runtime instance.

---

5. Best Practice (BP) Indicators in Designers

The Best Practice (BP) Framework runs continuously during development and full builds. Warnings and errors appear directly in the Visual Studio Error List window.

Critical BP Rules Tested on MB-500

Suppressing BP Warnings

If a specific Best Practice check cannot be satisfied for architectural reasons, developers can suppress it using an XML BP Ignore File (AxIgnoreDiagnosticMarker.xml placed in the model folder) or by applying the [SuppressBPWarning("BPCheckName", "Justification")] attribute in X++ code.

---

6. Exam Traps & Real-World Pitfalls

• Exam Trap 1: Attempting Prohibited Table Extension Operations. A question asks how to shorten the standard Name field on CustTable from 60 characters to 40 characters using a table extension. The correct answer is that you cannot shorten string lengths or delete fields via extensions; extensions can only expand or add capabilities, never contract or destroy base schema.
• Exam Trap 2: Extending a Non-Extensible Enum. A scenario requires adding a new payment type to a standard base enum, but the option to create an extension is disabled in Visual Studio. The root cause is that the enum's IsExtensible property is set to False. The developer must log an extensibility request with Microsoft or create an alternate data structure.
• Exam Trap 3: Application Explorer Search Delimiters. If a candidate writes type:table and name:Cust* in Application Explorer, no results will return. The search engine requires comma delimiters (type:table, name:Cust*).
• Exam Trap 4: Hardcoding Strings. Creating form buttons or table fields with raw English strings instead of label references (@ModelLabel:StringId) generates immediate Best Practice compiler warnings that can fail gated build pipelines.