Forms, Menus, and UI Patterns

Forms are how users see your data

Every table, view, and entity you’ve built so far is invisible to users until you create a form. Forms are the AOT objects that render the browser-based UI in D365 Finance & Operations.

Form patterns

Form patterns are mandatory layout templates. When you create a form, you apply a pattern, and Visual Studio validates that your form structure matches the pattern’s requirements.

Major form patterns

Choose the pattern that matches your scenario — the platform validates compliance

Pattern	Use Case	Structure
Details Master	Viewing/editing a single record with full detail	Navigation list (left) + detail view (right) with header and tab-based FastTabs
Details Transaction	Header-line transactions (sales orders, purchase orders)	Header fields at top + line grid below with line details
Simple List	Flat list of records (setup tables, reference data)	Grid with inline editing, no separate detail view
Simple List and Details	List with a detail pane	Grid on left + detail fields on right/below
List Page	Browse and filter records before opening details	Full-width grid with filter pane, preview pane, FactBoxes
Workspace	Role-based dashboards with tiles, lists, and links	Tiles + tabbed lists + links + charts — configurable by user
Dialog	Modal input forms (confirmations, parameters)	Simple field layout with OK/Cancel buttons
Drop Dialog	Quick input that drops down from a button	Minimal fields, compact layout, no modal overlay
Lookup	Lookup popup from a field	Grid showing lookup results with search

Sub-patterns

Sub-patterns apply to sections within a form, not the whole form:

• Fields and Field Groups — standard field layout within a group
• Toolbar and List — action buttons above a grid
• Tabular Fields — multi-column field layout
• Filters and Toolbar — filter fields + action buttons above content
• Section Tiles — tile layout for workspace sections

💡 Exam tip: pattern compliance

Visual Studio shows a pattern indicator on each form node. Green = compliant, yellow = missing optional elements, red = required elements missing.

The exam may ask: “A developer creates a form but sees red pattern violations. What should they check?” Answer: the form’s control hierarchy doesn’t match the pattern’s required structure — missing an ActionPane, wrong group nesting, or controls in the wrong order.

Question

What form pattern would you use for a sales order form that shows a header and order lines?

Click or press Enter to reveal answer

Answer

Details Transaction. This pattern is designed for header-line documents — it shows header fields at the top, a line grid below, and line details beneath or beside the grid. Examples: SalesTable form, PurchTable form.

Click to flip back

Form data sources

A form’s data sources connect it to tables, views, or queries.

Key data source properties

Property	Purpose	Common Values
Table	Which table/view to bind	Any AOT table or view
Index	Which index to use for initial sort	Typically the primary index
AllowEdit	Whether users can edit records	Yes / No
AllowCreate	Whether the New button works	Yes / No
AllowDelete	Whether the Delete button works	Yes / No
InsertIfEmpty	Auto-create a blank record if the data source is empty	Yes (for parameter forms) / No
JoinSource	Parent data source for master-detail	References another data source on the same form
LinkType	How child data source relates to parent	Active (filter by selected parent), Delayed, InnerJoin, OuterJoin, ExistJoin

Linking data sources (master-detail)

// Form: AxionInspectionDetails
// Data Sources:
//   AxionInspectionTable (primary — the header)
//     JoinSource: (none — root data source)
//   AxionInspectionLine (child — the lines)
//     JoinSource: AxionInspectionTable
//     LinkType: Active
//     (relation: InspectionId == InspectionId — auto-resolved from table relation)

When the user selects an inspection header, the lines data source automatically filters to show only that inspection’s lines. This is Active linking — the child refreshes whenever the parent selection changes.

💡 Scenario: Sophie's form data source confusion

Sophie Chen at Ferris Industries creates a form with two data sources — Products and ProductVariants. She sets the JoinSource but forgets to set the LinkType. The form shows ALL variants regardless of which product is selected.

Mentor Carl explains: “Without LinkType = Active, the child data source doesn’t know to filter when the parent selection changes. Set LinkType to Active for master-detail relationships where the child should refresh on parent selection.”

Form controls

Controls are the visual elements on a form — buttons, fields, grids, tabs.

Common control types

