Study guide
3.2 Application Explorer & Element Designers
Microsoft Dynamics 365: Finance and Operations Apps Developer Associate MB-500
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Cloud & Ecosystem Architecture
1.1 Cloud vs On-Premises Architecture & Deployment Typologies 1.2 Microsoft Ecosystem Integration & Extensibility Boundaries 1.3 Lifecycle Services (LCS) & Implementation Portal
2 Chapter 2: ALM, Environments & Unified Developer Experience
2.1 Package Deployment & Servicing 2.2 Unified Developer Experience (UDE) & Power Platform Admin Center 2.3 Environment Management & Governance
3 Chapter 3: Visual Studio Development & Metadata
3.1 Visual Studio Extension Models & Packages 3.2 Application Explorer & Element Designers 3.3 Database Synchronization & Visual Studio Debugging
4 Chapter 4: Azure DevOps Version Control & CI/CD
4.1 Version Control Architecture: TFVC vs Git in F&O 4.2 Branching, Merging & Conflict Resolution 4.3 CI/CD Build Pipelines & Artifact Generation
5 Chapter 5: UI Elements: Forms, Menus & Labels
5.1 Form Design & Form Patterns 5.2 Menus, Menu Items & Navigation 5.3 Label Files & Localization
6 Chapter 6: Data Model: Tables & Relational Design
6.1 Table Design & Extension 6.2 Views, Queries & Maps 6.3 Data Entity Design & Modeling
7 Chapter 7: Classes, Attributes & AOT Modifiers
7.1 Class Architecture & Access Modifiers 7.2 Attributes & Reflection 7.3 Event Handlers & Pre/Post Method Events
8 Chapter 8: X++ Core Programming & CRUD Operations
8.1 X++ Syntax, Control Flow & Global Functions 8.2 Data Manipulation & CRUD Logic 8.3 Best Practice Rules & Compiler Diagnostics
9 Chapter 9: Advanced OOP, Chain of Command & Extensibility
9.1 OOP Principles & QueryBuilder Class 9.2 Chain of Command (CoC) Implementation 9.3 Extensibility Patterns & Non-Breaking Changes 9.4 Event Handler Classes & Delegate Architecture 9.5 Variable Scoping, Declaration Placement & Object Lifetime
10 Chapter 10: F&O Frameworks & SysTest Unit Testing
10.1 SysOperation Framework Architecture 10.2 Workflow Framework & SysExtensionSerializer 10.3 SysTest Framework & Test Explorer
11 Chapter 11: Reporting Architecture & SSRS Reports
11.1 Reporting Architecture & Datastores 11.2 Report Data Providers & Contracts 11.3 SSRS Report Design, Deployment & Security 11.4 Determining When to Use a Specific Reporting Tool or Platform
12 Chapter 12: Business Intelligence, Workspaces & Electronic Reporting
12.1 Electronic Reporting (ER) Framework 12.2 Power BI Integration & Analytical Workspaces 12.3 Workspaces, Tiles, Lists & KPIs 12.4 Excel Integration & Office App
13 Chapter 13: Integration Patterns & Service Endpoints
13.1 Integration Pattern Evaluation & API Selection 13.2 Custom Services & SOAP/REST Endpoints 13.3 Consuming External Services & REST/SOAP APIs
14 Chapter 14: Data Management Framework (DMF) & Batch Processing
14.1 DMF Concepts, Projects & Sequencing 14.2 Entity Change Tracking & Recurring Integrations 14.3 Composite Entities & Batch OData API 14.4 Monitoring Entity Status, Availability & Job Execution
15 Chapter 15: Power Platform, Business Events & Azure Integrations
15.1 Dual-Write & Virtual Entities 15.2 Business Events Framework 15.3 Azure Key Vault Integration & Secure Storage
16 Chapter 16: Role-Based Security & Extensible Data Security
16.1 Role-Based Security Architecture 16.2 Extensible Data Security (XDS) Policies 16.3 Security Enforcement & Best Practices
17 Chapter 17: Performance Optimization & Data Access Patterns
17.1 Table & Form Caching Mechanisms 17.2 Temporary Tables & Set-Based Operations 17.3 Query Tuning, Indexes & Concurrency 17.4 Diagnostics: Trace Parser, Async & Sandbox Frameworks 17.5 Tuning Variable Scope, Buffer Lifetime & Memory Pressure
3.2 Application Explorer & Element Designers
Key Takeaways Explain This Topic AI
Application Explorer provides two complementary viewing modes: Classic View, which flattens all elements across models by element type, and Model View, which organizes elements hierarchically by Package and Model.
Advanced search syntax in Application Explorer uses comma-separated property filters such as type:table, name:Cust*, and model:ApplicationSuite to precisely query metadata.
Element designers enforce strict non-destructive constraints on extensions: developers can add fields, field groups, indexes, and relations, but cannot delete base fields, reduce string lengths, or change data types.
All AOT elements are stored as granular UTF-8 XML delta files under PackagesLocalDirectory, ensuring seamless version control branching, merging, and pull request audits.
The Best Practice (BP) framework integrates into element designers and compiler pipelines, enforcing standards on labels, table groups, primary index assignments, and relational integrity.
Last updated: September 2026
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
- Feature Classic View Model View
- Top-Level Organization AOT element types (Data Model, UI, Classes) Installed Packages and Models
- Search Scope Entire AOT across all models by default Can expand specific model folders or search globally
Visual Clutter High (tens of thousands of standard objects) Low (developers focus only on their active custom model)
- Model Visibility Shown in brackets beside element name Top-level parent node defines the model boundary
- Best For Discovering base objects to extend Developing and auditing elements within a custom model
- 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
- Filter Token Description Example Query
- type:<element_type> Filters by element type (table, class, form, edt, enum, query) type:table
- name:<pattern> Filters by element name; supports * wildcard name:Cust*
- model:<model_name> Restricts results to a specific model model:ApplicationSuite
- package:<package_name> Restricts results to a specific package package:ApplicationPlatform
- modified:<time_range> Filters by recent modifications modified:today , modified:recent
- 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:
Locate the base element in Application Explorer (e.g., CustTable in ApplicationSuite ).
Right-click the element and select Create extension (or Create extension in new project ).
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
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.
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
BP Rule Category Description & Requirement Consequence of Failure
Labels & Localization Hardcoded strings in Label or HelpText properties are forbidden. Every user-facing string must reference a label file (e.g., @ContosoCore:CustTitle ). BP Warning: "Label ... not found or text is hardcoded."
Table Group Property Every base table must specify an appropriate TableGroup ( Main , Group , WorksheetHeader , WorksheetLine , Transaction , Parameter ). BP Warning: Incorrect caching, archive, and data management behavior.
Primary & Cluster Indexes Tables must specify valid PrimaryIndex and ClusterIndex properties. Tables with surrogate keys must link them properly. BP Warning: Suboptimal query performance and record identity lookup issues.
Relation Cardinalities All table relations must have explicit Cardinality , RelatedTableCardinality , and RelationshipType properties configured. BP Error/Warning: Fails relational data integrity checks and DMF mapping.
Prefix Naming Custom fields on standard table extensions should use an organization prefix (e.g., Contoso_ ) to prevent naming collisions with future Microsoft fields. Risk of schema collision during One Version upgrades.
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.