Forem: Nikhil Sarpatwari

Fixing Outlook Sync Issues in Dynamics 365 CE - Track and Set Regarding are currently disabled

Nikhil Sarpatwari — Tue, 30 Sep 2025 12:33:57 +0000

If you’re using the Dynamics 365 App for Outlook and see this warning message:

Track and Set Regarding are currently disabled, but you can continue to view and edit Dynamics 365 data. Please contact your admin to enable all features.

you’ve hit one of the most common sync issues in Dynamics 365 CE.

Why This Happens

This usually occurs when the user’s mailbox in Dynamics 365 isn’t fully approved or has lost its sync configuration. Without an approved and enabled mailbox, Dynamics can’t allow tracking or “set regarding” actions from Outlook.

Resolution

The quickest way to fix this is to re-approve and re-enable the mailbox:

In Dynamics 365 CE, navigate to: Advanced Settings → Email Configuration → Mailboxes
Locate and open the affected user’s mailbox record
Click Approve Email
Then select Test & Enable Mailbox

Within a few minutes, the warning should disappear, and the Track and Set Regarding buttons will start working again in Outlook.

Pro Tip

If this issue keeps recurring:

Verify the Email Server Profile is set up correctly
Make sure Server-Side Synchronization is configured and tested
Check that the user has the correct security role permissions for email

With just a couple of clicks, you can bring back full Outlook integration for your users and avoid the frustration of missing sync features.

When Out-of-the-Box Email-to-Case Isn’t Enough in Dynamics 365 CE

Nikhil Sarpatwari — Sun, 28 Sep 2025 05:11:53 +0000

The out-of-the-box (OOB) Email-to-Case feature in Dynamics 365 CE Customer Service works well for most organizations. It automatically converts incoming customer emails into cases, saving agents time and ensuring customer issues are tracked properly.

But real-world scenarios aren’t always that simple. Many implementations I’ve worked on needed custom processes because the OOB approach couldn’t handle all business requirements.

In this post, I’ll outline when you can’t rely on OOB Email-to-Case and how to design a custom email-to-case process.

When OOB Email-to-Case Falls Short

Here are some situations where you may hit limitations:

Multiple Mailboxes, One Case Process
- OOB ties conversion logic to a specific queue/mailbox.
- If you receive support emails from multiple addresses (e.g., support@, billing@, vip@) but want consistent rules, you’ll need custom handling.
Advanced Routing Rules
- OOB uses basic queue routing.
- If you need routing based on keywords, customer type, entitlements, or SLAs, you’ll quickly outgrow standard rules.
Case Creation Rules vs. Plugins/Flows
- Case Creation Rules are limited to conditions/actions available in the UI.
- If you need integration with external systems (e.g., ServiceNow, Jira, SAP), you’ll need a plugin or Power Automate flow.
Duplicate Detection & Merging
- OOB creates a new case for each email.
- If multiple emails belong to the same ongoing issue, you might want to append as activities instead of creating duplicates.
Attachments & Compliance
- Large attachments or secure handling requirements (masking, redaction, storage in SharePoint/Azure Blob) can’t be managed by the OOB feature.
VIP/High-Priority Customers
- Some customers’ emails need to bypass queues and go straight to Tier 2/3 support.
- OOB rules can’t handle this level of escalation logic.

Designing a Custom Email-to-Case Process

A flexible approach looks like this:

1. Mailbox Setup

Still configure server-side synchronization for your support mailboxes.
Emails land in Dynamics as activities.

2. Power Automate Flow or Plugin

Trigger: When an email is created (via Dataverse trigger or plugin on email entity).
Check: Does it meet case-creation conditions (subject, sender, queue)?
Logic:
- If yes → Create/Update case record.
- If case already exists → Track as activity against it.
- Apply routing rules (BU, Queue, Owner).
- Handle attachments securely.

3. Advanced Features

Duplicate detection: Check open cases by customer & subject before creating new ones.
External integration: Push key details to other systems.
Priority handling: Auto-assign high-value customers.

Example: Power Automate Flow

Here’s a simplified design:

