A new admin opens the form designer for the first time, drops six fields onto the form, and ships it. Six weeks later the form has 47 fields, three sub-grids, and four tabs that nobody clicks. The Unified Interface gives you the tools to build clean UX. It also gives you the tools to build a wall of fields, and the second pattern is the path of least resistance.
Forms
Main forms, quick view, quick create, card forms. Use tabs, sections, and related records panels. Form Editor is WYSIWYG — keep it maintainable, not aesthetic. The discipline is to ask, on each new field request, whether the field belongs on the main form or on a related record visible through a sub-grid.
On main form:
- Fields edited every time the user opens the record
- Fields that drive form-level logic (status, type, owner)
- Fields that summarize the record at a glance
On a related entity:
- One-to-many child data
- Optional or rarely-used metadata
- History and audit trails
Cap main form fields at 25. Above that, scroll fatigue erodes data quality.
Views
Default views for lists. Public views for everyone. User-created personal views for the individual. Quick Find for search-as-you-type. The default Active view is the one users see most often; tune it like a product, not a config setting.
Active Accounts default view:
- Account Name
- Industry
- Owner
- Modified On
- Annual Revenue
- Primary Contact
Six columns is usually enough. Wider views slow the grid and the columns past column eight rarely get used.
Charts
System charts live on the table; personal charts on the user. Drill-in to chart segments opens filtered views. Limited but sufficient for dashboards. Use native charts for the questions that fit one entity and one aggregate; reserve Power BI for the cross-entity executive views.
<fetch aggregate="true">
<entity name="opportunity">
<attribute name="estimatedvalue" aggregate="sum" alias="value" />
<attribute name="stepname" groupby="true" alias="stage" />
<filter>
<condition attribute="statecode" operator="eq" value="0" />
</filter>
</entity>
</fetch>
Native charts respect the current view filter, which makes them feel responsive in a way embedded reports cannot match.
Dashboards
System dashboards show aggregated views. Single-user dashboards for personal focus. Embed Power BI for advanced analytics. The most valuable dashboard is usually the one a sales rep opens at 8am to plan the day, not the executive scorecard. Build the rep dashboard first; the exec dashboard is the second priority, not the first.
Site Map
Drives navigation. Areas to Groups to Subareas. Role-based filtering hides unused nodes. Deep menus are user pain — keep at most two levels visible. The role-based filtering is the most underused feature; users see every entity by default and assume they need them all.
Site map for Sales role:
Sales
My Work
Dashboards
Activities
Customers
Accounts
Contacts
Sales
Leads
Opportunities
Quotes
Hide everything else for the Sales role. The user can still global-search a record from a hidden area; they just do not see it in the nav.
App Modules
App modules let you ship a slimmer experience for each persona. A field service technician does not need the Sales hub clutter. Build a Field Service app module with only the entities, dashboards, and views the technician uses.
Field Tech App:
Entities: Work Order, Asset, Customer, Bookable Resource
Dashboards: My Schedule
Forms: Work Order Mobile
App modules reduce the cognitive load that drives the wall-of-fields complaint.
Theme and Branding
Themes change the header color, logo, and accent. They do not change form layout. Use a theme to make the production environment visually distinct from sandbox; users who see a red header in production know not to test there.
What to do this week
Open the most-used form in your environment, count the fields, and move every field that is not edited weekly to a sub-grid or a related record. Configure role-based site map filtering for your top three personas and ship a slim app module for the persona that opens Dynamics first thing in the morning.