In Dynamics 365 CRM, both file attachments and inline images are stored under the same entity: ActivityMimeAttachment. When emails are sent or received through Exchange and synced to Dynamics, all these files appear in the Attachment section of the email form.

Inline images (such as logos or signature graphics) are often included in emails for branding or formatting purposes. However, displaying these inline images in the attachment grid creates unnecessary clutter and can confuse users who expect to see only actual file attachments

.

Proposed improvement

A filter mechanism to exclude inline images from the attachment grid. This would help user easy to manage attachments in CRM

Benefits

• Enhances user experience by presenting a cleaner and more relevant attachment list.
• Reduces confusion and improves productivity when reviewing email attachments.

Description:

Internationally, the Japanese Yen is used without decimal points because its smallest monetary unit is the “Yen,” and there are no smaller circulating sub-units. All transaction amounts are expressed as whole Yen. Customer company adheres to this standard, so forcing a precision of two decimal places disrupts business operations and compliance with global norms.

Currently, Dynamics 365 allows configuring currency precision per currency but does not fully address scenarios like Yen where zero-decimal precision is required. This gap creates operational challenges and confusion for customers.

Request:

We strongly believe this is a functional limitation and request support for multi-decimal precision for currencies like Japanese Yen.

Benefits:

• Ensures compliance with international financial standards.
• Prevents operational disruptions for businesses using Yen.
• Improves user experience and trust in Dynamics 365’s multi-currency capabilities.

Description

Currently, bullet points in Dynamics 365 email templates are restricted to black. The customer’s brand guidelines require specific colors (e.g., blue). This limitation impacts brand identity and consistency across communications, especially since other Microsoft products like Word and Outlook allow seamless formatting using native components.

The customer relies on maintaining brand integrity, and restricting bullet points to black removes a key visual element. With over 80 active users and new users joining regularly, this limitation creates inefficiencies and forces IT teams to implement workarounds instead of optimizing the platform and rolling out new features.

Business Impact

• Brand Integrity: Consistent visual identity across customer-facing communications
• Operational Efficiency: Reduces time spent on manual workarounds and support
• User Experience: Aligns Dynamics 365 with standard functionality in other Microsoft products

Proposed Enhancement

Improve bullet points in email templates to adopt brand colors using native platform components (not HTML), ensuring compatibility across email clients and adherence to guardrails. This is not just a design preference—it affects brand consistency and operational efficiency. Implementing this enhancement will improve productivity and strengthen the platform’s value proposition.

Description

Currently, bullet points in Dynamics 365 Marketing email templates are restricted to black. The customer’s brand guidelines require specific colors (e.g., blue). This limitation impacts brand identity and consistency across communications, especially since other Microsoft products like Word and Outlook allow seamless formatting using native components.

The customer relies on maintaining brand integrity, and restricting bullet points to black removes a key visual element. With over 80 active users and new users joining regularly, this limitation creates inefficiencies and forces IT teams to implement workarounds instead of optimizing the platform and rolling out new features.

Business Impact

• Brand Integrity: Consistent visual identity across customer-facing communications
• Operational Efficiency: Reduces time spent on manual workarounds and support
• User Experience: Aligns Dynamics 365 Marketing with standard functionality in other Microsoft products

Proposed Enhancement

Improve the feature by allowing bullet points in Marketing email templates to adopt brand colors using native platform components (not HTML), ensuring compatibility across email clients and adherence to guardrails. This is not just a design preference—it affects brand consistency and operational efficiency. Implementing this enhancement will improve productivity and strengthen the platform’s value proposition.

Description

Customers using Microsoft Dynamics 365 and Microsoft Outlook often require seamless synchronization of Contacts between the two platforms while maintaining Dynamics 365 as the system of record (master contact database).

Currently, Server‑Side Synchronization between Outlook and Dynamics 365 relies on category‑based tracking and does not support:

• Automatic matching of Outlook Contacts with existing Dynamics 365 Contacts
• Ongoing bidirectional synchronization using Dynamics 365 as the authoritative source
• Native prevention of duplicate Contact records across Outlook and Dynamics
• Centralized identity matching based on Dynamics Contact data

As confirmed by Microsoft Support, synchronization logic today does not support automatic matching of Contact records between Outlook and Dynamics 365 during synchronization, and implementing this capability would require platform‑level enhancement.

This limitation creates challenges for organizations attempting to:

• Maintain a single unified Contact database in Dynamics 365 for Outlook contact loist.
• Ensure Outlook users interact with accurate and up‑to‑date Contact information from Dynamic
• Avoid manual tracking or duplicate Contact creation for Outlook

Customers want to leverage Dynamics 365 as the master Contact repository while allowing Outlook to reflect synchronized Contact data automatically, without relying on manual tracking or categorization.

Business Impact