Trigger: When an email activity is created in Dataverse.
Condition: Subject contains “Support” OR To = support@company.com.
Check: Query for open case with same contact & similar subject.
- If found → Add email to timeline.
- If not → Create new case record.
Route: Assign based on keywords or entitlement.
Attachments: Save to SharePoint & link to case.

Key Takeaways

OOB Email-to-Case works fine for small setups with simple queues.
If your business has multiple support lines, compliance rules, external integrations, or complex routing, you’ll need a custom solution.
A mix of server-side sync + Power Automate + plugins usually provides the right balance of automation and flexibility.

Dynamics 365 & Power Platform: What Developers Should Watch in 2025 Release Wave 2

Nikhil Sarpatwari — Sun, 28 Sep 2025 04:43:24 +0000

I’ve been digging through the 2025 Release Wave 2 plans and some preview articles, and I wanted to share what I found from a developer and maker perspective.

While most announcements highlight Copilot and AI, there are several changes that will directly affect developers — especially around solution management, extensibility, and integration patterns.

Here’s a summary of the Wave 2 features that stood out to me, and why they matter in real projects.

Why This Matters

Dynamics development is shifting as Copilot and agents become part of solution design.
ALM pipelines may need adjustments for new solution components.
Some older approaches, like DOM-based customizations, are at risk with UI updates.

This release is as relevant for developers as it is for business users.

Key Features to Note

1. Model Context Protocol (MCP) in Sales Copilot

Wave 2 brings MCP integration (the same protocol used by GitHub Copilot agents) into Dynamics Sales.

Impact: Developers can extend Copilot flows by packaging MCP “skills” as extensions. Security testing and permission handling will be essential.

2. Copilot Studio and Multi-Agent Support

Makers can now build multiple Copilot agents that integrate with Dataverse, Microsoft Graph, and Azure AI.

Impact: These agents will appear as new solution components, meaning ALM pipelines must handle export, import, and versioning.

3. Asynchronous Dual-Write

Dual-write now supports asynchronous processing between FinOps and Dataverse.

Impact: Integrations need to account for eventual consistency. Developers should test error handling, retries, and data reconciliation.

4. Natural Language ERP Queries

End users can query ERP data using natural language directly from Dynamics.

Impact: Developers must ensure that security roles are properly enforced, so sensitive data isn’t exposed through free-text queries.

5. UX and Navigation Refresh

Wave 2 introduces a more streamlined header and command bar redesign. Some buttons will move into overflow menus.

Impact: Ribbon customizations and JavaScript that rely on unsupported DOM selectors may break. It’s best to validate all custom buttons and switch to supported APIs.

6. Copilot Form Fill Assist and Smart Paste

Copilot can map data from files, images, or clipboard content into Dataverse fields.

Impact: Developers may need to customize mapping rules, add validation, or create plugins to enrich the data before saving.

Areas to Watch

How well solution upgrades handle Copilot agent components in ALM.
The reliability of asynchronous dual-write in production environments.
The effect of UI changes on ribbon customizations.
Licensing considerations for advanced Copilot features.

How to Prepare

Test pipelines with new solution components like agents.
Build and deploy a sample agent in Copilot Studio, then try exporting and importing via DevOps.
Simulate asynchronous integration delays between FinOps and Dataverse.
Review JavaScript customizations and remove unsupported DOM dependencies.
Work closely with makers — they’ll build more with Copilot Studio, and developers will need to provide governance.

Final Thoughts

Wave 2 is moving developers toward new responsibilities:

Less focus on form customizations.
More focus on governance, extensibility, and resilient integrations.

This is what I found while researching Wave 2.

Enabling Dynamics 365 Outlook App

Nikhil Sarpatwari — Fri, 12 Sep 2025 13:12:36 +0000

The Dynamics 365 App for Outlook brings CRM directly into Outlook, letting users track emails, appointments, and contacts without switching windows.

The process is now much simpler — but there are still a couple of mailbox steps to ensure everything works properly.

Prerequisites

User has a Dynamics 365 CE license.
Exchange Online mailbox (server-side sync).
A Dynamics 365 security role with the privilege “Dynamics 365 App for Outlook.”