Control	Purpose	Example
StringEdit	Text input field	Customer name, description
IntEdit / RealEdit	Number input	Quantity, amount
DateEdit	Date picker	Order date, due date
ComboBox	Dropdown (bound to enum)	Status, type
CheckBox	Boolean toggle	Active, approved
Grid	Tabular data display	Order lines, item list
ActionPane	Ribbon-style toolbar	New, Delete, Post, Print buttons
FastTab (Tab)	Collapsible sections	General, Financial, Delivery tabs
FormPart	Embedded FactBox or sub-form	Related records, quick info
MenuButton	Dropdown menu on action pane	Functions menu, Inquiries menu

Binding controls to data

Controls bind to data source fields automatically when you drag a field from the data source onto the design. The control type is determined by the field’s EDT:

• str → StringEdit
• int → IntEdit
• TransDate → DateEdit
• Enum → ComboBox

Question

What determines the default control type when you drag a field onto a form design?

Click or press Enter to reveal answer

Answer

The field's Extended Data Type (EDT) or base type. A string EDT creates a StringEdit, a date EDT creates a DateEdit, an enum creates a ComboBox. You can override the control type, but the default comes from the EDT.

Click to flip back

Menu items: the navigation system

Users don’t open forms directly — they click menu items. A menu item is a pointer that opens a form, runs a report, or triggers an action.

Three types of menu items

Display = open a form, Output = run a report, Action = execute a process

Type	Icon	What It Opens	Examples
Display	📋	A form for viewing/editing data	All Customers, Sales Orders, Inspection List
Output	🖨️	A report (SSRS) or output	Invoice print, Packing slip report
Action	⚡	Runs a class (batch job, process)	Post invoice, Recalculate prices, Close period

Menu item properties

Property	Purpose
Object	The form, report, or class this menu item opens
ObjectType	Form, Class, or SSRSReport
Label	What the user sees (should use a label reference)
NormalImage	Icon displayed in menus and tiles
SecurityKey	Security privilege required to access this menu item
RunOn	Where the code executes — Client, Server, or CalledFrom

💡 Exam tip: menu item security

Menu items are the entry points for the D365 security model. Privileges grant access to menu items, roles contain privileges.

Exam pattern: “Users in the Quality Inspector role cannot see the Inspection List form.” The fix is to check that the role includes a privilege that grants access to the AxionInspectionList Display menu item. Security is based on menu items, not forms.

Menus

Menus organise menu items into the navigation structure:

• Main Menu → appears in the module navigation
• Submenus → group related items
• Menu Item References → pointers to Display/Output/Action menu items

// Menu: AxionQualityModule
//   Submenu: Inspections
//     Display Menu Item: AxionInspectionList
//     Display Menu Item: AxionInspectionDetails
//   Submenu: Setup
//     Display Menu Item: AxionInspectionTypes
//     Display Menu Item: AxionInspectionParameters
//   Submenu: Reports
//     Output Menu Item: AxionInspectionReport
//   Submenu: Periodic
//     Action Menu Item: AxionCloseInspectionPeriod

Question

What are the three types of menu items in D365 F&O?

Click or press Enter to reveal answer

Answer

1. Display — opens a form for viewing/editing data. 2. Output — runs a report (SSRS). 3. Action — executes a class (batch job, process). Menu items are also the entry points for the security model — privileges are granted on menu items.

Click to flip back

Labels: the localisation system

Labels are the way D365 F&O handles multi-language text. Instead of hardcoding strings like “Customer” or “Save,” you create a label and reference it everywhere.

Label syntax

// Label file: @AxionLabels
// Label ID: @AxionLabels:InspectionId
// English (en-us): "Inspection ID"
// German (de): "Prüfungs-ID"
// French (fr): "ID d'inspection"

// Usage in AOT:
// EDT Label property: @AxionLabels:InspectionId
// Menu Item Label: @AxionLabels:InspectionList

// Usage in X++ code:
info("@AxionLabels:InspectionId");
// At runtime, displays in the user's language

Label best practices