The lack of automatic Contact matching and synchronization between Outlook and Dynamics 365 introduces several operational challenges:

• Contact duplication between Outlook and Dynamics environments
• Increased administrative overhead to manually track or sync Contacts
• Inconsistent customer data across sales, marketing, and service teams
• Reduced user adoption of Dynamics 365 when Outlook becomes the preferred Contact store
• Risk of outdated or conflicting Contact information across platforms
• Some users currently have more than 1000 contacts were mismatch.

Organizations attempting to centralize customer data within Dataverse are unable to ensure Outlook users operate from the same validated Contact dataset.

This impacts:

• Data governance initiatives
• Customer engagement accuracy
• Reporting reliability
• Sales productivity
• Enterprise adoption of Dynamics 365 as a single source of truth

For many customers transitioning from Outlook‑centric workflows, this represents a blocker to fully adopting Dynamics 365 Contact management capabilities.

Proposed Approach / Enhancement Request

Introduce a native synchronization option within Server‑Side Synchronization to allow:

1. Dynamics‑First Contact Authority Mode

Enable administrators to configure Dynamics 365 Contacts as the authoritative source for Contact data synchronized to Outlook.

2. Automatic Matching Logic

Provide built‑in matching rules to associate Outlook Contacts with existing Dynamics 365 Contacts using configurable attributes such as:

• Email Address
• Full Name
• Company Name
• External ID (optional custom field)

3. Duplicate Prevention

Allow synchronization to:

• Match to existing Dynamics Contact when criteria are met
• Prevent creation of duplicate Contact records in either system
• Update Outlook Contact records based on matched Dynamics Contact data

4. Ongoing Synchronization

Ensure matched Contacts remain synchronized for updates made in Dynamics 365, supporting:

• Contact detail updates
• Email or phone number changes
• Company or role updates

Problem Statement

When emails that are received in Outlook and synchronized back into Dynamics 365 / Power Apps are downloaded as .eml files and then re‑imported into Outlook, the email date appears incorrect.

This occurs because the Date Sent (senton) field on the Email entity is not populated for emails synchronized from an external mailbox. As a result, Outlook applies a default or fallback date value when importing the .eml file, leading to confusion and incorrect email timelines.

Business Impact

• Customers downloading emails for audit, compliance, or record‑keeping purposes see incorrect sent dates.
• Imported emails appear out of chronological order in Outlook.
• Manual intervention is required, which is not scalable and increases operational overhead.
• Impacts trust in exported email data from Dynamics 365 / Power Apps.

Scenario

1. An email is received in Outlook and synchronized into Dynamics 365 (Email entity).
2. The email record is created in Dynamics 365 without the Date Sent (senton) field populated.
3. The user downloads the email from Dynamics 365 as a .eml file.
4. The .eml file is imported back into Outlook.
5. Outlook displays an incorrect sent date.

Actual Behavior

• The Date Sent (senton) field is null for received/synchronized emails.
• When exporting the email, Outlook cannot correctly interpret the sent date.
• Outlook applies a default or incorrect date value.
• Users must manually edit the .eml file to correct the date.

Expected Behavior

• Emails synchronized from Outlook into Dynamics 365 should have the Date Sent (senton) field populated correctly.
• Downloaded .eml files should preserve the original sent date when imported back into Outlook.
• No manual modification should be required to maintain data integrity.

Validation / Findings

• Editing the date directly inside the .eml file confirms that Outlook correctly displays the date once a valid value is present.
• Emails sent directly from Dynamics 365 populate the Date Sent field correctly and do not exhibit this issue.
• The issue only affects emails synchronized from external mailboxes (received emails).
• The Date Sent (senton) column is a managed field and cannot be modified by customers.

Current Workaround

Since the Date Sent field is managed and cannot be edited in Dynamics 365:

1. Download the email from Dynamics 365.
2. Open the .eml file using Notepad.
3. Manually update the date value.
4. Import the email back into Outlook.

This workaround is manual and not suitable for high‑volume or compliance‑driven scenarios.

Suggested Improvement

• Populate the Date Sent (senton) field for emails synchronized from Outlook using available message metadata.
• Alternatively, ensure the exported .eml file includes a valid sent date derived from received email headers.
• Provide consistent behavior between sent emails and received/synchronized emails.

Summary

All‑day appointments in Dynamics 365 can display an incorrect date (typically one day earlier) when created around Daylight Saving Time (DST) transitions for certain time zones. This causes confusion for users and reduces trust in scheduling data, even though the underlying Dataverse data is stored correctly.

Problem Description

When users in DST‑affected time zones (for example, Sydney and Hobart – GMT+10 / GMT+11) create All‑Day Appointments, the appointment:

• Is stored correctly in Dataverse
• But is displayed as one day earlier in the model‑driven app form after DST ends

This behavior consistently occurs after DST rollover dates and can be reproduced in clean environments without customization.