Steps to Enable

1. Approve and Test the Mailbox

Go to Advanced Settings > Settings > Email Configuration > Mailboxes.
Open the user’s mailbox record.
Click Approve Email.
Then select Test & Enable Mailbox.
- The mailbox should show Success for incoming and outgoing emails.

2. Assign the Security Role

In Power Platform Admin Center (or Classic Settings), open the user record.
Add the role:
- Dynamics 365 App for Outlook User

3. User Access in Outlook

After a short wait, the app will appear automatically in:
- Outlook Desktop
- Outlook Web (OWA)

From there, users can:

Track emails and appointments.
Create new records from Outlook.
View Dynamics records inline.

Troubleshooting

If the app doesn’t appear:
- Double-check the mailbox status is Success.
- Ensure the security role is assigned.
- Wait 15–30 minutes, as rollout can take time.
Errors can be seen in the Mailbox Alerts section.

Final Thoughts

Enabling the Outlook App for Dynamics is now quicker than ever:

Approve + Test & Enable the mailbox.
Assign the security role.

That’s all it takes to boost productivity by bringing Dynamics right into Outlook!

Why Are Users Seeing Two Different “Edit Columns” and “Edit Filters” Buttons in Dynamics CE Views?

Nikhil Sarpatwari — Fri, 12 Sep 2025 12:42:38 +0000

If you’ve recently noticed that some users see two different versions of the Edit Columns and Edit Filters buttons in Dynamics 365 Customer Engagement views—one looking like the classic interface, and the other like the modern grid—you’re not alone.

I ran into this exact issue, and after some digging, the culprit turned out to be a feature setting in the Power Platform Admin Center.

The Root Cause: Natural Language Grid and View Search

In the Power Platform Admin Center, there’s a setting called “Natural language grid and view search” under Features. This toggle controls how the grid experience behaves for end users.

It has three possible options:

All users immediately → Everyone sees the modern grid experience.
No one → Everyone stays on the classic grid.
Users as the feature becomes available → A mix of classic and modern experiences, depending on the rollout progress.

That last option is where the confusion comes from. With “Users as the feature becomes available”, some users get the modern grid while others remain on the classic one. That’s why different people see different versions of the Edit Columns and Edit Filters buttons.

The Fix

To make the experience consistent across your organisation, you need to update the setting to either:

All users immediately (if you’re ready to fully adopt the modern grid), or
No one (if you want to stay on the classic grid for now).

This way, all users see the same interface and there’s no more back-and-forth confusion.

Final Thoughts

This is one of those small but impactful admin settings that can cause a lot of head-scratching for end users. If your team is reporting inconsistent UI in views, check the Natural language grid and view search setting first—it might just save you a lot of time troubleshooting.

Power Platform Admin Center – App Access Checker

Nikhil Sarpatwari — Tue, 09 Sep 2025 00:58:20 +0000

When troubleshooting why a user can’t access a model-driven app, the App Access Checker in the Power Platform Admin Center is your go-to tool.

What does it do?

The App Access Checker allows admins to simulate a user’s access to an app. Instead of trial and error, you can instantly see whether a user:

Has access to the app
Is missing security roles or privileges
Needs adjustments at the environment or app level

How to use it

Navigate to Power Platform Admin Center → Environments
Select your environment and go to Settings
Under Users + Permissions, choose Users -> choose App Access Checker
Pick the app, enter the user, and run the check
Review the access results

Why it’s useful

Saves time by validating access without impersonation
Helps identify whether the issue is role-based or app-level
Reduces user frustration by quickly pinpointing the problem

Reference: https://learn.microsoft.com/en-us/power-apps/maker/model-driven-apps/app-access-checker

Solution Layers in Power Automate Flows: Why Solution Upgrades Don’t Remove Active Layers

Nikhil Sarpatwari — Fri, 05 Sep 2025 07:32:10 +0000

If you’ve ever worked with Power Automate flows in a managed Production environment, you may have run into this situation:
someone makes a quick change directly in Production, and suddenly a new solution layer is sitting on top of everything.

That usually leads to the question:
“If I deploy a managed solution upgrade, will it overwrite that active layer and fix things?”