Do	Don’t
✅ Create a label file per model	❌ Reuse Microsoft’s @SYS labels for custom text
✅ Use descriptive label IDs	❌ Use label IDs like @AxionLabels:Label001
✅ One label per unique concept	❌ Create duplicate labels for the same text
✅ Use %1, %2 for dynamic values	❌ Concatenate strings with labels
✅ Translate all labels before go-live	❌ Leave labels in developer language only

The @SYS prefix

Microsoft’s standard labels use the @SYS prefix — for example, @SYS14352 means “Description” in every language. You can reference @SYS labels in your objects, but never modify them.

💡 Exam tip: labels are exam-relevant

The MB-500 exam explicitly tests label knowledge:

• Every user-visible string must use a label — never hardcode text
• Labels are stored in .label files per language in your model
• @SYS labels are Microsoft’s — reference them but don’t modify
• Label search: In Visual Studio, use the Label Editor to find existing labels before creating new ones
• String parameters: Use strFmt("@AxionLabels:InspectionCount", numInspections) with %1 placeholders — never concatenate translated strings

If a question asks “how to display a form title in the user’s language,” the answer always involves labels.

Question

Why should you never concatenate strings with labels for localisation?

Click or press Enter to reveal answer

Answer

Because word order differs between languages. 'Inspection count: 5' in English might be '5 inspections' in Japanese. Using strFmt('@Label:InspCount', 5) with a '%1' placeholder lets each translation put the number in the correct position for that language.

Click to flip back

Putting it together: form development checklist

When Vik builds a new form at Axion, he follows this flow:

1. Choose the pattern — Details Master, Simple List, etc.
2. Add data sources — primary table, set JoinSource and LinkType for children
3. Apply the pattern — right-click form Design → Apply Pattern
4. Build the layout — add ActionPane, groups, tabs per pattern requirements
5. Drag fields — from data source, let EDT determine control type
6. Create menu items — Display for the form, Action for any process buttons
7. Add to a menu — so users can navigate to the form
8. Label everything — use existing @SYS or create @Axion labels
9. Set security — configure privileges on the menu items
10. Test pattern compliance — green indicator = ready

💡 Scenario: Elena's workspace form

Elena Vasquez at PacificForge Manufacturing builds a Quality Manager workspace. CTO Gregor wants: a tile showing overdue inspections, a list of today’s inspections, and quick links to setup forms.

Elena applies the Workspace pattern:

• Section Tiles: Overdue Inspection Count (tile with a query counting overdue records)
• Section Tabbed List: Today’s Inspections (form part showing a filtered list)
• Section Related Links: Setup links (menu item references to parameter and setup forms)

The workspace pattern handles responsive layout automatically — tiles wrap on smaller screens, lists stack vertically.

Knowledge Check

Vik needs to create a form for viewing and editing individual inspection records. The form should show a list of inspections on the left and full details (with multiple FastTabs) on the right. Which form pattern should he apply?

ASimple ListBList PageCDetails MasterDWorkspace

Check Answer

Knowledge Check

Sophie creates a form with two data sources — InspectionHeader and InspectionLines. She sets InspectionLines.JoinSource to InspectionHeader but when she selects different headers, the lines grid always shows all lines from all inspections. What did she miss?

AShe needs to set the LinkType property on the InspectionLines data source to ActiveBShe needs to add a WHERE clause in the form's init() methodCShe needs to create a view that joins the two tablesDShe needs to set AllowEdit = No on the InspectionLines data source

Check Answer

Knowledge Check

Nikhil hardcodes the string 'Inspection saved successfully' in an info() call in his X++ code. A German-speaking user reports that the message still appears in English. What should Nikhil have done instead?

ASet the form's Language property to 'All'BCreate a label in a label file and reference it: info('@AxionLabels:InspectionSaved')CUse the Global::strTranslate() method to translate at runtimeDAdd a German resource file (.resx) to the project

Check Answer

Knowledge Check

A security administrator reports that users in the 'Quality Inspector' role can't access the Inspection List form. The form exists and works for admins. Where should the developer check first?

AThe form's Visible propertyBThe form's data source AllowEdit propertyCWhether the role includes a privilege that grants access to the Display menu item for the formDWhether the form has a valid pattern applied

Check Answer

---

Next up: Classes, Events, and Extensions — create X++ classes, extend standard behaviour with event handlers, and use attributes for metadata.