From a user perspective:

• The appointment appears incorrect
• Users assume data corruption or system bugs
• Support cases are raised even though data integrity is intact

Expected Behavior

For All‑Day Appointments:

• The date shown in the UI should remain consistent with the user‑selected date
• DST or UTC conversion should not shift the calendar day
• The UI should treat all‑day events as date‑only, not date‑time during rendering

Actual Behavior

• All‑day appointments display one day earlier in the UI after DST changes
• This impacts multiple users in the same region
• Occurs without any customer customization

Affected Scenarios

• Time zones observing DST (e.g., AU Eastern)
• All‑day appointments only
• Model‑driven app forms
• Both newly created and viewed records after DST transition

Suggested Improvements

One or more of the following improvements would significantly reduce customer impact:

1. DST‑aware rendering logic for all‑day appointments in model‑driven forms
2. Treat all‑day appointments as true date‑only values at the UI layer
3. Provide a platform option or flag to disable DST conversion for all‑day events
4. Improve documentation or warnings if this behavior is by design

Customer Impact

• Impacts user trust in calendar and scheduling features
• Creates confusion and calendar inconsistencies

Business Justification

Fixing or improving this behavior would:

• Reduce support incidents related to DST
• Improve user confidence in Dynamics 365 scheduling
• Align UI behavior with user expectations for all‑day events
• Prevent repeated escalations each DST cycle

Summary

As the Modern “New Look” for model-driven apps becomes mandatory in the 2026 Release Wave 1, customers are experiencing email template rendering and formatting differences that directly impact customer-facing communications.

Organizations need a supported transition safeguard—such as a compatibility option, controlled deferral, or guaranteed WYSIWYG rendering—to protect production email quality during mandatory rollouts.

Problem Statement

Our organization is experiencing formatting and rendering issues with email templates when using the CRM New Look in Dynamics 365 Sales. The same email templates display correctly in the classic experience but show visual inconsistencies when composed or sent using the New Look, affecting fonts, layouts, borders, and overall presentation.

At the same time, Microsoft has announced that with the 2026 Release Wave 1, the New Look will be mandatory and cannot be switched off. For Australia-based production environments, this rollout is scheduled within a fixed deployment window in April 2026, leaving limited time for remediation and validation.

Because email templates are business-critical and customer-facing, any unintended formatting changes introduce operational risk, reputational impact, and user resistance to adoption.

Business Impact

• Customer communication risk:
• Outgoing customer emails may appear unprofessional or inconsistent, impacting trust and brand perception.
• Operational disruption:
• Administrators and support teams must urgently re-test and update templates close to deployment weekends, increasing production risk.
• Reduced adoption confidence:
• Mandatory UI changes that negatively affect core business outputs (email) create resistance to the modern experience.

Current Behavior

• Email templates render differently when used under the New Look compared to the classic experience.
• Formatting issues only surface during email composition or after sending, not always during template editing.
• The New Look is enforced as part of a mandatory platform update and cannot be opted out of.
• Customers cannot reliably prevent the New Look from being enabled in production environments, even when business impact is identified.

Expected / Desired Behavior

Organizations should be able to transition to the New Look without risking customer-facing email quality. Specifically:

• Email templates should render consistently (true WYSIWYG) across:
• Template editor
• Email compose
• Delivered email to recipients

OR

• Admins should have access to a supported compatibility option that preserves classic email rendering while templates are updated.

OR

• Admins should have a short, supported deferral mechanism for production environments when business-critical regressions are identified.

Feature Request

Option 1 — Classic Email Rendering Compatibility Mode (Recommended)

Introduce an environment- or app-level setting such as:

“Use classic rendering engine for email templates and outgoing emails”

This would allow organizations to maintain stable outbound email formatting while transitioning templates to the New Look.

Option 2 — Controlled Transition / Deferral for Production

Provide a time-bound, supported admin option to delay enforcement of the New Look for production environments where customer-facing impacts are identified, especially during fixed regional rollout windows.

Option 3 — Guaranteed Rendering for Email Templates

Ensure the New Look normalizes HTML/CSS output so that what users see while composing emails exactly matches what recipients receive, without editor-only artifacts or layout drift.

Summary

As the Modern “New Look” for model-driven apps becomes mandatory in the 2026 Release Wave 1, customers are experiencing email template rendering and formatting differences that directly impact customer-facing communications.

Organizations need a supported transition safeguard—such as a compatibility option, controlled deferral, or guaranteed WYSIWYG rendering—to protect production email quality during mandatory rollouts.

Problem Statement

Our organization is experiencing formatting and rendering issues with email templates when using the CRM New Look in Dynamics 365 Sales. The same email templates display correctly in the classic experience but show visual inconsistencies when composed or sent using the New Look, affecting fonts, layouts, borders, and overall presentation.