The short answer is no. Let me explain why.

How solution layers actually work

Every component in Dataverse (flows, forms, views, apps, and so on) has layers that stack on each other:

Managed layers come from imported managed solutions.

Unmanaged “Active” layer is created whenever someone edits directly in the environment.

The active layer always wins. That means whatever change was made in Production will stay in place, even after you bring in a new managed solution version.

[ Unmanaged Active Layer ] ← always on top if it exists
[ Managed Upgrade Layer ]
[ Managed Base Layer ]

Why a solution upgrade doesn’t fix it?

When you import a new solution with the upgrade option, or even choose “overwrite customizations,” it only applies to conflicts between managed layers.
The unmanaged active layer is untouched. Because it sits on top, it continues to override whatever you just deployed.

How to get rid of the active layer?

If you want your managed solution version to take effect again, you need to remove the unmanaged layer:

Open the flow from inside the solution.
Go to More → Details → Solution layers.
Select Remove unmanaged customizations.

Once you do this, the flow goes back to the managed version delivered by your solution.

Avoiding the problem in the future

Try not to edit components directly in Production. Make changes in Dev or Test and deploy them forward.

Limit maker permissions in Production so flows can’t be tweaked there.

Use CI/CD pipelines (Azure DevOps or similar) so deployments are consistent and auditable.

The takeaway

Deploying a managed solution upgrade will not clear out an unmanaged active layer. If you want your solution version to apply, you’ll need to reset the component back to its base managed layer.

Adding Dynamics 365 Users through Security Roles as Members

Nikhil Sarpatwari — Tue, 02 Sep 2025 05:11:37 +0000

In Dynamics 365 CE and Dataverse, security is managed through Security Roles. A straightforward way to give users access is by adding them as members of a role.

You can also do this directly in the Power Platform Admin Center, which is handy when you need to add multiple users to the same role at once.

How to add users as members of a security role

Open the Power Platform Admin Center.
Select your environment.
Go to Settings → Security Roles.
Choose the security role you want to update.
From the top ribbon, select Members.
Click Add People, search for the users, and confirm.

Once added, those users will inherit the permissions defined by that role.

Limitations to keep in mind

While this method is quick and easy, it does have some limitations:

Bulk updates are limited: you can only add a few users at a time.
Business Unit restrictions: a user must be in the same Business Unit as the role to be added.
No automation or logic: users must be added manually—there is no way to assign roles dynamically based on department or job title.
Harder to govern at scale: it’s more difficult to track and audit these assignments across large organizations.
Navigation challenges: the members screen is not always efficient when dealing with many users.

When this approach works well

Adding a small number of users during onboarding.
Assigning roles in test or development environments.
Making quick adjustments where automation is not needed.

Alternatives for larger or automated scenarios

Use Power Automate to assign roles during onboarding or other events.
Use PowerShell scripts to handle large, bulk assignments across environments.
Use XrmToolBox plugins (like User Roles Manager) for mass updates and better visibility.

Takeaway

Adding users to security roles as members through the Power Platform Admin Center is a simple option for smaller teams or one-off assignments. For larger organizations or long-term governance, automation and admin tools are a better fit.

Dynamics 365: Group By in Views – A Game Changer!

Nikhil Sarpatwari — Mon, 25 Aug 2025 02:06:33 +0000

If you spend a lot of time in Dynamics 365 views, this one’s for you.

Until recently, if you wanted to group records — say by year, month, or quarter — you either had to export everything to Excel or create a chart/dashboard.

It worked, but… honestly, it was a bit of a hassle.

Now there’s a much simpler way: Group By in views

What’s new?

When you’re looking at a view and click on a date column (like Modified On), you’ll notice a new Group By option.

You can now group your records instantly by:

Year
Quarter
Month
Week
Day
Fiscal period
Fiscal year

All without leaving the view you’re in.

Why this is awesome

Quick wins – Need to see how many cases were updated last month? Two clicks.
No more Excel shuffle – Stay inside Dynamics instead of exporting just to do grouping.
User friendly – Anyone can use it. No special setup, no advanced reporting knowledge.

Example in action

I was checking a list of accounts recently and just wanted to see when they were last modified. Instead of messing with filters or creating a chart, I grouped by Year.

Boom!! I instantly saw the breakdown — and it honestly felt like a mini built-in report right there in the view.

Note on Limits

Group By is super handy, but there’s one thing to watch out for:

Dynamics 365 caps grouping and aggregation at 50,000 records.

If your dataset is bigger than that, you’ll see this error:

“The maximum record limit of 50000 is exceeded. Reduce the number of aggregated or grouped records.”

How to enable "Group By"

Out of the box – You don’t need to explicitly enable it; it’s available in the modern grid experience (Unified Interface).

Ensure that:

You are using Dataverse tables (entities) in the modern UI (not the legacy web client).
The view you’re working on includes a date field (e.g., Created On, Modified On, Custom Date). → Group By works best with date/time fields.

Final thoughts

This is one of those small features that makes a big difference.

It’s not flashy, but it saves time and keeps you in the flow.

I know I’ll be using it a lot… especially for those quick “just show me the trend” moments.

Debugging in Dynamics 365 CE – Part 5: Security & Access Issues

Nikhil Sarpatwari — Sun, 24 Aug 2025 04:51:07 +0000

So far, we’ve tackled:

Part 1 – Debugging JavaScript
Part 2 – Debugging Plugins in DEV
Part 3 – Debugging in Sandbox & Production
Part 4 – Debugging Power Automate Flows & Integrations

Now let’s talk about one of the most frustrating but common pain points: security and access issues in Dynamics 365 CE.

Why Security Debugging Is Tricky

When a user says:

“I can’t see this record”

or

“The button is greyed out”

…it could be due to:

Security roles
Business units
Teams
Hierarchy settings
Field-level security
Or even a missing environment variable for an app control

Debugging Techniques

Security Role Checker

Use the Check Access button (on record ribbon) to see why a user can/can’t access.

It breaks down privileges (Read, Write, Append, AppendTo, etc.).
User Access via Teams & Business Units

Remember: a user’s effective access = roles assigned directly + roles via teams.

Always confirm the user is in the right business unit — roles are BU-scoped!
Field-Level Security

Sometimes the form loads but specific fields are hidden/locked.

Verify if field-level security profiles are blocking access.
Apps & Controls

With model-driven apps, sometimes the issue isn’t security — it’s App Designer restrictions or environment variables missing after deployment.
Audit & Logs

Use the Audit log to check if an action was attempted but blocked.

Pair this with plugin trace logs to see if it failed mid-execution.

Example: Using Check Access

On any record → click ... → Check Access → see a list of users/teams and their effective privileges.

This is a lifesaver when you’re stuck between “user swears they had access yesterday” and “nothing changed.”

Key Takeaways

Start with Check Access — it narrows the problem fast.
Always map roles + teams + business unit to understand effective permissions.
Don’t forget field-level security, app access, and environment variables.
Sometimes it’s not a bug — it’s just security doing its job.

📖 Earlier posts in the series:

Part 1 – Debugging JavaScript
Part 2 – Debugging Plugins in DEV
Part 3 – Debugging in Sandbox & Production
Part 4 – Debugging Power Automate Flows & Integrations

Debugging in Dynamics 365 CE – Part 4: Power Automate Flows & Integrations

Nikhil Sarpatwari — Sun, 24 Aug 2025 04:26:43 +0000

We’ve covered:

Part 1 – Debugging JavaScript
Part 2 – Debugging Plugins in DEV
Part 3 – Debugging in Sandbox & Production

Now it’s time to talk about Power Automate flows and integrations — an area where many of us spend countless hours scratching our heads.

The Challenge with Flows

Unlike plugins, you can’t attach a debugger to a flow. Instead, you need to rely on:

Run history (inputs/outputs at each step)
Error handling (Configure run after, Try/Catch patterns)
Connection references (yes, they break more often than we’d like!)
Environment variables for dynamic values

Debugging Techniques

1. Run History & Peek Code

Always start by checking Run history.
Use “Peek code” to inspect raw JSON inputs/outputs — it often reveals type mismatches, missing fields, or null values.