At the same time, Microsoft has announced that with the 2026 Release Wave 1, the New Look will be mandatory and cannot be switched off. For Australia-based production environments, this rollout is scheduled within a fixed deployment window in April 2026, leaving limited time for remediation and validation.

Because email templates are business-critical and customer-facing, any unintended formatting changes introduce operational risk, reputational impact, and user resistance to adoption.

Business Impact

• Customer communication risk:
• Outgoing customer emails may appear unprofessional or inconsistent, impacting trust and brand perception.
• Operational disruption:
• Administrators and support teams must urgently re-test and update templates close to deployment weekends, increasing production risk.
• Reduced adoption confidence:
• Mandatory UI changes that negatively affect core business outputs (email) create resistance to the modern experience.

Current Behavior

• Email templates render differently when used under the New Look compared to the classic experience.
• Formatting issues only surface during email composition or after sending, not always during template editing.
• The New Look is enforced as part of a mandatory platform update and cannot be opted out of.
• Customers cannot reliably prevent the New Look from being enabled in production environments, even when business impact is identified.

Expected / Desired Behavior

Organizations should be able to transition to the New Look without risking customer-facing email quality. Specifically:

• Email templates should render consistently (true WYSIWYG) across:
• Template editor
• Email compose
• Delivered email to recipients
• Admins should have access to a supported compatibility option that preserves classic email rendering while templates are updated.
• Admins should have a short, supported deferral mechanism for production environments when business-critical regressions are identified.

Feature Request

— Classic Email Rendering Compatibility Mode (Recommended)

Introduce an environment- or app-level setting such as:

“Use classic rendering engine for email templates and outgoing emails”

This would allow organizations to maintain stable outbound email formatting while transitioning templates to the New Look.

— Controlled Transition / Deferral for Production

Provide a time-bound, supported admin option to delay enforcement of the New Look for production environments where customer-facing impacts are identified, especially during fixed regional rollout windows.

— Guaranteed Rendering for Email Templates

Ensure the New Look normalizes HTML/CSS output so that what users see while composing emails exactly matches what recipients receive, without editor-only artifacts or layout drift.

Summary

As the Modern “New Look” for model-driven apps becomes mandatory in the 2026 Release Wave 1, customers are experiencing email template rendering and formatting differences that directly impact customer-facing communications.

Organizations need a supported transition safeguard—such as a compatibility option, controlled deferral, or guaranteed email rendering—to protect production email quality during mandatory rollouts.

Problem Statement

Our organization is experiencing formatting and rendering issues with email templates when using the CRM New Look in Dynamics 365 Sales. The same email templates display correctly in the classic experience but show visual inconsistencies when composed or sent using the New Look, affecting fonts, layouts, borders, and overall presentation.

At the same time, Microsoft has announced that with the 2026 Release Wave 1, the New Look will be mandatory and cannot be switched off. For Australia-based production environments, this rollout is scheduled within a fixed deployment window in April 2026, leaving limited time for remediation and validation.

Because email templates are business-critical and customer-facing, any unintended formatting changes introduce operational risk, reputational impact, and user resistance to adoption.

Business Impact

• Customer communication risk:
• Outgoing customer emails may appear unprofessional or inconsistent, impacting trust and brand perception.
• Operational disruption:
• Administrators and support teams must urgently re-test and update templates close to deployment weekends, increasing production risk.
• Reduced adoption confidence:
• Mandatory UI changes that negatively affect core business outputs (email) create resistance to the modern experience.

Current Behavior

• Email templates render differently when used under the New Look compared to the classic experience.
• Formatting issues only surface during email composition or after sending, not always during template editing.
• The New Look is enforced as part of a mandatory platform update and cannot be opted out of.
• Customers cannot reliably prevent the New Look from being enabled in production environments, even when business impact is identified.

Expected / Desired Behavior

Organizations should be able to transition to the New Look without risking customer-facing email quality. Specifically:

• Email templates should render consistently (true WYSIWYG) across:
• Template editor
• Email compose
• Delivered email to recipients
• Admins should have access to a supported compatibility option that preserves classic email rendering while templates are updated.
• Admins should have a short, supported deferral mechanism for production environments when business-critical regressions are identified.

Feature Request

— Classic Email Rendering Compatibility Mode (Recommended)

Introduce an environment- or app-level setting such as:

“Use classic rendering engine for email templates and outgoing emails”

This would allow organizations to maintain stable outbound email formatting while transitioning templates to the New Look.

— Controlled Transition / Deferral for Production

Provide a time-bound, supported admin option to delay enforcement of the New Look for production environments where customer-facing impacts are identified, especially during fixed regional rollout windows.

— Guaranteed Rendering for Email Templates

Ensure the New Look normalizes HTML/CSS output so that what users see while composing emails exactly matches what recipients receive, without editor-only artifacts or layout drift.