2. Scopes & Error Handling

Wrap actions in Scope containers.
On failure, capture error details.
Use a parallel scope (success vs. failure path) to log exceptions gracefully.

Please refer to my LinkedIn post Power Automate: Stop Letting Your Flows Fail Silently! for details on how to set it up.

3. Connection References

Broken flows after deployment?
Check if the connection reference is valid in the target environment.
Automate overrides during deployment (DevOps pipelines help here).

4. Logging & Notifications

Create a simple Log entity/table in Dataverse to capture errors.
Add Teams/email notifications with correlation IDs so you can trace the issue back.

Debugging Integrations

When dealing with external systems (e.g., Azure Functions, Service Bus, FinOps):

Always log request/response payloads (sanitized if sensitive).
Use Retry policies and dead-letter queues for resiliency.
Leverage Application Insights for distributed tracing.

Example: Logging Flow Errors

Here’s a simple pattern using a failure scope:

{
  "status": "Failed",
  "error": "@{result('Update_Record')?['body/error/message']}",
  "correlationId": "@{workflow()?['run']['id']}"
}

This way you know what failed, why, and how to trace it back.

Key Takeaways

Flows are only as transparent as you make them.
Run history + good error handling + structured logging = faster debugging.
For integrations, think end-to-end: payloads, retries, monitoring.

📖 Earlier posts in the series:

Part 1 – Debugging JavaScript
Part 2 – Debugging Plugins in DEV
Part 3 – Debugging in Sandbox & Production

Debugging in Dynamics 365 CE – Part 3: Server-Side (Sandbox vs. Production)

Nikhil Sarpatwari — Sun, 24 Aug 2025 03:31:34 +0000

In Part 1, we looked at debugging JavaScript.

In Part 2, we explored plugin debugging in DEV with the Plugin Registration Tool and plugin trace logs.

Now, let’s dive into something trickier: debugging in Sandbox and Production environments.

Why Sandbox & Production Debugging Matters

When issues arise outside DEV, attaching a debugger isn’t always an option. Instead, you rely on trace logs, custom logging, and smart error handling.

This is where real-world debugging skills shine—balancing performance, user experience, and capturing enough detail to diagnose issues effectively.

Tools in Your Toolkit

1. Plugin Trace Logs

Enable them in Sandbox for detailed exception messages.
Adjust the logging level (Exception, All) based on the scenario.

2. Custom Logging

Create a lightweight logging entity/table (e.g., new_pluginlog).
Store details like:
- Correlation ID
- Message name
- Record ID
- Exception stack trace
Implement cleanup/retention policies to avoid database bloat.

3. Correlation IDs

Every error in Dynamics is tied to a correlation ID.
Combine with Application Insights or your custom log table for cross-referencing.

4. Application Insights / Azure Monitor

For enterprise scenarios, push plugin logs to Application Insights.
Benefit from rich querying, dashboards, and alerting.

Key Practices

Never debug directly in Production with a debugger attached—it’s unsupported and unsafe.
Use Sandbox with production-like data to replicate issues before attempting fixes.
Log enough detail to reproduce bugs without leaking sensitive information.
Implement feature flags or environment variables for toggling verbose logging safely.

Example: Logging Exception with Correlation ID

catch (Exception ex)
{
    tracingService.Trace("Plugin Error: {0}", ex.ToString());
    var log = new Entity("new_pluginlog");
    log["new_name"] = $"Error on {context.MessageName}";
    log["new_correlationid"] = context.CorrelationId.ToString();
    log["new_errordetails"] = ex.ToString();
    service.Create(log);
    throw;
}

Wrapping Up

Debugging in Sandbox and Production isn’t about attaching a debugger—it’s about visibility, traceability, and safe practices.

With the right mix of trace logs, custom logging, correlation IDs, and monitoring tools, you can diagnose even the trickiest issues without compromising stability.

Stay tuned for Part 4, where I’ll cover debugging Power Automate flows and integrations.

📖 If you missed them:

Part 1 – Debugging JavaScript
Part 2 – Debugging Plugins in DEV