chamara iresh's Blog

Mastering Microsoft Dynamics 365 CRM Plugins: The Ultimate Deep Dive

2025-07-12T19:39:00.003+09:00

Microsoft Dynamics 365 is an incredibly powerful platform, and plugins are one of its best-kept secrets for unlocking real business transformation. If you’ve ever wondered how to enforce complex validation, perform lightning-fast integrations, or inject truly custom business logic at just the right moment — plugins are your answer. After a decade of developing, troubleshooting, and optimising plugins for enterprises and startups alike, here’s a comprehensive guide on everything you need to know, distilled from years in the trenches.

What Exactly is a Dynamics 365 Plugin?

At its core, a Dynamics 365 plugin is a custom .NET class that runs when a specific event happens in the Dataverse platform. Think of plugins as your own logic, running invisibly on the server, responding instantly to changes like creating, updating, or deleting a record. While Microsoft calls these “extensibility points,” I see them as strategic hooks to make the system behave precisely the way your business demands.

Why should you care? Because plugins can do what no other tool in Dynamics can: enforce rules and logic at the data layer, right inside the transaction. This means the rules are always enforced, regardless of whether data is entered through the user interface, an Excel import, or a third-party integration. When built well, plugins are fast, reliable, and can even interact with external systems in real time.

Real-World Plugin Use Cases

Advanced Validation: For example, enforcing discount rules or compliance checks that are simply too complex for Business Rules or Power Automate flows.
Live Integration: Instantly syncing data to an ERP, or checking an external fraud service before allowing a new lead to save.
Automated Decisions: Routing records to the right team, calculating bonuses, or auto-populating related data, all before the user even sees the change.
Transactional Consistency: Ensuring that if anything goes wrong, all changes are rolled back together.

Understanding the Plugin Execution Pipeline

Mastering plugins starts with understanding the event pipeline. Here’s how Dynamics 365 processes an operation, and where your code can plug in:

Stages in the Pipeline

Pre-Validation: The very first gate, running before security checks and outside the main transaction. Use this for quick early validation.
Pre-Operation: Runs just before the record is saved, inside the database transaction. Here, you can change data before it’s committed — great for setting default values or enforcing business logic.
Main Operation: This is the core platform event (like actually creating the record). Custom code cannot run here.
Post-Operation: Executes after the record is saved but still inside the transaction (if sync), or right after commit (if async). Perfect for tasks like creating related records, sending notifications, or updating other data based on the saved result.

Synchronous vs Asynchronous Plugins

Synchronous plugins run in real-time; the user waits for them to finish. These are ideal for validation and actions that must complete before saving.
Asynchronous plugins run in the background, after the data is saved. These are great for tasks like calling web services or updating external systems, as they do not impact the user’s experience.

Transaction and Rollback

A crucial point: synchronous plugins in Pre-Operation and Post-Operation are part of a single transaction. If a plugin fails, the entire operation rolls back. Asynchronous plugins, on the other hand, cannot roll back the original data change.

Depth and Preventing Infinite Loops

Plugins can trigger other plugins, and Dynamics tracks this with a Depth property. If your plugin is triggered by another plugin’s update, Depth increases. To avoid infinite loops, always check the Depth and consider returning early if it’s above a certain threshold.

Images: Pre-Image and Post-Image

Plugins can access snapshots of the record before and after the change. Register a Pre-Image to see the original values, or a Post-Image to get final values after save. This is essential for comparing changes.

Filtering Attributes

When registering Update-step plugins, specify the fields that should trigger your logic. This makes your plugin more efficient and prevents unnecessary executions.

Synchronous vs Asynchronous Plugins: When to Use Each

Ask yourself:

Do you need to stop the save if something goes wrong? Use synchronous.
Is your logic time-consuming or depends on slow external systems? Go with asynchronous.
Do you need to provide instant feedback to users? Only synchronous plugins (or real-time workflows) can display error messages instantly.
Is it okay if the operation completes and your custom logic happens shortly after? Asynchronous is ideal.

In most enterprise systems, a mix of sync and async plugins keeps things both robust and performant.

Plugins vs. Other Tools

How do plugins compare to Power Automate, Business Rules, and JavaScript?

Plugins are best for complex, transactional, or high-performance logic.
Power Automate is great for cross-system automation, but it is always asynchronous and cannot cancel a save.
Business Rules are quick for simple field logic on forms but don’t work in all scenarios.
JavaScript is for UI interactions only, and never runs on imports or integrations.

Writing Your First Plugin: Key Components

The IPlugin Interface

Every plugin implements the IPlugin interface and its Execute(IServiceProvider serviceProvider) method. This is where everything happens.

public class MyPlugin : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        // Plugin logic here
    }
}

Accessing Context and Services

IPluginExecutionContext: Gives you all the event info — what triggered the plugin, which entity, what stage, what data.
IOrganizationService: Use this to read or write data in Dataverse.
ITracingService: Your best friend for debugging — trace messages appear in Plugin Trace Logs or System Jobs.

Typical plugin setup:

var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
var serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
var service = serviceFactory.CreateOrganizationService(context.UserId);
var tracing = (ITracingService)serviceProvider.GetService(typeof(ITracingService));

Implementing Logic

Check that the event is the one you want (e.g. context.MessageName == "Create").
Validate or transform data as needed.
Perform CRUD operations with IOrganizationService.
Trace key steps for diagnostics.

Exception Handling

To cancel a save or surface a user-friendly error, throw an InvalidPluginExecutionException with a message. Always trace exceptions for easier support.

Registering Plugins

Use the Plugin Registration Tool to upload your assembly, then register “steps” to define which event, entity, and stage should trigger your plugin. Include the plugin in your Solution so it can be deployed across environments.

Plugin Best Practices

Keep plugins stateless and thread-safe. Never use static variables for data you care about across plugin runs.
Early returns. Always check if the context fits your logic — exit early if not.
Avoid long-running code in synchronous plugins. Any delay here holds up users.
Filter attributes for updates. Register plugins to fire only on fields that matter.
Never run batch operations or spawn threads inside plugins. If you need bulk processing, do it outside plugins or break it into smaller operations.
Query only what you need. Minimize data retrieval for performance.
Avoid updating the same record in Post-Operation. This creates potential loops.
Use transactions wisely. Know that a sync plugin failure will roll back all changes.
Trace smartly. Use ITracingService.Trace for entry, exit, and exceptions—don’t overdo it in production.
Cache carefully. For reference data, use thread-safe, short-lived caches. Never cache large datasets in memory.
External API calls. Always set timeouts, handle errors, and do this asynchronously if possible.
Use secure config for secrets. Store API keys and sensitive info in Secure Configuration at plugin registration, not in code.
Prevent infinite loops. Use Depth checks, or flag attributes if needed.

Advanced Techniques for Senior Developers

Custom Actions and APIs: Create your own Dataverse messages with input/output parameters, then use plugins to implement the logic. This is perfect for reusable business operations.
Plugin Isolation/Sandbox: All plugins in the cloud run in a secure sandbox with limited permissions, no file system or registry access, and capped memory. Respect these boundaries.
Generic plugins: Handle logic for multiple entities in a single class by switching based on the context.
Impersonation: You can run plugins as a specific user (for special permissions). Useful for system-level operations.
Integration with external systems: Consider webhooks or offloading heavy work to Azure Functions for maximum scalability and minimum user impact.
Monitoring: Leverage Plugin Trace Logs and custom telemetry (for example, using Application Insights) to track performance and errors.

Automating Plugin Deployment: spkl and DevOps

Manual plugin registration is error-prone and doesn’t scale. Modern teams use tools like spkl (Sparkle) to automate deployment in CI/CD pipelines. You define registration details in a config file and use spkl to push your assemblies and steps. This keeps everything in source control and repeatable across environments. Microsoft’s Power Platform CLI is another great tool for managing solutions and plugin projects automatically.

Testing and Debugging Plugins

Unit testing plugins is a huge productivity booster. Frameworks like FakeXrmEasy allow you to simulate plugin contexts and test your logic in isolation. For live debugging, use the Plugin Registration Tool’s Profiler to capture and replay plugin executions in Visual Studio — especially invaluable for tracking down tough bugs in complex solutions.

Common Pitfalls and How to Avoid Them

Infinite loops (Depth checks and careful design)
Null reference errors (Always check if fields exist before using them)
Misregistered steps (Double-check your registrations)
Security exceptions (Run plugins under the correct user or with the right privileges)
Performance issues (Keep plugins fast, use filtering attributes)
Bulk data handling (Plugins must handle high-volume scenarios gracefully)

Latest Features and Innovations

The plugin model keeps evolving. With features like Custom APIs, seamless Azure integration, and robust DevOps tooling, it’s easier than ever to build maintainable, enterprise-ready logic in Dataverse.

Final Thoughts

Mastering plugins is a journey — from writing your first validation handler to architecture complex integrations that power the world’s largest enterprises. The techniques and tips here come from real projects, real support escalations, and plenty of lessons learned the hard way. If you embrace best practices, automate your deployments, and always keep performance in mind, plugins will be your secret weapon for building systems that truly deliver.

Happy coding, and may your plugins always be fast, safe, and bug-free!

Want more deep dives on Dynamics 365 development? Let me know what topics to cover next!

Model Context Protocol (MCP) + Dataverse: The Next Leap for AI and the Power Platform

2025-07-11T00:01:00.004+09:00

If you’re even a little bit invested in Power Platform, you’ve probably seen the Model Context Protocol (MCP) popping up in community posts, new features, and the Microsoft docs. If you’re wondering, “Is this just another buzzword, or does it actually make my life easier?” — this post is for you!

Let’s break down what MCP is, what you can do with it (hint: a lot!), and why this matters for every maker, developer, and AI enthusiast on the platform.

What is Model Context Protocol (MCP)?

MCP is a new open protocol from Microsoft that lets Large Language Model (LLM) applications — like Copilot Studio, Claude, VS Code Copilot — connect securely and natively to enterprise data sources like Dataverse. This means that your AI agents can “see” and work with your real Dataverse data, safely and efficiently, with no custom connectors or APIs needed.

Learn more: Connect to Dataverse with Model Context Protocol (preview)

Why Does MCP Matter?

No more manual queries: Just ask questions in natural language — “How many leads are active?” or “Show me a chart of cases by city” — and your agent (Claude, Copilot, etc.) does the heavy lifting.
Instant insights and updates: You can fetch, update, and create Dataverse records as simply as sending a chat message.
Build bots and automations faster: Tools like Copilot Studio can now “think” in real time with your data — great for building conversational agents and process automations.
Less code, more power: You can do all of this without needing to write FetchXML, SQL, or custom code.
Future-proof integration: Any AI or LLM tool supporting MCP can plug into your Dataverse data — opening up a huge ecosystem of smart, connected tools.

What Can You Actually Do with MCP + Dataverse?

Here’s just a taste of what’s possible right now (and it’s still just in preview!):

List all your tables: “Show me all tables in Dataverse.”
Describe schema: “Describe the account table.”
Read/query data: “How many contacts live in London?”
Create/update records: “Add a new contact: John Smith, email john@contoso.com.”
Build charts instantly: “Create a pie chart showing opportunities by owner.”
Integrate knowledge sources: “What’s the latest update from the product knowledge base?”

Basically, you can talk to your database, and it talks back with real answers, records, or charts — no code, just conversation.

How to Set Up MCP with Dataverse (Step by Step)

This is easier than you think. Here’s the process, based on Microsoft’s official docs :

Prerequisites:

Dataverse environment (Power Platform, Power Apps, or Power Automate)
VS Code installed (for advanced setup)
Claude Desktop (optional, but great as an MCP client)
.NET SDK 8.0 (for the MCP server local proxy)
Your Dataverse tenant ID
Dataverse connection (created in Power Automate)

What Tools Are Available?

From the official documentation, Dataverse MCP tools include:

create_record — Insert a row into a table
describe_table — Get table schema
execute_prompt — Run a predefined prompt
list_knowledge_sources — Show available knowledge sources
list_prompts — List prompts
list_tables — List available tables
read_query — Read data from tables
retrieve_knowledge — Query a knowledge source
update_record — Update a record

You can enable/disable each tool in your MCP config, so you’re always in control.

Limitations & Tips

Preview Feature: As of mid-2025, MCP with Dataverse is still in preview — don’t use in production just yet!
Security: Make sure you understand the permissions you grant your AI client.
Customization: Tune which tools you expose, and set your own prompts/knowledge sources for maximum flexibility.

Conclusion

Model Context Protocol (MCP) is the next frontier for Power Platform, AI, and no-code/low-code automation. You can connect any MCP-enabled AI client (Copilot, Claude, custom bots) to Dataverse and get natural, conversational access to your enterprise data.

No more clunky queries. No more endless charts. Just instant answers, insights, and updates — straight from your data, with the power of AI.

A big thank you to the amazing video guide creator
Nathan Rose — your step-by-step walkthrough made the whole process so much more approachable and fun for the community.

https://youtu.be/IkBRy8bVtrc?si=CZFlaY36Ojap15GM

How to Master Solution Layering and Troubleshoot Customization Conflicts in Dynamics 365 CRM

2025-07-10T23:59:00.006+09:00

If you’ve ever deployed a solution to a Dynamics 365 CRM environment only to find your changes don’t show up, or something strange happens with forms or fields, you’re not alone. Almost every Dynamics admin or customizer has run into the mysterious world of solution layering. It’s not always intuitive, but understanding how solution layers work is absolutely key for troubleshooting post-deployment issues and building a sustainable ALM (Application Lifecycle Management) process.

Let’s break down what solution layering is, how conflicts can occur, and how to confidently resolve them.

What Is Solution Layering in Dynamics 365 CRM?

Solution layering refers to the way Dynamics 365 (and Power Platform/Dataverse) manages multiple sets of customizations, especially when you have more than one solution (managed or unmanaged) touching the same component.

Every customizable object, like a form, view, or field, can have multiple “layers” of configuration applied. The platform keeps track of these layers and uses a clear order to decide what users will see and how components behave.

The Three Key Layers

System (Base) Layer:
The lowest layer. This is the original, out-of-the-box state ,think of it as the bedrock for every component.
Managed Solution Layers:
Each imported managed solution gets its own layer. Managed layers stack on top of the system layer in the order they’re imported. The most recent one always sits above earlier ones.
Unmanaged Layer:
The very top. Any direct customizations made in the environment (through the UI, or via unmanaged solutions) live here. There is only one unmanaged layer per component, and the latest change always wins in this layer.

Why does this matter? Because only the topmost value (or a merge of layers, depending on the component) is active at runtime. This is why the changes you just imported sometimes seem to “disappear” or get overridden by something you didn’t expect.

How Do Layer Conflicts Happen?

Let’s say you install a third-party managed solution that customizes the Account form, maybe it adds a couple of new sections. Later, you deploy your own managed solution, which also customizes that Account form (perhaps adding a new section for internal use).

At runtime, the Account form merges customizations from both solutions, unless they directly conflict (for example, both try to change the header text). In that case, the topmost layer “wins.”
If someone makes a direct change in production (for instance, hiding a field to fix a quick issue), that unmanaged layer sits above everything else, even above your newly-deployed managed solution.

Common Example:
You deploy a managed solution expecting to see a new field on the form, but it’s not visible to users. You open the solution layers viewer and find an unmanaged change sitting on top (maybe a previous quick fix), which is hiding your field.

Merge or “Last One Wins”?

Some things merge:
For example, if two managed solutions add different fields to the same form, both fields are visible, because those additions merge.
Some things overwrite:
If two solutions provide a button or field with the same name/ID, or try to set a property like the display name or visibility, the “last one wins.” The topmost solution layer’s value is what the user will see.
Unmanaged layer always wins:
Any direct changes made in the environment (the unmanaged layer) always take precedence. That’s why making direct changes in production is risky, it can override everything below.

How to Troubleshoot with the Solution Layers Tool

Dynamics 365 includes a powerful tool for investigating component layering:

Go to the Power Apps Maker portal
Find the component (form, view, field, etc.) you’re troubleshooting
Select it and choose “See solution layers”

You’ll see all the layers, in order, and can review what each solution changed. Properties that were altered by a solution are highlighted.

Pro tip: If you can’t see your recent change in production, check here first. If there’s an unmanaged layer on top, that’s almost always the culprit.

The Unmanaged Layer: A Double-Edged Sword

Unmanaged customizations are a frequent cause of “why isn’t my solution working?” problems. For instance:

A System Customizer makes a “quick fix” to a form in production, creating an unmanaged layer.
You deploy a managed solution to update that same form, but your changes don’t appear, because the system uses the unmanaged version as the active layer.

How to fix:

Either incorporate that unmanaged change into your managed solution and redeploy
Or: Use “Remove Active Customizations” to delete the unmanaged layer for that component (be aware: this discards those ad-hoc changes!)

Warning: If the unmanaged layer added fields with data, removing it will remove the field and its data.

Resolving Managed Solution Conflicts

When two managed solutions conflict (maybe both add a field with the same name, or try to change the same form property), you have a few options:

Manage Layer Order
Re-import the solution you want to take precedence. (Remember, the most recently imported managed solution is on top.)
Adjust the Customizations
If you own both solutions, tweak them so they don’t overlap (use unique names or separate component responsibilities).
Use a Patch or Hotfix Solution
If you can’t remove the “problem” managed solution (e.g., it’s a core or third-party solution), create a tiny managed patch or hotfix solution. This patch will layer above, overriding the problematic setting or property.
Uninstall or Clean Up
As a last resort, uninstall the managed solution causing the issue, but only if nothing else depends on it.

Dependency Issues: Why Can’t I Uninstall a Solution?

Another layering-related headache: Sometimes you can’t uninstall or upgrade a solution because something else (another solution or unmanaged change) is using its components. You’ll usually get a descriptive error listing the dependencies.

Use the solution layers viewer to see what’s on top of the component you’re trying to remove.
Remove or reconfigure any dependent solutions or unmanaged changes first.

How to Use Layering to Your Advantage

Solution layering isn’t just a problem to solve, it’s a powerful tool if you plan for it.

Modular design:
Have a base managed solution for your core entities, and layer feature-specific managed solutions on top. Teams can work independently as long as they avoid overlapping components.
Safe rollbacks:
If you need to remove a feature, you can just uninstall its solution — everything beneath remains intact.
Hotfixes:
Emergency patch needed? Deploy a managed patch solution. It sits on top, overrides what’s needed, and can be rolled back easily.

Best Practices & Tips

Always use the Solution Layers viewer when troubleshooting.
Document which solutions “own” which parts of your system to avoid accidental overlap.
Avoid direct unmanaged changes in production — if you must, plan to integrate them back into a managed solution and remove the unmanaged layer ASAP.
Check Solution Import logs: These can warn you if components were skipped or a conflict occurred.
Test all changes in a non-prod environment first. Removing or reordering solution layers can have side effects.

Summary

Solution layering in Dynamics 365 CRM can feel confusing at first, but it’s a robust system for handling complex, multi-team, and even multi-vendor deployments. The trick is to respect the order of layers, avoid unmanaged “quick fixes” in production, and always use the tools Microsoft provides to see what’s going on.

If you ever run into a situation where “my change isn’t showing up” or “something broke after a deployment,” the solution layers tool should be your first stop. With a clear ALM strategy and a little practice, you’ll turn layering from a headache into a feature that helps you build, troubleshoot, and evolve your CRM with confidence.

Extra Reading & Resources:

Got a layering war story or pro tip? Drop it in the comments!

How We Recovered a Retired Product in Microsoft Dynamics 365 CRM (And What You Can Do)

2025-06-05T20:09:00.002+09:00

Recently, I heard from a friend who had faced a major issue in their CRM system — one that could easily turn into a nightmare if you’re not prepared.

If you’ve ever worked with Microsoft Dynamics 365 CRM, you’ll know that products can be inactivated (retired) when they’re no longer needed. But what happens if you need to reactivate a product that was retired? You’d expect it to be simple, but surprisingly, it’s not possible out of the box (OOB).

Here’s what happened — and what you can do if you ever face this problem in your live environment.

The Problem

They found a critical product had been retired by mistake. When they tried to reactivate it, there was no way to bring it back using standard CRM functionality.

They were stuck — and with the product inactive, it wasn’t showing up where it was needed, impacting real business processes.

What They Did

First, they assessed the issue and confirmed: no OOB (out-of-the-box) way exists to reactivate retired products.
Next, they raised a support ticket with Microsoft. Microsoft’s team ran a backend script to move the product’s status from Retired back to Draft.

At this point, things looked better — the product was visible again.

But...

The Hidden Problem

When trying to use the product — like adding it to a cart — errors popped up:

"An error occurred while saving the {0} property instance."
"Specified argument was out of range of valid values. Parameter name: value."

Confusing, right?

It turned out that while the product was moved to Draft, one of its Product Properties — a field related to the product — was still inactive.

CRM didn’t like that mismatch.

The Real Fix

They went back to Microsoft support, flagged the new issue, and explained what they had found.

Microsoft’s engineers:

Ran a test script in UAT (test environment) to reactivate the inactive Product Property.
After confirming everything worked there, they ran the script in the Live environment.

Finally, the errors were gone. The product could be used normally again — just like before it was retired.

Key Takeaways

If this ever happens to you:

You can’t reactivate a retired product OOB — Microsoft support is needed.
Simply changing the product status isn’t enough — check the related Product Properties too.
Raise a detailed support ticket and suggest checking Product Properties if you hit errors.
Test fixes in UAT first before applying anything live.

It’s one of those hidden challenges that can trip you up if you’re not careful. Hopefully, if you ever end up in a similar situation, this story will save you hours of troubleshooting!

Decoding the Mystery of msdynci Columns in Dynamics 365 and Customer Insights

2025-04-23T06:13:00.007+09:00

Integrating Microsoft Dynamics 365 CRM with Customer Insights - Data (CI-D) opens up a world of possibilities for understanding your customers better. But as you navigate this integration, you might notice something peculiar: certain tables, like your trusty Contacts, get these columns prefixed with msdynci_, while others seem to miss out. If you've ever wondered if your data sync is working correctly, you're not alone. The truth is, this isn't a random occurrence – it's a deliberate design that reflects how Customer Insights handles different types of data.

The Purpose Behind the Pattern: Why Only Some Tables Get the `msdynci_` Prefix

Think of Customer Insights - Data as a platform built to create a unified and comprehensive view of your customers. To achieve this, it focuses on what it considers "profile" tables – primarily your Contact and Account entities.¹ When you set up the synchronization between Dynamics 365 CRM and CI-D, the system identifies these key entities as central to building that single customer profile.¹

To power features like profile unification, data enrichment, audience segmentation, and even predictive scoring, Customer Insights - Data automatically adds specific metadata fields to these designated profile tables ^1. These are the columns you see with the msdynci_ prefix. They act as internal markers, helping Customer Insights track and manage profile-related data more effectively.¹

Here are a few key msdynci_ columns you'll likely encounter in your core profile tables:

msdynci_isprofile: This column likely acts as a simple yes/no indicator, telling the system whether a specific record (like a Contact) is actively contributing to your unified customer profile within Customer Insights - Data.²
msdynci_lastprofileupdate: Think of this as a digital timestamp. It probably records the exact date and time when a record's profile information was last updated or refreshed by Customer Insights - Data.² This is crucial for knowing how recent your unified customer data is.
msdynci_profilestatus: This column likely holds a status code or value that reflects the current stage of a record's profile within the Customer Insights - Data processing pipeline.² It could indicate if a profile is active, pending unification, or has been successfully unified.

Now, what about other tables in your Dynamics 365 environment, such as custom entities or standard tables like Activities? These are generally not automatically treated as core profiles in Customer Insights - Data.⁴ As a result, they don't automatically receive the msdynci_ columns unless you explicitly configure them within CI-D.⁴ This design helps keep the focus on the most critical customer data for unification.

Validating Your Integration: Ensuring Smooth Synchronization

To make sure your Dynamics 365 CRM and Customer Insights - Data integration is working as expected, here are a few key steps you can take ⁵:

Examine Sync Health Metrics: Head over to the Power Platform Admin Center. Here, you can usually find a dashboard that shows the overall health of your data synchronization, including the status of individual tables.
Verify Table Classifications in CI-D: Open up Customer Insights - Data and navigate to Data > Tables. This section allows you to see how each table is classified (e.g., as a profile, interaction, or relationship) and confirm which tables are being actively used.
Configure Non-Profile Tables: If you have custom entities that you want to include in your Customer Insights data model, you'll likely need to manually map them within CI-D. This involves defining their schema and specifying how they relate to your core profile entities.

Key Insights for Administrators

Understanding the selective nature of msdynci_ columns is crucial for anyone managing a Dynamics 365 and Customer Insights - Data integration. It provides a clear view into how Customer Insights categorizes and processes your CRM data, helping to maintain a distinction between core profile information and other supporting data.¹ When building your unified customer data models, recognizing this architectural choice ensures you can accurately interpret table structures and establish effective relationships between different entities.

Diving Deeper: Exploring Other `msdynci_` Tables

Beyond the key columns mentioned earlier, the integration also creates several other tables in your Dataverse environment, all helpfully prefixed with msdynci_.¹ These tables serve specific purposes in managing and enriching your customer data:

Table Name	Key Columns	Description
`msdynci_alternatekey`	`DataSourceName`, `TableName`, `AlternateValue`, `CustomerId`, `AlternateKeyId`, `Identifier`	Contains mappings between the unique identifier Customer Insights - Data generates for a customer and their original identifiers from source systems like Dynamics 365 CRM .
`msdynci_unifiedactivity`	`CustomerId`, `ActivityId`, `SourceTableName`, `SourceActivityId`, `ActivityType`, `ActivityTimeStamp`, `Title`, `Description`, `URL`	Stores a consolidated view of customer activities (e.g., purchases, website visits, support interactions) gathered from various connected data sources, providing a unified timeline for each customer profile.⁵
`msdynci_customermeasure`	`CustomerId`, `Measures`, `Identifier`, `CustomerMeasureId`	Holds calculated metrics and Key Performance Indicators (KPIs) derived at the level of the unified customer profile, enabling tracking and analysis of crucial business metrics at an individual customer level.⁵
`msdynci_enrichment`	`CustomerId`, `EnrichmentProvider`, `EnrichmentType`, `Values`, `EnrichmentId`, `Identifier`	Stores the results of data enrichment processes, where customer profiles are augmented with additional information from Microsoft or third-party data providers, enhancing the comprehensiveness of customer understanding.⁵
`msdynci_prediction`	`CustomerId`, `ModelProvider`, `Model`, `Values`, `PredictionId`, `Identifier`	Contains the output and results generated by predictive AI models within Customer Insights - Data, providing insights into potential future customer behaviors and outcomes for proactive interventions.⁵
`msdynci_segmentmembership`	`CustomerId`, `SegmentProvider`, `SegmentMembershipType`, `Segments`, `Identifier`, `SegmentMembershipId`	Records which specific customer segments (defined within Customer Insights - Data) each unified customer profile is a member of, essential for enabling targeted marketing and personalized experiences.⁵

Real-World Applications: Putting `msdynci_` Columns to Work

Understanding these msdynci_ columns and tables opens up various practical applications :

Smarter Segmentation: Use msdynci_isprofile to create highly targeted audience segments that include only fully unified customer profiles.
Personalized Interactions: Leverage msdynci_lastprofileupdate to ensure your sales and service teams have the most up-to-date customer information for more relevant conversations.
Troubleshooting Integration Issues: Monitor msdynci_profilestatus to quickly identify and address any records that may have failed to unify correctly.
Comprehensive Customer Journeys: Utilize msdynci_unifiedactivity to gain a holistic view of customer interactions across all touchpoints, enabling more effective journey mapping.
Data-Driven Insights: Employ msdynci_customermeasure to track key metrics like customer lifetime value and tailor business strategies accordingly.
Targeted Marketing: Rely on msdynci_segmentmembership to deliver personalized marketing messages and offers based on specific customer segment affiliations.

Staying Informed: Recent Updates and Best Practices

The landscape of Dynamics 365 and Customer Insights is constantly evolving. Keeping an eye on recent release waves and updates is essential. Features like enhanced integration with Microsoft Fabric OneLake and improvements to the Dataverse connector can influence how msdynci_ data is managed.

For optimal management of your integration, remember these best practices :

Strategic Synchronization: Only sync necessary entities to avoid performance bottlenecks.
Data Quality First: Implement robust data unification processes within Customer Insights - Data to ensure accurate and complete customer profiles.
Regular Monitoring: Keep a close watch on the data synchronization status in both Dynamics 365 CRM and Customer Insights - Data to identify and resolve any issues promptly.⁵

By understanding the role of msdynci_ columns and following these best practices, you can confidently navigate the integration between Microsoft Dynamics 365 CRM and Customer Insights - Data, unlocking the full potential of your customer data.

Mastering the Intersect Method in C#: A Beginner's Guide

2025-03-05T04:15:00.001+09:00

Have you ever needed to figure out what two lists have in common? Maybe you’re comparing two sets of numbers or trying to find students who appear in two different class rosters. In C#, the Intersect method from LINQ is your go-to tool for this. Think of it as finding the overlap between two circles in a Venn diagram—only the elements present in both collections make it to the final result.

In this blog, we’ll walk through how to use Intersect step by step. We’ll cover the basics, dive into using it with custom objects, talk about performance, and show you how to handle tricky situations like null values. Whether you’re new to C# or looking to brush up on your skills, this guide is written to be clear, simple, and easy to follow. Let’s get started!

What is Intersect?

Intersect is a handy LINQ method in C# that finds the common elements between two collections. It’s part of the language’s set operations, meaning it works like a filter that keeps only what’s shared between the two. No need to write long loops or complicated logic—Intersect does the heavy lifting for you.

For example, imagine you have two groups of friends, and you want to know who’s in both groups. Intersect is your shortcut to spotting those mutual buddies.

Basic Usage with Simple Types

Let’s kick things off with an easy example using lists of numbers. Here’s how Intersect works with basic types like integers:

using System;
using System.Linq;
using System.Collections.Generic;

class Program
{
    static void Main()
    {
        // Two lists of numbers
        List<int> list1 = new List<int> { 1, 2, 3, 4, 5 };
        List<int> list2 = new List<int> { 3, 4, 5, 6, 7 };

        // Find the common elements
        var commonElements = list1.Intersect(list2);

        // Print the result
        Console.WriteLine("Common Elements: " + string.Join(", ", commonElements));
        // Output: Common Elements: 3, 4, 5
    }
}

In this code:

list1 has numbers 1 through 5.
list2 has numbers 3 through 7.
Intersect gives us 3, 4, and 5—the numbers that appear in both lists.

It’s that simple! For basic types like integers or strings, Intersect works out of the box because C# already knows how to compare them.

Using Intersect with Custom Objects

Things get a little trickier when you’re dealing with your own custom objects, like a Student class. By default, C# compares objects by their references (think of it as their memory address), not their actual values. So, if you have two Student objects with the same name but stored in different places in memory, Intersect won’t see them as equal—unless we teach it how.

Let’s define a Student class:

public class Student
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Now, suppose we have two lists of students, and we want to find the ones in both lists based on their Id. Here’s where a custom comparer comes in. We’ll create a StudentComparer class to tell Intersect to compare students by their Id:

public class StudentComparer : IEqualityComparer<Student>
{
    public bool Equals(Student x, Student y)
    {
        // Two students are equal if their IDs match
        return x.Id == y.Id;
    }

    public int GetHashCode(Student obj)
    {
        // Generate a hash code based on the ID
        return obj.Id.GetHashCode();
    }
}

With our comparer ready, let’s use Intersect:

List<Student> students1 = new List<Student>
{
    new Student { Id = 1, Name = "Alice" },
    new Student { Id = 2, Name = "Bob" },
    new Student { Id = 3, Name = "Charlie" }
};

List<Student> students2 = new List<Student>
{
    new Student { Id = 2, Name = "Bob" },
    new Student { Id = 3, Name = "Charlie" },
    new Student { Id = 4, Name = "David" }
};

// Find common students using the custom comparer
var commonStudents = students1.Intersect(students2, new StudentComparer());

foreach (var student in commonStudents)
{
    Console.WriteLine($"ID: {student.Id}, Name: {student.Name}");
}
// Output:
// ID: 2, Name: Bob
// ID: 3, Name: Charlie

Here:

students1 and students2 share students with IDs 2 and 3.
The StudentComparer ensures Intersect matches them by Id, not memory location.
We get Bob and Charlie as the result—exactly what we wanted!

Performance: Why Intersect Shines

One reason to love Intersect is its speed. Under the hood, it’s optimized to use a set-based approach, which is much faster than writing your own loops, especially for big lists. It’s like having a super-smart assistant who can instantly spot matches.

For even better performance, try using HashSet<T> instead of List<T> when working with large datasets. A HashSet is built for quick lookups, making Intersect run like lightning. Here’s a tip: if you’re dealing with thousands of items, converting your lists to hash sets first can save you serious time.

Handling Null Values Like a Pro

In real-world coding, you’ll often run into null values—lists that haven’t been initialized or data that’s missing. If you don’t handle these, Intersect can throw a nasty null reference exception and crash your program. Let’s make our code bulletproof by adding null checks.

Here’s an example where one list might be null:

List<Student> a = null;
List<Student> b = new List<Student>
{
    new Student { Id = 10, Name = "test" }
};

// Check if both lists are null
if (a == null && b == null)
{
    Console.WriteLine("Both lists are null. Nothing to process.");
    return;
}

// Safely intersect with null handling
var c = a?.Intersect(b, new StudentComparer()) ?? b ?? new List<Student>();
var d = b?.Intersect(a ?? new List<Student>(), new StudentComparer()) ?? new List<Student>();

// Show the results
Console.WriteLine("Common elements in 'c':");
foreach (var item in c)
{
    Console.WriteLine($"ID: {item.Id}, Name: {item.Name}");
}

Console.WriteLine("\nCommon elements in 'd':");
foreach (var item in d)
{
    Console.WriteLine($"ID: {item.Id}, Name: {item.Name}");
}
// Output:
// Common elements in 'c':
// ID: 10, Name: test
//
// Common elements in 'd':

Let’s break it down:

a is null, and b has one student.
For c: Since a is null, a?.Intersect(...) is null, so c falls back to b (the ?? b part), giving us the student with ID 10.
For d: b.Intersect(a ?? new List<Student>()) means intersecting b with an empty list (since a is null), which results in nothing.
The ?. and ?? operators keep everything safe and crash-free.

This approach ensures your code stays robust, even when data goes missing.

Wrapping It Up

We’ve covered a lot about Intersect in C#! Here’s what we’ve learned:

It’s a LINQ method that finds common elements between two collections.
It works easily with simple types like numbers or strings.
For custom objects, you need a comparer to define what “equal” means.
It’s fast, especially with hash-based collections like HashSet.
Null handling with ?. and ?? makes your code reliable.

Intersect is a powerful little tool that can simplify your code and save you time. Whether you’re comparing lists of numbers or complex objects, it’s got your back.

Try It Yourself!

Now that you’ve seen Intersect in action, why not give it a spin in your next project? Play with the examples above, tweak them, and see how they fit your needs. Have a cool trick or question about Intersect? Drop it in the comments—I’d love to hear from you!

Happy coding!

Virtual Tables in Microsoft Dataverse - CRM Online

2025-02-03T21:09:00.000+09:00

Connect External Data in Real-Time Without Duplication

Introduction

Imagine needing to view customer orders stored in an ERP system directly within Microsoft Dataverse—without importing gigabytes of data. Or pulling live inventory numbers from a SQL database into your CRM to empower sales teams with real-time insights. This isn’t a futuristic dream; it’s exactly what Virtual Tables (formerly known as Virtual Entities) enable today.

Virtual Tables act as a dynamic bridge between Microsoft Dataverse and external systems, allowing you to interact with external data as if it were natively stored in your CRM. No duplication, no manual syncing, and no storage costs—just seamless, real-time access.

In this guide, we’ll explore how Virtual Tables work, when to use them, and how to implement them step-by-step in your Dataverse environment.

What Are Virtual Tables?

A Virtual Table is a special type of table in Microsoft Dataverse that connects to an external data source—like an ERP system, SQL database, or REST API. Unlike standard tables, Virtual Tables don’t store data locally. Instead, they fetch and display data on-demand from the external system, ensuring you always see the latest information.

Key Benefits of Virtual Tables

Eliminate Data Redundancy: Access external data without duplicating it in Dataverse.
Real-Time Insights: View live data from ERP, SQL, or web services instantly.
Cost Efficiency: Reduce storage costs by avoiding data imports.
Seamless User Experience: Use Virtual Tables in model-driven apps, Canvas apps, and Power Automate workflows just like native tables.
Flexible Integration: Support for OData v4 APIs, SQL databases, and custom data providers.

When Should You Use Virtual Tables?

Virtual Tables shine in scenarios where:

Data Resides Externally: Your ERP, legacy system, or third-party API holds critical data that needs to be accessed within Dataverse.
Real-Time Access Is Essential: Stale data isn’t an option (e.g., live inventory, pricing, or order status).
Large Datasets Are Involved: Importing massive data into Dataverse is impractical or costly.
Security or Compliance Constraints Exist: Data must remain in its source system due to governance policies.

Example Use Case:

A manufacturing company uses Virtual Tables to connect Dataverse to their on-premises SAP ERP system. Sales teams now view real-time production schedules and inventory levels in CRM, enabling accurate delivery promises without data duplication.

How Do Virtual Tables Work?

Virtual Tables rely on a data provider to communicate with the external system. Here’s the workflow:

Query: A user or app requests data from the Virtual Table (e.g., “Show all open orders”).
Fetch: Dataverse sends the query to the external data provider (e.g., an OData API or SQL connector).
Return: The provider retrieves the data and sends it back to Dataverse.
Display: The data appears in Dataverse as if it were a native table.

By default, Virtual Tables are read-only. However, you can enable create, update, and delete (CRUD) operations if the external system supports them.

Implementing Virtual Tables: A Step-by-Step Guide

Step 1: Prepare Your External Data Source

OData v4 APIs: Ensure your API endpoint is accessible and returns data in the correct format.
SQL Databases: Whitelist Dataverse IPs or set up secure connectivity (e.g., Azure Private Link).
- Custom Providers: Develop a custom connector if your source isn’t OData or SQL.

Pro Tip: Use tools like Postman to validate your API endpoints before connecting them to Dataverse.

Step 2: Register the Data Source in Dataverse

Navigate to Power Apps > Dataverse > Tables.
Under Settings (⚙), select Advanced Settings > Virtual Entity Data Sources.
Click New and choose your provider (e.g., OData v4).
Enter connection details (URL, authentication) and test the connection.

Step 3: Create and Map the Virtual Table

In Dataverse, click + New Table and toggle Virtual Table.
Select your registered data source.
Define the schema:

Map the external system’s primary key to Dataverse.
Add fields (e.g., “Order Number,” “Status”) and match them to the source’s columns.

Publish the table.

Step 4: Test and Deploy

Open the Virtual Table in Dataverse to verify data appears.
Embed it in a model-driven app or use it in a Power Automate flow.
Test CRUD operations if enabled.

Common Challenges and Solutions

No Data Displayed?

Confirm the data source URL is correct.
Check for authentication errors (e.g., expired tokens).
Verify field mappings (e.g., primary key matches).

Read-Only Limitations

Most providers default to read-only. Enable writes by configuring the external system to handle POST/PATCH requests.

Performance Lag

Optimize API/database queries (e.g., add filters or indexing).
Use pagination for large datasets.

Authentication Issues

Use Azure Active Directory (AAD) for OAuth-secured APIs.
For SQL, leverage Azure SQL’s firewall rules or managed identities.

References :

How to Integrate Customer Insights with Microsoft Dynamics 365 CRM Online

2025-01-24T04:06:00.005+09:00

In today’s customer-centric world, integrating Customer Insights with Microsoft Dynamics 365 CRM (Customer Relationship Management) Online enables organizations to unlock the power of data-driven decisions. By unifying disparate data sources, businesses can deliver personalized experiences and build stronger customer relationships. Here's a step-by-step guide to integrating Customer Insights with Dynamics 365 CRM Online and leveraging its capabilities.

What is Dynamics 365 Customer Insights?

Microsoft Dynamics 365 Customer Insights is a customer data platform (CDP) that consolidates customer data from various sources into a single unified profile. This helps organizations:

Gain a 360-degree view of customers: By aggregating data from marketing, sales, service, and other channels.
Deliver personalized experiences: Leverage AI and machine learning to gain actionable insights.
Optimize marketing and sales efforts: By predicting customer needs and preferences.

Steps to Integrate Customer Insights with Dynamics 365 CRM Online

1. Set Up Dynamics 365 Customer Insights

Provision the Customer Insights environment: Log into the Microsoft Power Platform Admin Center and provision a new Customer Insights instance.
Ingest data sources: Import data from multiple sources like Dynamics 365, Excel files, SQL databases, or third-party apps (e.g., Salesforce, Shopify).
Map and unify data: Use the unification feature to create a single customer profile by mapping data fields and resolving duplicates.

2. Enable Integration with Dynamics 365 CRM

Install Dynamics 365 connectors: Ensure that the Dynamics 365 Customer Insights connector is available in your environment.
Set up Power Automate flows: Use Power Automate to create workflows that sync Customer Insights profiles and insights into Dynamics 365 CRM entities such as Contacts or Leads.

3. Configure Customer Insights Cards in Dynamics 365 CRM

Enable Customer Cards in Dynamics 365 CRM to display real-time insights about a customer, such as:
- Purchase history
- Engagement levels
- Churn risk score
- Recommended next actions
Steps to set up Customer Cards:
1. Navigate to Settings in Dynamics 365 CRM.
2. Go to Customer Insights Integration and authenticate your Customer Insights environment.
3. Configure the fields and metrics to display within the CRM interface.

4. Utilize Prebuilt AI Models

Customer Insights includes AI models like:

Predictive churn: Identifies customers at risk of leaving.
Customer lifetime value (CLV): Calculates potential revenue from a customer.
Product recommendations: Provides personalized suggestions based on purchase patterns.

These insights can be directly integrated into Dynamics 365 CRM to drive smarter decision-making.

5. Enable Real-Time Data Synchronization

Set up data refresh schedules: Ensure your data in Customer Insights is updated frequently.
Use Power Automate for real-time syncing: Configure automated workflows to update records in Dynamics 365 CRM whenever changes occur in Customer Insights.

6. Build Custom Visualizations with Power BI

Use Power BI to create rich dashboards that combine Customer Insights data with CRM data. Examples include:
- Customer segmentation analysis
- Sales performance metrics
- Customer journey tracking

7. Integrate with Marketing and Sales Tools

Connect Customer Insights with Dynamics 365 Marketing to deliver targeted campaigns.
Enable Sales Insights in Dynamics 365 CRM to give sales reps actionable recommendations during customer interactions.

Benefits of Integrating Customer Insights with Dynamics 365 CRM Online

1. Centralized Data for a Unified Customer View

Combining Customer Insights with Dynamics 365 CRM eliminates data silos and provides a holistic view of each customer, enabling better personalization.

2. Improved Customer Engagement

Personalized recommendations and insights empower sales and marketing teams to engage with customers more effectively.

3. AI-Powered Decision Making

With built-in AI models, organizations can predict customer behavior, reduce churn, and maximize lifetime value.

4. Increased Operational Efficiency

Automated workflows and real-time synchronization ensure that teams always have the latest data without manual intervention.

Advanced Use Cases

1. Event-Based Customer Journeys

Use real-time event triggers, like abandoned carts or website interactions, to automatically update Dynamics 365 CRM records and initiate follow-up actions.

2. Advanced Segmentation

Segment customers based on their behavior, preferences, and engagement history. Use these segments in targeted marketing campaigns.

3. Cross-Sell and Upsell Opportunities

Leverage AI-driven recommendations to identify products or services that a customer is likely to purchase next.

4. Customer Feedback Analysis

Integrate feedback from surveys (e.g., Microsoft Forms or third-party tools) into Customer Insights and display sentiment analysis in Dynamics 365 CRM.

Tools and Resources

1. Microsoft Power Platform

Use Power Automate and Power Apps to customize workflows and create apps that connect Customer Insights with Dynamics 365 CRM.

2. Azure Synapse Analytics

For advanced data processing and analytics, connect Customer Insights data with Azure Synapse Analytics.

3. Microsoft Learn and Documentation

Explore the official Customer Insights documentation to deepen your knowledge.

Calling Microsoft Dynamics 365 CRM Online APIs from External Applications

2025-01-24T03:42:00.004+09:00

If you’re working with Microsoft Dynamics 365 CRM Online, you’ve probably encountered situations where you need to integrate it with other applications like your website, custom web APIs, or tools like KingswaySoft, XrmToolBox, or Change Data Capture (CDC) tools. API integration can unlock incredible automation and data synchronization, but with great power comes a few headaches.

Let’s dive into how you can make API calls to your MS CRM Online system, what limits and challenges you need to be aware of, and how to avoid common pitfalls while following best practices.

How MS CRM Online API Calls Work

The Microsoft Dataverse Web API (formerly known as the Common Data Service API) is at the heart of connecting with MS CRM Online. It uses OData and supports CRUD (Create, Read, Update, Delete) operations for your CRM data.

Common Use Cases for CRM API Calls:

Website Integration: Pull customer data, update records, or submit forms directly to CRM.
Middleware Tools: Automate imports, data migration, or bulk updates using KingswaySoft or SSIS packages.
Data Sync with External Systems: Use APIs to sync CRM data with ERP, marketing tools, or third-party systems in near-real time.
Automation Tools: Tools like Power Automate or XrmToolBox to streamline operations without reinventing the wheel.

What Makes MS CRM Online API Calls Different?

Dynamics 365 CRM Online operates in the cloud, which means Microsoft enforces strict rules to ensure the stability of its infrastructure. These include:

Daily API Limits (Service Protection Limits):
Each user and tenant in MS CRM Online has a daily API call limit based on the licenses they’re using.
- For example, a Dynamics 365 Customer Service Enterprise license allows 40,000 daily API calls per user.
- These limits are shared across all applications making calls on behalf of a user or application.
Timeouts and Query Size Restrictions:
- The maximum request timeout is 2 minutes.
- API calls can fail if they try to retrieve too much data at once. Large datasets need to be retrieved in pages using $top and $skip.
Concurrency Limits:
- Too many concurrent calls from the same application or user can trigger throttling (HTTP 429 errors).
Authentication:
- CRM Online only supports OAuth 2.0 for authentication. No basic auth! This means you’ll need to register an app in Azure AD and obtain access tokens to make API calls.

Limitations You Need to Know About

Throttling (HTTP 429 Errors):
If you exceed API limits or send too many requests too quickly, Microsoft will throttle your app to ensure the CRM stays stable for all users. Throttling typically results in a “429 Too Many Requests” error.
Complex Queries Can Fail:
Using too many joins, nested filters, or retrieving large data sets can lead to timeout errors or performance issues.
Eventual Consistency:
Data changes made through the API might not be immediately available for reads, especially if you’re using background processes like workflows.
Security Role Restrictions:
Even if you have API access, the user or application making the call is still limited by their assigned security roles in CRM.

Best Practices for MS CRM Online API Calls

Optimize Your Queries:
- Only retrieve the data you need by using $select to specify columns and $filter to narrow down records. For example:
```
GET https://<your-org>.crm.dynamics.com/api/data/v9.2/accounts?$select=name,revenue
```
Use Pagination for Large Datasets:
- MS CRM Online supports server-side paging using the @odata.nextLink property in responses. This is crucial when dealing with more than 5,000 records.
Batch API Requests:
- Instead of making multiple single calls, use batch operations to group several requests into one. This reduces the number of API calls and improves efficiency.
Implement Retry Logic:
- Throttling is inevitable if you’re working at scale. Implement retry logic with exponential backoff when you encounter HTTP 429 errors.
Monitor API Usage:
- Use the Power Platform Admin Center to monitor API call consumption and identify heavy users or apps. This helps you stay ahead of limits.
Use Change Tracking for Incremental Data Sync:
- Instead of polling all records repeatedly, use Change Tracking in CRM to fetch only the records that have changed since the last sync.
Secure Your API Calls:
- Use HTTPS for all communications. Ensure Azure AD tokens are stored securely, and rotate client secrets regularly.

How to Monitor API Usage in MS CRM Online

Power Platform Admin Center:
Go to Admin Center > Analytics > Common Data Service (Dataverse) to see the API usage summary for your environment. You’ll get a breakdown of calls by user, application, and type.
Enable Logging:
Turn on the Plug-in Trace Log to track failed calls or performance bottlenecks.
Use Audit Logs:
Dynamics 365 allows you to track API interactions via the audit log. It’s particularly useful for troubleshooting data updates or failed requests.
Alerts for API Limits:
Set up alerts to notify you when usage approaches the daily API limit. This can prevent unexpected disruptions.

What to Do If You Exceed the Limit

Analyze Your Calls:
Use the Power Platform Admin Center to identify which users or applications are consuming the most API calls. Common culprits include poorly optimized workflows or data sync jobs.
Reduce API Calls:
- Replace frequent polling with Change Tracking or webhooks.
- Consolidate multiple small API calls into fewer, larger calls using batch operations.
Purchase Additional Capacity:
If you’re regularly exceeding limits, you can buy extra capacity from Microsoft as an add-on.
Temporarily Slow Down Integrations:
Adjust schedules for non-critical jobs or integrations to avoid peak times.

How to Monitor API Usage from the Microsoft Power Platform Admin Center

One of the best ways to keep an eye on your API usage in Dynamics 365 CRM Online is by leveraging the Microsoft Power Platform Admin Center. This portal provides real-time analytics and insights into API consumption for your environment. Here's how you can monitor your usage step by step:

Steps to Monitor API Usage in the Admin Center

Log in to the Power Platform Admin Center
- Go to Power Platform Admin Center.
- Use your admin credentials to log in. You’ll need global admin or system admin permissions to access detailed metrics.
Navigate to the Analytics Section
- On the left-hand navigation pane, click on Analytics and select Dataverse (formerly Common Data Service).
- Choose the Environment you want to monitor if you’re managing multiple environments (e.g., production, sandbox).
View API Usage Overview
- In the Dataverse Analytics dashboard, go to the Capacity or API Usage tab.
- This section shows:
  - Daily API Usage: A graph or table displaying how many API calls have been consumed by the environment.
  - Users and Applications: Breakdowns of which users or applications are generating the most API traffic.
  - Remaining API Capacity: See how close you are to hitting your daily API limits.
Filter by Time Period or User/Application
- Use filters to narrow down API usage by:
  - Specific Users
  - Applications (e.g., integrations like KingswaySoft, Power Automate flows)
  - A specific time period (e.g., daily, weekly).
Identify Problem Areas
- Look for patterns in API consumption. For example:
  - A user making excessive API calls due to misconfigured workflows.
  - An application like a middleware tool consuming more calls than expected.
- Drill down into specific calls to identify whether they are read-heavy or write-heavy.
Set Up Alerts (Optional)
- Currently, you cannot directly configure alerts from the admin center, but you can monitor daily API thresholds using Power BI dashboards or scripts. Microsoft may notify you by email if your usage consistently exceeds capacity.
Access Logs for Detailed Troubleshooting
- If you’re troubleshooting failures, you can enable and access:
  - Plug-in Trace Logs: Tracks issues with custom plugins or workflows that might be contributing to excessive API usage.
  - Audit Logs: Enables detailed tracking of API actions, including which records were updated or accessed.

Key Insights You Can Gather from the Admin Portal

Who or What Is Consuming the Most API Calls?
The analytics dashboard shows a breakdown of API usage by user and application. This helps you pinpoint whether the problem lies with a specific integration (like KingswaySoft) or a user's actions (e.g., running an overly complex advanced find).
Are You Approaching Your Daily API Limits?
The dashboard provides a visual representation of your daily API consumption and how much headroom you have left before hitting the limit.
Which API Calls Are Failing?
If certain API calls are failing, you can cross-reference your logs to determine the cause. Look out for throttling errors (HTTP 429) or misconfigured apps making unnecessary requests.

Tips for Effective Monitoring

Regularly Check the Dashboard
Make it a habit to check API usage in the admin center weekly or after deploying a new integration to catch issues early.
Set Thresholds for Heavy API Consumers
If you find that specific apps (e.g., Power Automate flows) or users consistently hit the limits, optimize their behavior by reducing frequency or batching operations.
Plan Capacity for Busy Periods
If you know your environment will experience high API demand (e.g., a data migration or bulk import), consider purchasing additional capacity in advance.

MS CRM Plugin Development: Real Talk from a Senior Dev

2024-12-28T01:06:00.002+09:00

Hey there, fellow CRM developers!

What The Heck Is A Plugin (And Why Should You Care)?

Think of plugins as your secret weapon in the CRM world. They're essentially .NET libraries that let you inject your own code into CRM's event pipeline. While Microsoft's marketing team might call them "extensibility points," I like to think of them as your chance to say "Hey CRM, let me handle this my way!"

The Real-World Use Cases 💡

Let me share some actual scenarios where plugins saved my bacon:

A client needed to validate complex pricing rules before saving opportunities (something Power Automate would choke on)
We had to sync data with an ancient ERP system that only spoke SOAP
Had to implement real-time fraud detection on lead creation
Needed to enforce business rules that would make a flowchart cry

Plugin Architecture: The Stuff That Matters 🏗️

Here's what you actually need to know:

public class YourAwesomePlugin : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        // This is where the magic happens
        var context = (IPluginExecutionContext)serviceProvider
            .GetService(typeof(IPluginExecutionContext));
        
        // Pro tip: Always log what you're doing
        var tracer = (ITracingService)serviceProvider
            .GetService(typeof(ITracingService));
        tracer.Trace("Starting the awesome stuff...");
        
        // Your business logic goes here
    }
}

When & Where to Use Plugins 🎯

Pre-validation: When you need to stop bad data before it ruins your day
Pre-operation: For modifying data before it hits the database
Post-operation: When you need to trigger additional actions after the main operation
Async: For anything that might take longer than a coffee break

Quick Tip: Event Pipeline Explained Without the Jargon

Think of it like a security checkpoint:

Pre-validation: The metal detector
Pre-operation: The passport check
Post-operation: The duty-free shopping
Async: The stuff that happens after you're already on the plane

🎯 Why Should You Care About Plugins?

Let's be real - while Power Automate is great for simple stuff, plugins are where the real magic happens. They're like your Swiss Army knife for all things CRM customization. I've used them for everything from complex transaction validations to integrating with legacy systems that make COBOL look modern.

🔍 Plugin Basics (The Stuff Everyone Pretends They Already Know)

First, let's get our heads straight about what a plugin actually is - it's a .NET class library that hooks into CRM's event pipeline. Think of it as your bouncer at the club, deciding what data gets in and what happens to it.

Here's something they don't tell you in the docs: choosing between synchronous and asynchronous execution isn't just about speed - it's about not getting angry calls from users when their screen freezes. Trust me, I learned this the hard way.

💡 Real-World Example: The Lead Assignment Nightmare

Let me share a war story. We had a client who needed leads automatically assigned based on complex criteria (region, product interest, lead score, and current sales rep workload). Here's the battle-tested solution:


public class SmartLeadAssignment : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        // Get the context and service objects
        var context = (IPluginExecutionContext)serviceProvider
            .GetService(typeof(IPluginExecutionContext));
        var service = ((IOrganizationServiceFactory)serviceProvider
            .GetService(typeof(IOrganizationServiceFactory)))
            .CreateOrganizationService(context.UserId);
        var tracingService = (ITracingService)serviceProvider
            .GetService(typeof(ITracingService));

        try
        {
            if (context.MessageName != "Create" || 
                context.PrimaryEntityName != "lead") return;

            var lead = (Entity)context.InputParameters["Target"];
            
            // Pro tip: Always check if the field exists!
            if (!lead.Contains("new_region") || 
                !lead.Contains("new_productinterest")) 
            {
                tracingService.Trace("Required fields missing");
                return;
            }

            var assignee = GetOptimalSalesRep(service, lead);
            if (assignee != Guid.Empty)
            {
                lead["ownerid"] = new EntityReference("systemuser", assignee);
            }
        }
        catch (Exception ex)
        {
            // Always log the full exception - future you will thank present you
            tracingService.Trace($"Error: {ex.ToString()}");
            throw new InvalidPluginExecutionException(
                "Error assigning lead. Check trace logs for details.", ex);
        }
    }
}

🎓 Pro Tips That Saved My Bacon

Always Use Early Returns
```
if (!context.InputParameters.Contains("Target")) return;
```
This prevents your plugin from running unnecessarily and saves precious CPU cycles.
Transaction Context Is Your Friend
```
if (!context.IsInTransaction) throw new InvalidPluginExecutionException();
```
This has saved me from duplicate processing more times than I can count.
Trace Everything (But Smart)
```
tracingService.Trace($"Processing {lead.Id} for region {region}");
```
Future you will buy present you a beer for this.

🚀 Deployment Like a Pro

Forget manually uploading DLLs (it's 2024, folks!). Here's my Azure DevOps pipeline that's saved hours of my life:

🔍 Debugging Like a Detective

When things go wrong (and they will), here's your survival kit:

Plugin Profiler is your best friend
Set up local debugging with the Plugin Registration Tool
Use conditional breakpoints for specific scenarios

⚠️ Common Pitfalls (Learn From My Pain)

Never, ever make HTTP calls in sync plugins
Always check for null before accessing entity attributes
Don't trust the cache - always verify your data
Remember: plugins have a 2-minute timeout (yes, even async ones)

🎯 Advanced Techniques

For the real ninjas out there:

Use IOrganizationService sparingly (it's expensive)
Implement caching for frequently accessed data
Consider using Early-Bound entities for better performance
Use QueryExpression instead of FetchXML for complex queries

Want to see how I handle multi-threading in async plugins? Drop a comment below, and I'll share my battle-tested patterns!

🐛 Live Debugging Like a Pro

Here's my tried-and-true debugging workflow:

Remote Debugging Setup


// Add this to your plugin constructor
if (!Debugger.IsAttached && Debugger.Launch())
{
    DebuggerBreak();
}

Structured Logging Pattern


public void Execute(IServiceProvider serviceProvider)
{
    var tracer = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
    var context = new PluginTraceContext(tracer);
    
    context.Log($"Starting plugin execution for {context.MessageName}");
    try
    {
        // Your logic here
        context.LogObject("Input parameters", context.InputParameters);
    }
    catch (Exception ex)
    {
        context.LogException(ex);
        throw;
    }
}

🚨 Real Production Issues I've Faced (And How to Fix Them)

The Infinite Loop Nightmare


// Check if the plugin triggered itself
if (context.Depth > 1) return;

Memory Leaks in Async Plugins


using var serviceFactory = (IOrganizationServiceFactory)serviceProvider
    .GetService(typeof(IOrganizationServiceFactory));
using var service = serviceFactory.CreateOrganizationService(null);

Deadlocks in Transaction Processing


// Always use optimistic concurrency
entity.RowVersion = currentRowVersion;

📊 Production Monitoring That Actually Works


// Custom telemetry wrapper
public class PluginTelemetry : IDisposable
{
    private readonly Stopwatch _timer;
    private readonly ITracingService _tracer;
    
    public PluginTelemetry(ITracingService tracer)
    {
        _tracer = tracer;
        _timer = Stopwatch.StartNew();
    }
    
    public void Dispose()
    {
        _timer.Stop();
        _tracer.Trace($"Execution time: {_timer.ElapsedMilliseconds}ms");
    }
}

🌐 Extending with Web APIs (The Smart Way)

When plugins just won't cut it:


[RoutePrefix("api/v1/crm")]
public class CrmExtensionController : ApiController
{
    [HttpPost]
    [Route("bulkupdate")]
    public async Task<IHttpActionResult> BulkUpdateRecords([FromBody] BulkUpdateRequest request)
    {
        using var client = new CrmServiceClient(ConfigurationManager
            .ConnectionStrings["CRM"].ConnectionString);
            
        // Process in batches of 1000
        foreach (var batch in request.Records.Chunk(1000))
        {
            await ProcessBatchAsync(client, batch);
        }
        
        return Ok();
    }
}

💡 The Async Plugin Survival Guide

When to use async:

External API calls
Batch processing
Email notifications
File operations

Pro tip: Always implement retry logic:


private async Task ExecuteWithRetryAsync(Func<Task> operation)
{
    var policy = Policy
        .Handle<Exception>()
        .WaitAndRetryAsync(3, retryAttempt => 
            TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)));
            
    await policy.ExecuteAsync(operation);
}

Production-Ready Base Plugin Class

Here's my battle-tested base class that's saved countless hours:


public abstract class PluginBase : IPlugin
{
    private readonly string _unsecureConfig;
    private readonly string _secureConfig;

    protected PluginBase(string unsecureConfig = null, string secureConfig = null)
    {
        _unsecureConfig = unsecureConfig;
        _secureConfig = secureConfig;
    }

    public void Execute(IServiceProvider serviceProvider)
    {
        var context = (IPluginExecutionContext)serviceProvider
            .GetService(typeof(IPluginExecutionContext));
        var factory = (IOrganizationServiceFactory)serviceProvider
            .GetService(typeof(IOrganizationServiceFactory));
        var tracer = (ITracingService)serviceProvider
            .GetService(typeof(ITracingService));
        
        var service = factory.CreateOrganizationService(context.UserId);

        try
        {
            // Performance tracking
            using var performance = new PerformanceTracker(tracer);
            
            ExecutePluginLogic(new PluginContext
            {
                Context = context,
                Service = service,
                TracingService = tracer,
                UnsecureConfig = _unsecureConfig,
                SecureConfig = _secureConfig
            });
        }
        catch (Exception ex)
        {
            tracer.Trace($"❌ Error: {ex}");
            throw new InvalidPluginExecutionException(
                $"Plugin failed: {GetType().Name}", ex);
        }
    }

    protected abstract void ExecutePluginLogic(PluginContext context);
}

public class PluginContext
{
    public IPluginExecutionContext Context { get; set; }
    public IOrganizationService Service { get; set; }
    public ITracingService TracingService { get; set; }
    public string UnsecureConfig { get; set; }
    public string SecureConfig { get; set; }
}

🔐 Securing Your Plugin Configuration

Never hardcode sensitive stuff! Here's how to handle configs properly:


public class LeadScoringPlugin : PluginBase
{
    public LeadScoringPlugin(string unsecureConfig, string secureConfig) 
        : base(unsecureConfig, secureConfig)
    {
    }

    protected override void ExecutePluginLogic(PluginContext context)
    {
        var config = JsonConvert.DeserializeObject<ScoringConfig>(
            context.SecureConfig);
            
        context.TracingService.Trace($"Using API key: ***{
            config.ApiKey.Substring(config.ApiKey.Length - 4)}");
    }
}

🚀 Spkl Plugin Registration - The Right Way

First, your spkl.json:


{
  "plugins": [
    {
      "solution": "YourSolution",
      "assemblypath": "bin\\Debug\\YourPlugin.dll",
      "classRegex": ".*Plugin$",
      "excludePluginSteps": true
    }
  ]
}

deployment-config.json for different environments:


{
  "dev": {
    "server": "https://dev.crm.dynamics.com",
    "solution": "YourSolution_1_0_0_1",
    "secureConfiguration": {
      "LeadScoringPlugin": {
        "ApiKey": "dev_api_key_here"
      }
    }
  },
  "prod": {
    // Production config
  }
}

🎯 Pro Tips for Spkl

Version Control:


# Never commit secrets!
deployment-config.json
# Keep template
deployment-config.template.json

Automated Registration:


# Register plugins
spkl plugins [path] 

# Update specific plugin
spkl plugin [path] -name YourPlugin

Debug Settings:


<!-- .spkl.json -->
<setting name="debug" value="true" />

🔍 Real-World Example: Putting It All Together


public class CustomerValidationPlugin : PluginBase
{
    private readonly ValidationSettings _settings;

    public CustomerValidationPlugin(string unsecureConfig, string secureConfig) 
        : base(unsecureConfig, secureConfig)
    {
        _settings = JsonConvert.DeserializeObject<ValidationSettings>(
            unsecureConfig);
    }

    protected override void ExecutePluginLogic(PluginContext pluginContext)
    {
        var entity = (Entity)pluginContext.Context.InputParameters["Target"];
        
        // Use config settings
        if (_settings.EnableStrictValidation)
        {
            // Validation logic here
        }
        
        pluginContext.TracingService.Trace(
            $"Validation completed with rules: {_settings.RuleSet}");
    }
}

🔑 Critical Things Every D365 Plugin Dev Should Know

Thread Safety & Context


// Always use thread-safe collections
private static readonly ConcurrentDictionary<string, object> Cache = 
    new ConcurrentDictionary<string, object>();

// Check execution context
if (context.Depth > 1) return; // Prevent recursive loops

Performance Optimization


// Batch your requests
var multipleRequest = new ExecuteMultipleRequest
{
    Settings = new ExecuteMultipleSettings
    {
        ContinueOnError = false,
        ReturnResponses = true
    },
    Requests = requests.ToArray()
};

Error Handling Best Practices


try
{
    // Your logic
}
catch (FaultException<OrganizationServiceFault> ex)
{
    // Handle CRM-specific errors
    tracer.Trace($"Error Code: {ex.Detail.ErrorCode}");
}
catch (TimeoutException ex)
{
    // Handle timeouts gracefully
    throw new InvalidPluginExecutionException(
        "Operation timed out. Please try again.", ex);
}

Common Gotchas to Avoid

Plugin Isolation
- Don't share static state between plugin instances
- Avoid file system operations
- Never store sensitive data in static variables
Transaction Management


// Check if you're in a transaction
if (!context.IsInTransaction)
{
    throw new InvalidPluginExecutionException(
        "This operation must be part of a transaction.");
}

Cache Usage


// Implement proper caching
private static readonly MemoryCache Cache = new MemoryCache(
    new MemoryCacheOptions
    {
        SizeLimit = 1024
    });

// Use cache with expiration
Cache.Set(key, value, TimeSpan.FromMinutes(5));

Advanced Techniques

Custom Actions Integration


public class CustomActionPlugin : PluginBase
{
    protected override void ExecutePluginLogic(PluginContext context)
    {
        if (context.Context.MessageName != "my_customaction")
            return;
            
        var parameters = context.Context.InputParameters;
        // Process custom action
    }
}

Bulk Operation Handling


// Handle bulk operations efficiently
private async Task ProcessBulkAsync(
    IOrganizationService service, 
    List<Entity> entities)
{
    var tasks = entities
        .Select(entity => Task.Run(() => ProcessSingle(service, entity)));
    await Task.WhenAll(tasks);
}

Performance Metrics to Monitor

Plugin execution time
Database calls per operation
Memory usage patterns
Exception rates


public class PerformanceMetrics
{
    private readonly Stopwatch _timer = new Stopwatch();
    private int _dbCalls = 0;
    
    public void TrackDatabaseCall()
    {
        Interlocked.Increment(ref _dbCalls);
    }
}

Final Words of Wisdom

Always test with large datasets
Plan for failure scenarios
Keep security at the forefront
Document your assumptions
Use code reviews religiously

🔚 Wrapping Up

Remember: a good plugin is like a good referee - it does its job without anyone noticing. Keep it simple, keep it fast, and always, always test in a sandbox first.

#MSDynamics #CRMDevelopment #Plugins #DotNet #RealTalk

Will AI Really Replace Software Engineers? Let's Talk About Devin

2024-12-28T00:10:00.004+09:00

Hey there, fellow developers! 👋 I've been deep in the trenches of software engineering for years, and let me tell you - the buzz around Devin, Cognition AI's new AI engineer, has gotten me thinking about our future in tech.

The AI Engineer Next Door

Remember when GitHub Copilot first dropped and everyone lost their minds? Well, Devin is like Copilot's overachieving cousin who went to Stanford. This AI doesn't just complete your code - it builds entire systems from scratch. We're talking requirements analysis, coding, testing, debugging, and deployment. Pretty wild, right?

But here's the thing - I'm not updating my LinkedIn to "Former Software Engineer" just yet. Here's why.

The Real Impact (From Someone in the Trenches)

Last week, I spent three hours hunting down a missing semicolon. THREE. HOURS. Imagine if Devin handled that while I focused on architecting our new microservices structure? That's the future we're looking at.

Let me break down what I think this means for us:

The Good Stuff 🚀

No more mind-numbing debugging sessions
Automated code reviews that actually make sense
Tests that write themselves (hallelujah!)
More time for the fun stuff - designing systems and solving real problems

The Challenges We'll Face 🤔

Look, I've worked with enough tools to know nothing's perfect. Here's what keeps me up at night:

Security Concerns I mean, who's responsible when AI-generated code introduces a zero-day vulnerability? Your friendly neighborhood developer (that's you) will need to be extra vigilant.
The Learning Curve Remember how long it took to master Git? Now imagine learning to "prompt engineer" an AI developer. It's a whole new skill set.
Code Quality Control Sure, Devin can code. But can it understand why we shouldn't use that fancy new framework just because it's trending on Twitter?

New Opportunities (Not Just Buzzwords)

Here's something exciting - I'm seeing new roles pop up in job boards:

AI Development Orchestrators (fancy title for people who speak both human and AI)
Technical Ethics Officers (because someone needs to make sure the AI plays nice)
AI-Human Bridge Architects (yes, that's actually a thing now)

Personal Experience Corner 💡

Last month, I experimented with AI coding assistants on a personal project. The result? I built in two weeks what would've taken two months. But - and this is crucial - I was still the one making the important decisions. The AI was like having a super-smart intern who never needs coffee breaks.

What This Means For Your Career

Stop learning every new JavaScript framework that drops (I said what I said). Instead:

Master system design principles
Get comfortable with AI tools
Develop your architectural thinking
Build strong communication skills (AI still sucks at client meetings)

Pro Tips from the Field 🎯

Start small - use AI for code review first
Document everything (your future self will thank you)
Always verify AI-generated code
Keep learning, but focus on principles over syntax

The Future Is Actually Pretty Cool

You know what's better than being replaced by AI? Having AI handle the boring stuff while we focus on innovation. It's not about surviving the AI revolution - it's about thriving in it.

Let's Talk!

I'm curious - what's your take on all this? Have you worked with any AI coding tools? Drop your thoughts in the comments below, or hit me up on Twitter @chamrairesh

P.S. If you're worried about AI taking your job, remember: they still can't explain to clients why their "small change" will take two weeks to implement. That's job security right there!

Keep coding, keep learning, and maybe give Devin a chance to handle your next debugging session. Trust me, your sanity will thank you.

#SoftwareEngineering #AI #TechFuture #DevLife #CodingWithAI

Importing Data for Multi-Select Option Sets in MS CRM using Excel Online

2024-12-17T02:02:00.001+09:00

Importing data into multi-select option sets in Microsoft Dynamics CRM can be challenging when using the standard data import functionality. The step-by-step guide below will help you successfully import data using the Excel Online out-of-the-box (OOB) functionality while avoiding common issues

Why Use a Template for Data Import?

Multi-select option sets allow you to assign multiple values to a single field in CRM. However, this flexibility comes with a challenge: ensuring data consistency during imports. Using a predefined blank template ensures the proper structure and formatting of your data.

Step 1: Use the Blank View Template

To make importing data simpler, you could create a special blank view template designed for data import. Here’s what you need to know:

What Is the Blank View?
This CRM view is a predefined structure with all the necessary columns for data import, but no data filled in.
Why Keep It Blank?
It’s good to leave this view empty so it serves as a clean template. If populated, it may display existing data, defeating its purpose.

Step 2: Export the Template

Open the blank view in MS CRM.
Export the view to Excel. This exported file becomes your working template for data import.

💡 Tip: Always double-check that the view is blank before exporting it.

Step 3: Fill in the Template

Once you have the template:

Open the exported Excel file on your computer.
Carefully enter the data you wish to import, ensuring all fields match the required format.
For multi-select option sets, separate multiple values with a semicolon (;). For example:

Option1; Option2; Option3

✅ Pro Tip: Accuracy is key. Mistakes in formatting may cause import errors.

Step 4: Open Excel Online in CRM

Back in CRM, follow these steps:

Navigate to the same blank view you used earlier.
Click the three dots (···) in the toolbar, then select Open in Excel Online.

This will allow you to edit the data directly in the CRM environment.

Step 5: Copy and Paste Your Data

Open your completed Excel template.
Copy the filled data from your file.
Paste it into the Excel Online sheet opened from CRM.

⚠️ Important: Use a semicolon (;) as the separator for multi-select option sets. If any other delimiter is used, the import process will fail.

Step 6: Save and Track Progress

Once the data is pasted, save your changes in Excel Online.
The CRM system will automatically start the import process.
Track the import progress directly in CRM by navigating to the Imports section.

Import Process

Flowchart to visualize the entire import workflow:

Benefits of This Approach

Consistency: Using a blank template ensures that all required columns are present and properly formatted.
Accuracy: Direct edits in Excel Online minimize errors during upload.
Efficiency: Tracking progress in CRM helps identify and resolve issues quickly.

Always remember to use semicolons for separating values, double-check your formatting, and save your work frequently to ensure a smooth import experience.

Happy importing! 🚀

Applying the Single Responsibility Principle (SRP)

2024-05-01T02:49:00.004+09:00

Applying the Single Responsibility Principle (SRP) in Report Processing

The Single Responsibility Principle (SRP) is a foundational concept in object-oriented programming that advocates for classes to have only one reason to change. This principle promotes modular, readable, and maintainable code by ensuring that each class or module encapsulates only one responsibility or behavior.

Example Scenario

In our scenario, we have a reporting system responsible for processing various report items asynchronously. To uphold the SRP, we aim to refactor our report processing logic into distinct components that each fulfill a specific responsibility, such as data encapsulation, processing orchestration, and logging.

Implementation

1. ReportItem Class

public class ReportItem
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public ReportItemStatus Status { get; set; }
    public string ErrorMessage { get; set; }
}

The ReportItem class represents a report item entity, encapsulating properties like Id, Name, Status, and ErrorMessage. This class is solely responsible for managing data related to a report item.

2. ReportProcessor Class

public class ReportProcessor
{
    private readonly IReportService _reportService;
    private readonly ILogger _logger;

    public ReportProcessor(IReportService reportService, ILogger logger)
    {
        _reportService = reportService;
        _logger = logger;
    }

    public async Task ProcessReportItemAsync(Guid itemId)
    {
        var item = await _reportService.GetReportItemAsync(itemId);

        if (item == null || item.Status != ReportItemStatus.Pending)
        {
            _logger.LogWarning($"Report item with ID {itemId} is not available for processing.");
            return;
        }

        try
        {
            _logger.LogInformation($"Processing report item: {item.Name}");

            item.Status = ReportItemStatus.Processing;
            await _reportService.UpdateReportItemAsync(item);

            await SimulateReportProcessingAsync(item);

            item.Status = ReportItemStatus.Completed;
            await _reportService.UpdateReportItemAsync(item);

            _logger.LogInformation($"Report item processed successfully: {item.Name}");
        }
        catch (Exception ex)
        {
            item.Status = ReportItemStatus.Failed;
            item.ErrorMessage = ex.Message;
            await _reportService.UpdateReportItemAsync(item);

            _logger.LogError($"Failed to process report item: {item.Name}. Error: {ex.Message}");
        }
    }

    private async Task SimulateReportProcessingAsync(ReportItem item)
    {
        // Simulate report processing
    }
}

The ReportProcessor class is dedicated to processing report items asynchronously. It utilizes an injected IReportService for data retrieval and updates and an ILogger for logging processing outcomes and errors. This class demonstrates a clear responsibility focused on orchestrating the report processing workflow.

3. Interfaces

public interface IReportService
{
    Task<ReportItem> GetReportItemAsync(Guid itemId);
    Task UpdateReportItemAsync(ReportItem item);
}

public interface ILogger
{
    void LogInformation(string message);
    void LogWarning(string message);
    void LogError(string message);
}

Interfaces like IReportService and ILogger define contracts for interacting with report data and logging actions, respectively. Leveraging interfaces promotes loose coupling, facilitates dependency injection for enhanced testability, and enables flexibility in swapping implementations.

Conclusion

In this example, we've refactored our report processing logic to adhere to the Single Responsibility Principle (SRP). Each class (`ReportItem`, `ReportProcessor`) embodies a distinct responsibility, such as data encapsulation or processing orchestration. Meanwhile, interfaces (`IReportService`, `ILogger`) facilitate decoupling and abstraction, fostering maintainable and extensible code.
By applying SRP, we've established a modular and maintainable design where each component is dedicated to a specific aspect of report processing. This design approach enhances code clarity, adaptability to changing requirements, and adherence to best practices in software design and architecture. Ultimately, embracing SRP contributes to a cleaner and more manageable codebase, promoting robustness and scalability in our reporting system.

Unveiling the Power of Microsoft CRM Managed Solutions

2024-02-07T04:37:00.002+09:00

In the fast-paced world of CRM and app development, Microsoft consistently shines with its innovative solutions. One standout is the Managed Solution in Microsoft CRM, a game-changer for customization and deployment. This guide dives into the details of MS CRM Managed Solutions and Solution Layers, highlighting their importance and the latest updates related to Power Apps.

Managed Solutions and Their Key Components

Managed Solutions are essential for packaging customizations and configurations, making it easier to bundle, distribute, and deploy components across different environments. Key components within Managed Solutions include:

Entities: Custom entities that define data structures, tailored to specific customer or industry needs.
Processes and Workflows: Automation tools that ensure standardized operations and boost efficiency.
Forms and Views: Customizable user interface elements for a seamless CRM experience.
Web Resources and Scripts: Enhancements for visual and functional aspects using images, scripts, and stylesheets.

Solution Layers: Structuring Customizations with Precision

Solution Layers are a core concept in Managed Solutions, providing a structured approach to customization. By organizing components into layers like Base, Sales, and Service, developers can create solutions that are easily extended, modified, or replaced without affecting core functionality.

Example Scenario

Imagine XYZ Corp implementing a Managed Solution in their CRM environment. This solution includes custom entities for tracking customer feedback, automated workflows for managing support tickets, and tailored forms for an intuitive user interface. Solution Layers help categorize these customizations, ensuring a systematic and organized deployment.

Latest Changes and Power App Integration

Microsoft's commitment to innovation has brought significant updates to Power Apps within the CRM ecosystem. Notable enhancements include:

Unified Interface Enhancements: Major improvements to the Unified Interface for Power Apps and Dynamics 365 applications, focusing on performance optimization and enhanced customization capabilities.
Dataverse Integration: Deeper integration of Dataverse, the data platform for Power Apps, streamlining data management with a unified data schema for both Power Apps and CRM customizations.
Power Apps Component Framework (PCF) Advancements: Empowering developers to create richer and more interactive customizations with improved capabilities and extensibility.

Updating Managed Solutions: A Step-by-Step Guide

Applying the Upgrade or Update in the Target Environment

Development Environment Preparation: Open the unmanaged solution and customize components as needed.
Version Incrementation: Increment version numbers when exporting the solution as a managed solution.
Solution Update: Sign into Power Apps, select the target environment, and navigate to "Solutions" in the left navigation pane.
Solution Action Options: Options include "Upgrade," "Stage for Upgrade," and "Update," each serving specific purposes in the update process.
Post Import Actions: Decide on post-import actions, such as enabling plug-in steps and flows included in the solution.
Import Confirmation: Wait for the import to complete and review the results.

Advanced Insights: Version Numbers, Component Removal, and Customization Overwrites

Understanding Version Numbers for Updates: A solution's version follows the major.minor.build.revision format. Updates must have higher version numbers than the parent solution.
Removing a Managed Component: Options include upgrading the solution in the development environment or deleting the managed solution, each serving specific use cases.
Overwrite Customizations Option: Use caution with the "Overwrite Customizations" option, as it can impact unmanaged customizations on components.

Patching and Deployment

Patching is a crucial aspect of maintaining and updating Managed Solutions. Here’s how you can effectively manage patches:

Creating Patches: Patches allow you to make incremental updates to a solution without modifying the entire solution. They include only the changes to entities and related assets
1
.
Applying Patches: Patches can be applied to both managed and unmanaged solutions. They must have the same major and minor version numbers as the parent solution but a higher build and release number
2
.
Cloning Solutions: When you need to roll up all patches into a new version, you can clone the solution. This creates a new version that includes all the patches, ensuring a clean and updated deployment
2
.

Conclusion

Navigating the complex world of Microsoft CRM Managed Solutions requires a comprehensive approach. By understanding the core components, leveraging Solution Layers, and staying updated on the latest changes related to Power Apps, businesses can ensure a smooth and efficient customization deployment in their CRM environments. Always exercise caution and follow best practices, especially when updating solutions, managing dependencies, or overwriting customizations. The power to tailor CRM environments to specific needs lies with those who master the nuances of Managed Solutions and their evolving capabilities.

Additional Recommendations: Use a single publisher for all solutions across environments.

Mastering Dependency Injection in C# and ASP.NET Web API: A Comprehensive Guide

2024-02-07T04:12:00.005+09:00

Hey there! 👋 Let's dive into Dependency Injection (DI) in a way that actually makes sense. No buzzwords, just practical knowledge you can use today.

Why Should You Care About DI?

Before we dive into the code, let's talk about why DI matters in real-world development:

Ever inherited a codebase where changing one thing breaks everything else?
Spent hours mocking dependencies for unit tests?
Struggled to swap implementations for different environments?

DI helps solve these headaches. Let's see how.

Starting Simple: The Basics

Let's build this up step by step with a real-world scenario. Imagine you're building an e-commerce API:

// Before DI - The Painful Way 😫
public class OrderController
{
    private readonly OrderService _orderService = new OrderService(
        new PaymentProcessor(
            new PaymentGateway()
        )
    );
}

// After DI - The Clean Way 😎
public class OrderController
{
    private readonly IOrderService _orderService;

    public OrderController(IOrderService orderService)
    {
        _orderService = orderService;
    }
}

Real-World DI Patterns

The Constructor Injection Pattern (Your Go-To Choice)

This is what you'll use 90% of the time:


public class OrderProcessor
{
    private readonly IPaymentGateway _paymentGateway;
    private readonly IOrderRepository _orderRepository;
    private readonly ILogger<OrderProcessor> _logger;

    public OrderProcessor(
        IPaymentGateway paymentGateway,
        IOrderRepository orderRepository,
        ILogger<OrderProcessor> logger)
    {
        _paymentGateway = paymentGateway;
        _orderRepository = orderRepository;
        _logger = logger;
    }

    public async Task ProcessOrder(Order order)
    {
        _logger.LogInformation($"Processing order {order.Id}");
        // Your business logic here
    }
}

Service Lifetimes Explained Simply

Think of services like employees in a store:

public void ConfigureServices(IServiceCollection services)
{
    // The Store Manager (Singleton) - One person, there all day
    services.AddSingleton<IStoreConfig, StoreConfig>();
    
    // The Cashier (Scoped) - One per customer
    services.AddScoped<IOrderProcessor, OrderProcessor>();
    
    // The Shopping Assistant (Transient) - New one for each task
    services.AddTransient<IProductValidator, ProductValidator>();
}

Testing Made Easy

Here's how DI makes testing a breeze:

public class OrderProcessorTests
{
    [Fact]
    public async Task ProcessOrder_WithValidPayment_Succeeds()
    {
        // Arrange
        var mockPaymentGateway = new Mock<IPaymentGateway>();
        mockPaymentGateway.Setup(x => x.ProcessPayment(It.IsAny<decimal>()))
            .ReturnsAsync(true);

        var processor = new OrderProcessor(
            mockPaymentGateway.Object,
            Mock.Of<IOrderRepository>(),
            Mock.Of<ILogger<OrderProcessor>>()
        );

        // Act
        await processor.ProcessOrder(new Order { Amount = 100m });

        // Assert
        mockPaymentGateway.Verify(x => x.ProcessPayment(100m), Times.Once);
    }
}

Advanced Patterns (When You Need Them)

The Decorator Pattern (Adding Behavior)

Perfect for adding caching, logging, or validation:

public class CachingOrderService : IOrderService
{
    private readonly IOrderService _inner;
    private readonly ICache _cache;

    public CachingOrderService(IOrderService inner, ICache cache)
    {
        _inner = inner;
        _cache = cache;
    }

    public async Task<Order> GetOrder(int id)
    {
        var cacheKey = $"order_{id}";
        if (_cache.TryGet(cacheKey, out Order order))
            return order;

        order = await _inner.GetOrder(id);
        _cache.Set(cacheKey, order);
        return order;
    }
}

Factory Pattern (When You Need Dynamic Creation)


public class PaymentProcessorFactory
{
    private readonly IServiceProvider _services;

    public PaymentProcessorFactory(IServiceProvider services)
    {
        _services = services;
    }

    public IPaymentProcessor Create(PaymentMethod method)
    {
        return method switch
        {
            PaymentMethod.CreditCard => _services.GetRequiredService<ICreditCardProcessor>(),
            PaymentMethod.PayPal => _services.GetRequiredService<IPayPalProcessor>(),
            _ => throw new NotSupportedException($"Payment method {method} not supported")
        };
    }
}

Common Pitfalls (Learn From Our Mistakes)

❌ Circular Dependencies


// Don't do this!
public class ServiceA
{
    public ServiceA(ServiceB b) { }
}

public class ServiceB
{
    public ServiceB(ServiceA a) { }
}

// Do this instead
public class ServiceA
{
    private readonly IServiceProvider _services;
    private ServiceB _b;

    public ServiceA(IServiceProvider services)
    {
        _services = services;
    }

    private ServiceB B => _b ??= _services.GetRequiredService<ServiceB>();
}

❌ Disposing Services Incorrectly

// Remember to dispose scoped services!
public async Task ProcessOrders()
{
    using var scope = _services.CreateScope();
    var processor = scope.ServiceProvider.GetRequiredService<IOrderProcessor>();
    await processor.ProcessPendingOrders();
}

Pro Tips 🚀

Keep services focused (Single Responsibility Principle)
Use constructor injection by default
Register services in feature modules for better organization
Always dispose of scoped services
Use middleware for cross-cutting concerns

Wrapping Up

DI isn't just a pattern – it's a tool that makes your life easier. Start with constructor injection, use scoped services wisely, and remember: if a class needs to create its dependencies, it's probably doing too much.

Resolving CRM Online LINQ Query Failures: A Deep Dive into a Strange SQL Error

2024-01-02T20:05:00.001+09:00

Introduction: In the world of Microsoft Customer Relationship Management (CRM) online systems, encountering errors during LINQ queries can be a frustrating experience. Recently, our team faced a particularly perplexing issue where a LINQ Query failed, throwing an enigmatic SQL error. The error message provided little information, leaving us scratching our heads. In this blog post, we’ll share our journey in troubleshooting and ultimately resolving this issue.

The Error: Here’s the error message that had us stumped:

{
  "Message": "An error has occurred.",
  "ExceptionMessage": "Sql error: Generic SQL error. CRM ErrorCode: -2147204784 Sql ErrorCode: -2146232060 Sql Number: 207",
  "ExceptionType": "System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=9.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]"
}

Initial Investigation: Our first step was to reach out to the Microsoft support team for assistance. After providing them with the network trace and Fiddler log, they uncovered an interesting lead — an error related to customer insight fields. Intrigued, we dove deeper into our CRM system.

Discovery: Upon scrutinizing the CRM fields and relationships, we discovered that the mentioned fields did exist, but here’s the catch — they were no longer in use. Puzzled by this revelation, we recalled a past instance where we had created a customer insight instance for testing purposes. Subsequently, we reset (deleted) it using Microsoft’s recommended method.

However, it seems that not everything was cleanly deleted. Some fields and relationships lingered behind, causing a ripple effect leading to the LINQ Query failure.

Bug Identified: This anomaly in the deletion process hinted at a bug related to the interaction between customer insights and CRM links. It became apparent that when encountering the cryptic SQL error mentioned earlier, the first course of action should be to check for unused fields or relationships.

Resolution: Armed with this knowledge, we undertook a systematic cleanup process. We meticulously combed through our CRM system, identifying and deleting any remnants of fields or relationships that were no longer in use. Once this cleanup was completed, we re-executed the LINQ Query, and lo and behold, the error vanished.

Conclusion: The journey from a vague SQL error to a resolution taught us the importance of thorough system cleanup, especially when dealing with interconnected modules like customer insights and CRM. If you ever encounter a LINQ Query failure with a similar error, consider this blog post as your guide to troubleshooting and resolving the issue.

Remember, the devil is in the details — sometimes, the remnants of past testing can come back to haunt your queries. Happy coding

How to Become a CRM Developer for Microsoft Dynamics 365 Online

2022-12-25T05:07:00.004+09:00

The demand for Microsoft Dynamics 365 Online developers continues to grow as more organizations adopt cloud-based CRM solutions. This comprehensive guide will help you navigate your journey to becoming a successful Dynamics 365 developer.

Essential Programming Foundation

Start by mastering core programming concepts and languages:

Learn computer science fundamentals through platforms like:
- Coursera (https://www.coursera.org/)
- Khan Academy (https://www.khanacademy.org/)
- Code Academy (https://www.codecademy.com/)
- freeCodeCamp (https://www.freecodecamp.org/)
Focus on C# and .NET development using resources such as:
- Microsoft Visual Studio (https://visualstudio.microsoft.com/)
- C# Fundamentals on Pluralsight (https://www.pluralsight.com/courses/csharp-fundamentals)
- C# Programming Yellow Book (http://www.csharpcourse.com/)
- Microsoft Learn (https://learn.microsoft.com/en-us/dotnet/csharp/)

Dynamics 365 Expertise

Develop specialized knowledge in:

Core CRM concepts
Dynamics 365 platform architecture
Power Platform capabilities
Common Data Service (Dataverse)
Business process automation

Resources for Dynamics 365:

Microsoft Dynamics 365 documentation (https://docs.microsoft.com/en-us/dynamics365/)
Microsoft Power Platform Learning Path (https://learn.microsoft.com/en-us/power-platform/)
Dynamics 365 Community Forums (https://community.dynamics.com/)

Practical Experience

Gain hands-on experience through:

Setting up a free trial environment
Building sample applications
Contributing to open-source projects
Participating in hackathons
Taking on freelance projects

Professional Development

Enhance your career prospects by:

Earning Microsoft certifications:
- Microsoft Certified: Dynamics 365 Developer Associate
- Power Platform Developer Associate
Joining professional communities:
- Dynamics 365 User Group (https://dynamiccommunities.com/dynamics-365-crm)
- Stack Overflow (https://stackoverflow.com/)
- LinkedIn Dynamics 365 groups
Following industry resources:
- Microsoft Dynamics 365 blog (https://cloudblogs.microsoft.com/dynamics365/)
- Power Apps Community Blog (https://powerusers.microsoft.com/t5/Power-Apps-Community-Blog/bg-p/PowerAppsBlog)

Setting Up Your Development Environment

Get started with a trial version:

Visit dynamics.microsoft.com
Click "Try it now"
Choose "Try Dynamics 365 for free"
Complete registration with Microsoft account
Access development tools and resources

Personal Experience Building a CRM Solution

Here's my journey developing a custom CRM solution for a real estate agency:

The project involved creating a property management module within Dynamics 365. I started by analyzing the client's requirements and designing custom entities for properties, listings, and transactions. Using C#, I developed custom plugins for automated workflow triggers when properties changed status.

Key challenges included:

Integrating with third-party property listing APIs
Implementing complex business rules for commission calculations
Building a custom Power BI dashboard for sales analytics

This experience taught me the importance of understanding both technical aspects and business processes in CRM development.

Stay Current

The Dynamics 365 ecosystem evolves rapidly. Stay updated through:

Microsoft Release Plans
Technical documentation updates
Community events and webinars
Industry conferences
Online training platforms

Remember that becoming a successful Dynamics 365 developer requires continuous learning and practical application of skills. Start with small projects and gradually take on more complex challenges as you build your expertise.

Non-Technical Skills for CRM Developers

While technical expertise is crucial for a Microsoft Dynamics 365 developer, non-technical skills are equally important for long-term success. These skills enable developers to collaborate effectively, understand business needs, and deliver solutions that drive value.

1. Business Analysis Skills

Understanding the business processes and objectives of clients is key to building effective CRM solutions.

Learn to gather and analyze requirements.
Develop process flow diagrams.
Understand business workflows and automation needs.
Recommended resource: Business Analysis Fundamentals on Udemy (https://www.udemy.com/)

2. Problem-Solving Mindset

Every CRM project comes with unique challenges.

Develop critical thinking skills.
Learn to troubleshoot complex issues.
Approach problems systematically.

3. Communication Skills

Clear communication bridges the gap between technical teams and stakeholders.

Practice active listening.
Learn to explain technical concepts to non-technical audiences.
Improve documentation skills for requirements and technical designs.

4. Project Management Basics

Familiarity with project management methodologies ensures smooth project delivery.

Understand Agile and Scrum methodologies.
Learn to use tools like Jira, Trello, or Microsoft Project.
Recommended resource: Agile Fundamentals on Pluralsight (https://www.pluralsight.com/)

5. Time Management and Organization

CRM projects often involve multiple tasks and deadlines.

Prioritize tasks effectively.
Use tools like Microsoft To-Do or Asana for task management.
Set realistic timelines and track progress.

6. Customer Focus

Understanding end-users' needs helps in building user-friendly solutions.

Develop empathy for user challenges.
Gather feedback through user testing.
Prioritize customer satisfaction.

7. Adaptability and Continuous Learning

The tech landscape evolves quickly.

Stay open to learning new tools and updates.
Adapt to changing project requirements.
Attend webinars, training sessions, and conferences.

Becoming a Microsoft Power Platform Developer

The Microsoft Power Platform is a suite of low-code tools that enables the rapid development of custom business applications, automation of workflows, and insightful data analysis. As a CRM developer, proficiency in the Power Platform is invaluable for creating integrated and efficient solutions.

Understanding the Power Platform

The Power Platform comprises several key components:

Power Apps: Develop custom applications with minimal coding.
Power Automate: Automate workflows and business processes.
Power BI: Analyze data and create interactive reports.
Power Pages: Build low-code, responsive websites.

These tools are built on Microsoft Dataverse, providing a unified data platform for seamless integration.

Microsoft Learn

Steps to Become a Power Platform Developer

Learn the Fundamentals:
- Microsoft Learn: Offers comprehensive modules on Power Platform basics.
- Introduction to Microsoft Power Platform for Developers: Provides an overview tailored for developers.
  Microsoft Learn
Set Up a Developer Environment:
- Power Platform Developer Plan: Access free development environments to build and test solutions.
- How-To Guide: Instructions on creating a developer environment.
  Microsoft Learn
Master Dataverse:
- Dataverse Developer Guide: Learn about the underlying data platform for Power Apps.
  Microsoft Learn
Explore Fusion Development:
- Fusion Development: Combines low-code tools with traditional coding for enhanced solutions.
- Fusion Development eBook: In-depth resource on fusion development practices.
  Microsoft Learn
Enhance Application Lifecycle Management (ALM) Skills:
- Power Platform ALM Basics: Understand the essentials of managing application lifecycles.
- Power Platform CLI: Command-line interface for efficient development and deployment.
  Microsoft Learn
Stay Updated with Official Documentation:
- Power Platform Developer Documentation: Regularly updated resources and guides.
  Microsoft Learn

Additional Resources

Training Modules: Interactive learning paths for hands-on experience.
Community Forums: Engage with other developers to share knowledge and solutions.

By following these steps and utilizing the available resources, you can develop the skills necessary to become a proficient Microsoft Power Platform developer, enhancing your ability to create robust CRM solutions.

For a visual overview and additional insights, you might find the following video helpful:

Final Thoughts

A successful Dynamics 365 developer combines technical proficiency with strong interpersonal and analytical skills. By developing these non-technical competencies, you will not only build better CRM solutions but also foster stronger relationships with clients and team members.

Security Features in Microsoft Dynamics 365 (CRM) Online

2022-12-25T04:28:00.005+09:00

Microsoft Dynamics 365 (CRM) Online is a cloud-based customer relationship management platform that helps businesses manage their sales, marketing, and customer service activities. To ensure the security of the platform and the data stored on it, Dynamics 365 (CRM) Online offers a variety of security features.

1. Encryption: Dynamics 365 (CRM) Online uses SQL Transparent Data Encryption (TDE) to encrypt and decrypt data and log files in real time, helping to protect customer databases at rest. As of December 2017, Microsoft recommends securing the encryption keys used for TDE on the Azure Secure Vault (HSM). This allows you to generate and manage your own encryption keys, and upload them to an Azure Key Vault controlled by Microsoft.

2. Multi-Factor Authentication (MFA) or Two-Factor Authentication (2FA): MFA or 2FA is a security measure that requires an additional method of verifying your identity, such as a one-time code sent to your phone or a security app, in addition to your password. Dynamics 365 (CRM) Online includes basic MFA, but you may need to purchase Azure AD Premium licenses for additional MFA options.

3. Pen testing: Microsoft conducts server-level penetration testing to ensure the security of Dynamics 365 (CRM) Online. These tests are designed to identify and exploit vulnerabilities in the system, and the results are used to improve the security of the platform.

4. Data center security: Dynamics 365 (CRM) Online is hosted on Microsoft Azure, which has a number of security measures in place to protect the data centers that host the platform. These measures include physical security, network security, and data protection. Azure also undergoes regular security audits and assessments to ensure that it meets industry standards and regulations.

5. Compliance: Dynamics 365 (CRM) Online meets a number of industry and government standards and regulations, including GDPR, HIPAA, and ISO 27001. This helps to ensure that the platform is secure and compliant with relevant laws and regulations.

6. Data backup and recovery: Dynamics 365 (CRM) Online includes data backup and recovery capabilities to help protect against data loss. In the event of a data loss or disaster, you can restore your data from a backup to minimize the impact on your business.

7. Access control: Dynamics 365 (CRM) Online includes access control features to help you manage who has access to your data and what they can do with it. This includes role-based security, which allows you to assign different levels of access to different users or groups, and data visibility controls, which allow you to specify which data is visible to which users.

8. Activity logging: Dynamics 365 (CRM) Online includes activity logging to help you track changes to your data and identify any potential security issues. You can view the logs to see who made changes to your data and when, and use this information to help detect and prevent security breaches.

9. Security updates: It is important to keep your Dynamics 365 (CRM) Online instance and any associated apps up to date with the latest security updates to protect against vulnerabilities and threats. Microsoft regularly releases security updates for Dynamics 365 (CRM) Online to help protect against new threats and vulnerabilities.

For more information on the security of Microsoft Dynamics 365 (CRM) Online, visit the following links:

Migrate Dynamics CRM 365 Online to Dynamics CRM 365 On-Premise — Summary

2022-12-25T04:17:00.003+09:00

Migrating from Dynamics CRM 365 Online to Dynamics CRM 365 On-Premise can be a complex process, but it is often necessary for organizations that need to access data offline or comply with certain regulations. The migration process involves transferring data, configurations, and customizations from the cloud-based version to the on-premise version, which is installed and run on a local server.

The first step in the migration process is to prepare the on-premise environment by installing and configuring the Dynamics CRM server, setting up Active Directory, and preparing the SQL Server database. Next, data must be exported from the online version of Dynamics CRM using the Dynamics CRM Data Migration Manager. This tool allows users to select the data they want to export and specify a location for the exported files.

Once the data has been exported, it can be imported into the on-premise version of Dynamics CRM using the Import Data Wizard. This tool guides users through the process of mapping the data from the exported files to the appropriate fields in the on-premise version.

After the migration is complete, it is important to test the migrated data to ensure that it has been transferred correctly and that the on-premise version of Dynamics CRM is functioning properly. By following the steps outlined in this blog post and carefully planning and executing the migration process, organizations can successfully migrate from Dynamics CRM 365 Online to Dynamics CRM 365 On-Premise.

chamara iresh's Blog: Migrate Dynamics CRM 365 Online to Dynamics CRM 365 On-Premise

Migrate Dynamics CRM 365 On-Premise to CRM 365 Online - Summary

2022-12-25T03:58:00.005+09:00

There are several key differences between Dynamics 365 on-premises and Dynamics 365 online that organizations should consider when deciding which option is best for their needs. Some of the main differences include:

1. Deployment: Dynamics 365 on-premises is installed on an organization's own servers, while Dynamics 365 online is hosted in the cloud.

2. Maintenance and upgrades: With Dynamics 365 on-premises, organizations are responsible for managing and maintaining the system, including installing updates and patches. With Dynamics 365 online, Microsoft handles these tasks.

3. Scalability and performance: Dynamics 365 online is built on Azure, a cloud platform with a global network of data centers, which allows for better scalability and performance compared to on-premises systems.

4. Customization: With Dynamics 365 on-premises, organizations have more flexibility to customize the system to meet their specific needs. However, this customization can also increase the complexity and maintenance required for the system. Dynamics 365 online is more limited in terms of customization, but this can also make it easier to maintain and use.

5. Integration: Dynamics 365 online offers integration with other Microsoft cloud services such as Office 365 and Azure, which can be beneficial for organizations already using these services. Dynamics 365 on-premises can also be integrated with other systems, but this requires additional effort and resources.

6. Cost: The cost of Dynamics 365 on-premises depends on the number of users and the amount of customization required. In general, Dynamics 365 online is likely to be more cost-effective, especially for organizations with a large number of users.

When deciding whether to migrate to Dynamics 365 online, organizations should carefully consider their specific needs and requirements, including the level of customization required, the complexity of the system, and the resources available for maintenance and support. It may be helpful to consult with a Dynamics 365 partner or consultant to determine the best solution for your organization.

Refer below link for details information:

chamara iresh's Blog: Migrate Dynamics Dynamics CRM 365 On-Premise to CRM 365 Online

Unit Testing with FakeXrmEasy

2022-12-02T04:35:00.003+09:00

Making Unit Testing Easy with FakeXrmEasy

Hey there! Let's talk about making your Dataverse testing life easier with FakeXrmEasy. If you've been wrestling with unit tests for your Dynamics 365/Dataverse projects, you're in for a treat.

Why You'll Love FakeXrmEasy

Think of FakeXrmEasy as your personal Dataverse simulator. Instead of mocking every single service call (we've all been there, it's not fun), FakeXrmEasy gives you an in-memory database that just works. No more endless mocking – just write your tests and go!

Key Features

Complete simulation of Dataverse backend with in-memory database
Support for all query types:
- FetchXML
- QueryExpress
- QueryByAttribute
- CRM LINQ provider
Compatible with major test runners (xUnit, MSTest, NUnit)

Real-World Testing Example

Let's look at a practical example. Say you're updating contact records:

public class ContactTests : FakeXrmEasyTestsBase
{
    private readonly Contact _contact;

    public ContactTests() 
    {
        // Create a test contact - just like you would in real life
        _contact = new Contact
        {
            Id = Guid.NewGuid(),
            FirstName = "John",
            LastName = "Smith",
            EmailAddress1 = "john.smith@email.com"
        };
    }

    [Fact]
    public async Task Can_Update_Contact_Name_And_Email()
    {
        // Start with our test contact
        context.Initialize(_contact);

        // Let's update John's details
        var command = new UpdateContactCommand(service)
        {
            ContactId = _contact.Id,
            FirstName = "Jonathan",
            EmailAddress1 = "jonathan.smith@email.com"
        };
        await command.ExecuteAsync();

        // Did it work? Let's check!
        var updatedContact = context.CreateQuery<Contact>()
            .Where(c => c.Id == _contact.Id)
            .FirstOrDefault();

        Assert.Equal("Jonathan", updatedContact.FirstName);
        Assert.Equal("jonathan.smith@email.com", updatedContact.EmailAddress1);
    }
}

Here's the command that makes it happen:

public class UpdateContactCommand
{
    private readonly IOrganizationService _service;
    public Guid ContactId { get; set; }
    public string FirstName { get; set; }
    public string EmailAddress1 { get; set; }

    public UpdateContactCommand(IOrganizationService service)
    {
        _service = service ?? throw new ArgumentNullException(nameof(service));
    }

    public async Task ExecuteAsync()
    {
        var contact = new Contact
        {
            Id = ContactId,
            FirstName = FirstName,
            EmailAddress1 = EmailAddress1
        };

        await _service.UpdateAsync(contact);
    }
}

Quick Tips for Better Tests

Keep it simple - test one thing at a time
Only set up the data you need
Give your tests clear, descriptive names
Check the results right after your operation

Testing Queries Made Easy

Here's how you might test a query to find active contacts:


[Fact]
public void Find_Active_Contacts()
{
    // Set up some test contacts
    var contacts = new List<Contact>
    {
        new Contact { 
            Id = Guid.NewGuid(), 
            FirstName = "Active",
            StateCode = ContactState.Active 
        },
        new Contact { 
            Id = Guid.NewGuid(), 
            FirstName = "Inactive",
            StateCode = ContactState.Inactive 
        }
    };
    context.Initialize(contacts);

    // Find active contacts
    var activeContacts = context.CreateQuery<Contact>()
        .Where(c => c.StateCode == ContactState.Active)
        .ToList();

    // Make sure we found the right one
    Assert.Single(activeContacts);
    Assert.Equal("Active", activeContacts[0].FirstName);
}

Basic CRUD Testing

[Fact]
public async Task Create_And_Update_Account_With_Related_Contacts()
{
    // Setup test data
    var account = new Account
    {
        Id = Guid.NewGuid(),
        Name = "Test Corp"
    };

    var contact = new Contact
    {
        Id = Guid.NewGuid(),
        FirstName = "John",
        LastName = "Doe",
        ParentCustomerId = account.ToEntityReference()
    };

    context.Initialize(new Entity[] { account, contact });

    // Test update logic
    var updateCmd = new UpdateAccountCommand(service)
    {
        AccountId = account.Id,
        NewName = "Test Corp International",
        Revenue = new Money(1000000)
    };
    
    await updateCmd.ExecuteAsync();

    // Verify results
    var updatedAccount = context.CreateQuery<Account>()
        .Include(a => a.Contact_Customer) // Related contacts
        .FirstOrDefault(a => a.Id == account.Id);

    Assert.Equal("Test Corp International", updatedAccount.Name);
    Assert.Equal(1000000, updatedAccount.Revenue.Value);
}

Plugin Testing

public class AccountPostCreatePlugin : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
        var service = ((IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory)))
            .CreateOrganizationService(context.UserId);

        var account = context.InputParameters["Target"] as Entity;
        
        // Create associated task
        var task = new Task
        {
            Subject = $"Review new account: {account.GetAttributeValue<string>("name")}",
            RegardingObjectId = account.ToEntityReference()
        };
        
        service.Create(task);
    }
}

public void Plugin_Creates_Task_On_Account_Creation()
{
    // Setup plugin context
    var plugin = new AccountPostCreatePlugin();
    var account = new Account { Id = Guid.NewGuid(), Name = "New Account" };
    
    // Setup execution context
    var pluginContext = context.GetDefaultPluginContext();
    pluginContext.InputParameters = new ParameterCollection
    {
        { "Target", account }
    };
    pluginContext.Stage = 40; // Post-operation
    
    // Execute plugin
    plugin.Execute(context.GetDefaultServiceProvider(pluginContext));
    
    // Verify task creation
    var createdTask = context.CreateQuery<Task>()
        .FirstOrDefault(t => t.RegardingObjectId.Id == account.Id);
    
    Assert.NotNull(createdTask);
    Assert.Contains("Review new account", createdTask.Subject);
}

Custom Action Testing


public class CloseOpportunityRequest : OrganizationRequest
{
    public CloseOpportunityRequest() : base("new_CloseOpportunity")
    {
    }

    public Guid OpportunityId
    {
        get { return (Guid)Parameters["OpportunityId"]; }
        set { Parameters["OpportunityId"] = value; }
    }

    public int Status
    {
        get { return (int)Parameters["Status"]; }
        set { Parameters["Status"] = value; }
    }
}

[Fact]
public void Test_Close_Opportunity_Action()
{
    // Setup
    var opportunity = new Opportunity
    {
        Id = Guid.NewGuid(),
        Name = "Test Deal",
        StatusCode = new OptionSetValue(1)
    };
    context.Initialize(opportunity);

    // Register custom action
    context.AddExecutionMock("new_CloseOpportunity", (req) =>
    {
        var opportunityId = (Guid)req.Parameters["OpportunityId"];
        var status = (int)req.Parameters["Status"];

        // Update opportunity
        var opp = new Opportunity
        {
            Id = opportunityId,
            StateCode = new OptionSetValue(1),
            StatusCode = new OptionSetValue(status)
        };
        context.GetOrganizationService().Update(opp);

        return new OrganizationResponse();
    });

    // Execute action
    var request = new CloseOpportunityRequest
    {
        OpportunityId = opportunity.Id,
        Status = 2 // Won
    };
    
    context.GetOrganizationService().Execute(request);

    // Verify
    var updatedOpp = context.CreateQuery<Opportunity>()
        .FirstOrDefault(o => o.Id == opportunity.Id);
    Assert.Equal(2, updatedOpp.StatusCode.Value);
}

Workflow Testing

public class CreateFollowUpTaskActivity : CodeActivity
{
    [Input("Account")]
    [ReferenceTarget("account")]
    public InArgument<EntityReference> Account { get; set; }

    protected override void Execute(CodeActivityContext executionContext)
    {
        var workflowContext = executionContext.GetExtension<IWorkflowContext>();
        var serviceFactory = executionContext.GetExtension<IOrganizationServiceFactory>();
        var service = serviceFactory.CreateOrganizationService(workflowContext.UserId);

        var task = new Task
        {
            Subject = "Follow up with account",
            RegardingObjectId = Account.Get(executionContext)
        };
        
        service.Create(task);
    }
}

[Fact]
public void Workflow_Creates_Follow_Up_Task()
{
    // Setup
    var account = new Account
    {
        Id = Guid.NewGuid(),
        Name = "Test Account"
    };
    context.Initialize(account);

    // Setup workflow
    var workflow = new CreateFollowUpTaskActivity();
    var workflowInvoker = new WorkflowInvoker(workflow);
    
    // Execute workflow
    var inputs = new Dictionary<string, object>
    {
        { "Account", account.ToEntityReference() }
    };
    
    workflowInvoker.Invoke(inputs);

    // Verify
    var createdTask = context.CreateQuery<Task>()
        .FirstOrDefault(t => t.RegardingObjectId.Id == account.Id);
    
    Assert.NotNull(createdTask);
    Assert.Equal("Follow up with account", createdTask.Subject);
}

Testing Complex Scenarios

Business Rules Testing

[Fact]
public void Contact_Business_Rules_Test()
{
    // Setup business rules
    context.EnableBusinessRules();
    
    var contact = new Contact
    {
        Id = Guid.NewGuid(),
        EmailAddress1 = "invalid-email"
    };

    // Should throw due to business rule violation
    Assert.Throws<InvalidPluginExecutionException>(() =>
        context.GetOrganizationService().Create(contact));
}

Multi-Entity Operations


[Fact]
public async Task Create_Account_With_Primary_Contact()
{
    var data = new AccountWithContactCommand(service)
    {
        AccountName = "Enterprise Corp",
        ContactFirstName = "Jane",
        ContactLastName = "Smith",
        ContactEmail = "jane.smith@enterprise.com"
    };

    var result = await data.ExecuteAsync();

    // Verify account creation
    var account = context.CreateQuery<Account>()
        .FirstOrDefault(a => a.Id == result.AccountId);
    Assert.NotNull(account);

    // Verify contact creation and association
    var contact = context.CreateQuery<Contact>()
        .FirstOrDefault(c => c.Id == result.ContactId);
    Assert.NotNull(contact);
    Assert.Equal(account.Id, contact.ParentCustomerId.Id);
}

Best Practices Summary

Initialize minimal test data
Test business logic isolation
Use meaningful test names
One assertion concept per test
Mock external services when needed
Handle async operations properly
Test error scenarios

Common Pitfalls

Not clearing context between tests
Testing too many scenarios in one test
Not handling plugin context properly
Forgetting to register custom actions
Not testing negative scenarios

Remember, FakeXrmEasy handles all the heavy lifting of simulating Dataverse. You just focus on writing clean, meaningful tests. No more mock setup headaches!

Application lifecycle management (ALM) with Microsoft Power Platform

2022-12-02T04:25:00.005+09:00

Application lifecycle management (ALM) with Microsoft Power Platform - Power Platform | Microsoft Learn

Learn how to implement application lifecycle management (ALM) using Microsoft Power Platform (Power Apps, Power Automate, Dataverse, Power Virtual Agents).

About ALM with Power Platform

OVERVIEW

What is ALM?

CONCEPT

REFERENCE

Tools and apps used for ALM

Understand and work with solutions

CONCEPT

Implement healthy ALM

CONCEPT

For developers

CONCEPT

ALM automation

OVERVIEW

Related docs

OVERVIEW

Solution for Power Apps Connection issue

2022-12-01T03:32:00.000+09:00

Recently I have been working on connection changes in several applications and faced issues after connection changes. The change was not published to the staging and live environment.

Login to https://make.powerapps.com/
Select your environment
Navigate to Dataverse --> Connection
Updated new connection

Issue: After connection update still changes are not reflecting

Navigate to App

Staging environment Power Apps not allowing to edit the app and publish the changes due to security privilege in my application.

Fix :

Navigate to Solutions --> Your Power App

Open Your Power App

Then Save and Published. Your new changes should reflect now.

Play the apps to test the changes.

CRM Data Export service extension till next 18-04-2023 by Microsoft

2022-11-29T23:32:00.002+09:00

Microsoft has extend Dynamics 365 Data Export Service till 18-April-2022. Previously mentioned it was planed on end of November.

https://powerapps.microsoft.com/en-us/blog/do-more-with-data-from-data-export-service-to-azure-synapse-link-for-dataverse/

Steps to Extend DES.

Navigate to Settings > Data Export

Click below One-Time Extension button for extension

Click the Submit button

Then your environment will extend till 18-April-2022.

Migrate Dynamics CRM 365 On-Premise to CRM 365 Online

2022-01-24T19:43:00.018+09:00

Pros of Migrating to Dynamics 365 Customer Engagement (CE) Online:

• Cost reduction: Moving to Dynamics 365 CE Online can help reduce costs associated with maintaining on-premises infrastructure and resources.

• No manual upgrades: Microsoft handles all upgrades and maintenance for Dynamics 365 CE Online, so you don't have to worry about performing manual updates.

• Fewer resources needed: Migrating to Dynamics 365 CE Online allows you to manage the system with fewer resources, including infrastructure and database expertise.

• High availability and disaster recovery: Dynamics 365 CE Online offers a high availability and disaster recovery environment, with a guaranteed 99.9% uptime by Microsoft.

• Greater support: Microsoft provides more support for product issues with Dynamics 365 CE Online compared to the on-premises version.

• Access from anywhere: Dynamics 365 CE Online can be accessed from any location with an internet connection.

• Office 365 integration: You can use your Office 365 ID for login and multi-factor authentication (MFA) with Dynamics 365 CE Online.

• Multiple device access: Dynamics 365 CE Online can be accessed using a variety of devices, including mobile phones and tablets.

• Email tracking with Outlook: You can use the Outlook App to track emails with Dynamics 365 CE Online.

• Access to online features: Dynamics 365 CE Online provides access to Microsoft CRM online features and technologies, such as Power Apps, Flows, and Power BI.

Limitations of Dynamics 365 Online:

• Cannot use third-party DLLs for plugin and workflow development, which may limit the functionality that can be added to the system.

• Reports can only be developed using fetch xml, which may not be suitable for all reporting needs and may require additional time and effort to convert existing SQL reports.

• Additional data storage and attachment storage may be required at an additional cost, depending on the size and usage of the system.

• Extra testing and releases may be necessary for regular CRM rollup upgrades to ensure that the system continues to function as expected and to address any potential issues that may arise.

• There is limited control over the infrastructure and hardware, which is managed by Microsoft. This means that the organization may not have the ability to make certain customizations or configurations to the system.

Using Dynamics 365 On-Premise:

• The organization has full control over the environment and can make unsupported customizations to the system.

• The organization has full control over the database and can develop SQL reports and write SQL queries for data extraction.

Limitations of Dynamics 365 On-Premise:

• Requires more cost, infrastructure, and staff to manage the system.

• May require specialized application experts to manage the infrastructure, such as ADFS, SSRS, and SQL DBA (Cluster, Always On with DR).

• Regular maintenance is required, including OS and security patches, which may require downtime and regression testing.

• Vulnerability scans and penetration testing may be necessary, with necessary fixes required to address any identified issues.

• Support from Microsoft may be more difficult to obtain and may take longer to resolve issues compared to the online version of Dynamics 365.

Dynamics 365 V8 (on-Prem) vs Dynamics 365 CE (online)

Technical differences

• Dynamics 365 CE Online is entirely cloud-based and managed by Microsoft (including product, database, data center, and infrastructure)

• CRM rollup upgrades are managed by Microsoft twice a year.

• Database, data center, and disaster recovery (DR) managed by Microsoft (DB backup and restoration is very fast and simple)

• Reports – Only supports Fetch XML reports, not SQL query reports, it might be required to convert SQL based reports before online migration.

• Interfaces with other systems - Requires opening of firewall connections to connect to other systems.

• Does not support Outlook client, requires switch to CRM Outlook online app

• Incompatible JavaScripts may need to be modified for new XRM APIs.

• ADFS server not required, can use Office 365 login ID for authentication

• Plugins and workflows using third-party DLLs must be modified (Ex: IL merge)

Requirements

• User training on new system and change management process during testing (UAT)

• Personalized experience apps based on CRM security roles for improved access management and ease of use (e.g. back office app, admin app, shop ops app)

• UI changes with Dynamics 365 CE Online 9.1 using unified client interface (UCI)

Operations

• Rollup version upgrades: It is important for users of Dynamics 365 CE Online to be aware of and plan for rollup version upgrades, which are managed by Microsoft and occur twice a year. Users should be informed of the changes and asked to try them out in the testing environment (UAT). All versions of the system (development, staging, testing, and production) must be upgraded to the same rollup.

• Maintenance and downtime: There is no need for a system maintenance window or downtime with Dynamics 365 CE Online, as the system is managed and maintained by Microsoft.

• Accessibility: Dynamics 365 CE Online can be accessed from anywhere in the world, which allows users and the development team to work remotely and provide better support.

• User experience: The user experience may be different in Dynamics 365 CE Online due to changes in the unified client interface (UCI).

• Microsoft support: Microsoft support is generally more available for Dynamics 365 CE Online compared to Dynamics 365 V8 On-Premise.

• New features: Users of Dynamics 365 CE Online receive new features twice a year as part of the rollup updates.

Migration Plan

Assumptions

• Eligibility for FastTrack migration: The company has the necessary eligibility requirements for FastTrack migration.

• Migration method: The migration will be done using the FastTrack method.

• Account type: Hybrid AD accounts will not be used, and Office 365 accounts will be used to access the system.

• Email address and profile: The email address will be an Office 365 account and the email profile will be configured using Microsoft Exchange Online.

• Deployment server and organization: A new deployment server with Windows Server 2016 and SQL 2016 will be set up to create a separate organization for customizations required for CRM Online migration. The current server and organizations should not be used to avoid impacting current operations.

• Azure Tenant: The company has an Azure Tenant, and an Azure subscription and storage account (which the customer will need to pay for along with Dynamics 365 subscriptions) have been set up, along with provision for two sandbox environments in staging.

• CRM licenses: All necessary CRM licenses have been purchased before the migration.

• Microsoft Lifecycle Services: The migration project has been set up in Microsoft Lifecycle Services, which uses a wizard-based hosted tool for the migration. Microsoft Lifecycle Services

• Managed CRM solution: A managed CRM solution will be used for deployment to the testing and production environments.

Here are some points to consider when planning a migration to Dynamics 365 Customer Engagement (CE) Online:

• Dual licenses: It is possible to use a Dynamics 365 CRM On-Premise license for the online version of the software.

• Licensing method: The most cost-effective licensing method can be chosen based on the client's budget and system access requirements. Options include Enterprise (more costly), Power app (less costly), and Team Member (less costly).

Setup Development Environment

Here is a list of steps to set up a development environment for a migration to Dynamics 365 Customer Engagement (CE) Online:

• Set up a new on-premise server: A new server should be set up using the development environment before creating an online migration solution to avoid additional migration cycles. This server should have CRM V8, SQL 2016, and the operating system Windows Server 2016.

• Create a new development organization: A new development organization can be created by restoring the existing development CRM database and importing the organization.

• Make necessary changes in the development CRM: The following changes should be made in the development CRM:

• Create a new CRM solution and include all customizations in that solution
• Convert SQL-based reports to Fetch XML
• Update plugins and workflows to run in sandbox mode
• Check for and reconfigure any integration with third-party tools, and remove IL merge
• Update JavaScript to the new client object model (compatible with the unified client interface (UCI))
• Update CRM forms to provide a rich user experience with the UCI
• Make the solution online compatible
• Test that all application functionalities are working as expected

• Upload the database backup to Azure Blob Container: Take a database backup, log in to the Lifecycle portal, and upload the database backup to the Azure Blob Container.

• Upgrade CRM: Follow the steps to upgrade CRM 9.0, then CRM 9.1, using the provided tools and steps.

• Validation of the migration: Run the validation report and fix any issues identified in the CRM V8 environment. Once the issues are fixed, upload the database backup again, follow the same steps, and ensure that the validation report is successful before uploading the CRM online via the Lifecycle portal.

• Creation of the online development environment: Once the validation steps are completed, follow the steps in the Lifecycle portal to create the CRM Online development environment.

• User mapping: Upload user mapping with the permissions required to complete the migration successfully.

• Regression testing in the online environment: Perform testing in the online environment to ensure that all functionalities are working as expected. This may include functional, integration, and user acceptance testing.

Setup UAT Environment

Here are the steps to set up a testing (UAT) environment for a migration to Dynamics 365 Customer Engagement (CE) Online:

• Create a new UAT organization: A new testing organization can be created by restoring the existing testing CRM database and importing the organization in the new environment.

• Import the customized solution from the development CRM: Import the customized solution from the development CRM to the testing environment, including any fixes made during the development migration.

• Upload the database backup to Azure Blob Container: Take a database backup, log in to the Lifecycle portal, and upload the database backup to the Azure Blob Container.

• Upgrade CRM: Follow the steps to upgrade CRM 9.0, then CRM 9.1, using the provided tools and steps.

• Validation of the migration: Once issues are fixed, upload the database backup again, follow the same steps, and ensure that the validation report is successful before uploading the CRM online via the Lifecycle portal.

• Creation of the online testing environment: Once the validation steps are completed, follow the steps in the Lifecycle portal to create the CRM Online testing environment.

• User mapping: Upload user mapping with the permissions required to complete the migration successfully.

• Testing: Perform a full regression test to ensure that all functionalities are working as expected in the online testing environment. This may include functional, integration, and user acceptance testing.

• Familiarization with the new unified client interface: Help users become familiar with the new unified client interface (UCI).

Setup Production Environment

Here are the steps to set up a production environment for a migration to Dynamics 365 Customer Engagement (CE) Online:

• Pilot migration: Microsoft can provide support for a pilot migration before the production CRM migration in the new environment.

• Inform users: Inform users that they will need to stop using the production system.

• Create a new production organization: A new production organization can be created by restoring the existing production CRM database and importing the organization.

• Upload the database backup to Azure Blob Container: Take a database backup, log in to the Lifecycle portal, and upload the database backup to the Azure Blob Container.

• Creation of the online production environment: Once the validation steps are completed, follow the steps in the Lifecycle portal to create the CRM Online production environment.

• User mapping: Upload user mapping with the permissions required to complete the migration successfully.

• Testing: Perform a full regression test to ensure that all functionalities are working as expected in the online production environment. This may include functional, integration, and user acceptance testing.

Eligibility

FastTrack assistance is available for customer tenants with 150 or more licenses from one of the eligible plans from the following Microsoft product families: Microsoft 365, Office 365, Microsoft Viva, Enterprise Mobility & Security, and Windows 10. However, it may still be possible to get Microsoft support by talking to them and convincing them of the future usage of the online CRM system and the increase in user licensing capacity.

More Information: https://docs.microsoft.com/en-IN/fasttrack/eligibility

Refences:

Refer to the following video for more information: Dynamics CRM On-premise To Dynamics 365 Online Migration Tech Talk.

https://docs.microsoft.com/en-us/dynamics365/fasttrack/migration

https://nishantrana.me/2020/05/15/dynamics-crm-on-premise-to-online-migration-program-microsoft-fasttrack/

Dynamics CRM to Dynamics 365 Online Migration Guide

Dynamics CRM On-Premise to Dynamics 365 Online Migration Study Guide

Quiz

1.
What are the primary benefits Microsoft offers for customers migrating Dynamics CRM on-premises to Dynamics 365 online?
2.
According to the Microsoft Learn article, what Dynamics CRM on-premises versions are currently supported for OP2OL migration services?
3.
What were some of the challenges with manual migration methods (like using SSIS, KingswaySoft, and Scribe) from Dynamics CRM on-premises to online, especially for older versions like CRM 2011?
4.
Describe the high-level architecture of the FastTrack migration tool, mentioning the key components involved.
5.
What are some critical prerequisites that need to be in place before starting the migration process using the FastTrack tool? Provide at least three examples.
6.
Explain the role of the CRM validation service in the migration process and what it helps to identify.
7.
What is the purpose of the intermediate CRM environments (e.g., CRM 2011, 2013, 2015, 2016) created during the FastTrack migration process, especially when migrating from an older version?
8.
What are the key responsibilities of the customer and the FastTrack team during the Dynamics CRM on-premises to online migration project?
9.
What are some limitations of Dynamics 365 Online compared to the on-premises version, as highlighted in the Medium article? Provide at least two examples.
10.
Briefly outline the general six-step process for migrating Dynamics CRM from on-premises to CRM 365 Online as summarized in the second Medium article.

Quiz Answer Key

1.
Microsoft provides guidance, tools, documentation, and performs configuration tasks where applicable and feasible to assist eligible customers with supported versions of Dynamics CRM in migrating their on-premises database to Dynamics 365 and Microsoft Dataverse. This aims to make the migration process more automated and guided.
2.
Currently, the OP2OL migration services support Dynamics CRM 2016 (on-premises) and later versions. This means customers on these versions can utilize Microsoft's direct migration assistance.
3.
Manual methods were often time-consuming and labor-intensive, lacking automation and a guided process. Especially for older versions like CRM 2011, significant schema changes over time made manual data mapping challenging. There was also no easy way to check for unsupported customizations beforehand.
4.
The FastTrack migration tool utilizes Lifecycle Services as a portal to access the tool. It involves provisioning temporary Azure environments within the customer's subscription, upgrading the on-premises database through intermediate CRM versions (like 2016), using Azure Blob Storage for the database backup, and employing services for validation and final migration to Dynamics 365 Online.
5.
Critical prerequisites include having an existing, unconfigured Dynamics 365 online sandbox license, an Azure subscription with the necessary roles and privileges, and ensuring that all on-premises users have corresponding identities and required licenses in the Office 365 tenant for proper mapping.
6.
The CRM validation service analyzes the solutions (either the default solution from the uploaded database or manually uploaded solution files) for any unsupported customizations that might hinder the migration process. It provides a report detailing these issues, allowing customers and partners to review and address them before the actual migration.
7.
The intermediate CRM environments are created to facilitate the upgrade process of the on-premises database. For example, a database from an older version like CRM 2011 needs to be upgraded sequentially through versions like 2013, 2015, and finally 2016 before it can be migrated to Dynamics 365 Online. This staged upgrade ensures compatibility and data integrity.
8.
The customer is responsible for understanding the migration process, ensuring all prerequisites are met (licensing, Azure setup, user mapping), planning the migration timeline, and validating the migrated environment. The FastTrack team provides the migration tool, offers guidance and support, helps remove roadblocks, and performs the final migration step.
9.
Limitations of Dynamics 365 Online include the inability to use third-party DLLs for plugin and workflow development, and the restriction of reports to FetchXML (potentially requiring conversion of existing SQL-based reports). Additionally, there is limited control over the underlying infrastructure and hardware.
10.
The general process involves determining the reason for migration, planning the migration strategy, preparing the on-premises environment (backups, updates), migrating the data and customizations using Microsoft or third-party tools, thoroughly testing and validating the migrated environment, and finally going live with the new Dynamics 365 Online instance.

Essay Format Questions

1.
Discuss the key motivations and benefits for organizations choosing to migrate from Dynamics CRM on-premises to Dynamics 365 Online. Consider both technical and business advantages.
2.
Analyze the role of the FastTrack migration program and its associated tool in simplifying the process of migrating from Dynamics CRM on-premises to Dynamics 365 Online. What are its strengths and what aspects still require significant customer involvement?
3.
Compare and contrast the technical considerations and potential challenges of migrating from older Dynamics CRM on-premises versions (e.g., 2011, 2013) versus newer versions (e.g., 2016) to Dynamics 365 Online, based on the provided sources.
4.
Evaluate the importance of the pre-migration assessment and validation phase in ensuring a successful transition from Dynamics CRM on-premises to Dynamics 365 Online. What are the critical elements that need to be addressed during this stage?
5.
Considering the information from all the provided sources, outline a comprehensive migration plan for a hypothetical organization moving from Dynamics CRM 2013 on-premises to Dynamics 365 Online. Include key stages, responsibilities, and potential challenges.

Glossary of Key Terms

•
Dynamics CRM (on-premises): A version of Microsoft's Customer Relationship Management software that is installed and hosted on an organization's own servers and infrastructure.
•
Dynamics 365: Microsoft's suite of intelligent business applications, including Customer Engagement (formerly Dynamics CRM) applications, offered as a cloud-based service.
•
Microsoft Dataverse: The underlying data service that supports many Microsoft Power Platform components and Dynamics 365 applications, providing a scalable and secure data storage option in the cloud.
•
OP2OL (On-premises to Online): Refers to the migration services and process of moving from an on-premises deployment of Dynamics CRM to the online (cloud-based) version, Dynamics 365.
•
FastTrack: A Microsoft program designed to help customers deploy Microsoft cloud solutions, including Dynamics 365, providing guidance, tools, and resources.
•
Lifecycle Services (LCS): A collaboration portal provided by Microsoft that offers tools and services to manage the lifecycle of Microsoft Dynamics 365 implementations, including migration tools.
•
Azure Subscription: A foundational element for using Azure services, providing a billing boundary and a container for resources.
•
Azure Blob Storage: Microsoft Azure's object storage solution for the cloud, optimized for storing massive amounts of unstructured data, such as the on-premises database backup.
•
CRM Validation Service: A component of the FastTrack migration tool that analyzes a Dynamics CRM database or solution for potential compatibility issues with Dynamics 365 Online.
•
Sandbox License: A non-production environment for Dynamics 365 Online used for development, testing, and training purposes before deploying changes to the live production environment.
•
Multi-geo: A feature in Microsoft 365 and Dynamics 365 that allows a tenant to provision and store data at rest in multiple geographical locations.
•
Managed Solution: A packaged set of Dynamics 365 customizations that can be imported, exported, and managed as a single unit.
•
Fetch XML: A proprietary query language used by Dynamics 365 for retrieving data, particularly for reports in the online version.
•
Unified Client Interface (UCI): The modern, web-based user interface for Dynamics 365 applications, designed for consistent experience across various devices.
•
Plugin: Custom code written in .NET that executes in response to events within Dynamics 365, extending its out-of-the-box functionality.
•
Workflow: An automated process within Dynamics 365 that can be triggered by specific events or run on demand to perform a series of actions.
•
SSIS (SQL Server Integration Services), KingswaySoft, Scribe: Third-party tools commonly used for data integration and migration tasks, often employed in manual Dynamics CRM migrations.
•
DLL (Dynamic Link Library): A type of file that contains compiled code that can be used by Windows programs, sometimes used in Dynamics CRM on-premises customizations.
•
ADFS (Active Directory Federation Services): A Microsoft service that provides single sign-on (SSO) capabilities, often used for authentication in on-premises Dynamics CRM deployments.
•
SSRS (SQL Server Reporting Services): A Microsoft platform for creating and managing paginated reports, commonly used with Dynamics CRM on-premises for custom reporting.
•
SQL DBA (Database Administrator): A professional responsible for managing and maintaining SQL Server databases.
•
UAT (User Acceptance Testing): A phase of testing where end-users verify that the migrated system meets their requirements and works as expected.
•
Hybrid AD Accounts: User accounts that exist in both on-premises Active Directory and Azure Active Directory, often used in hybrid cloud environments.
•
ILMerge: A utility that merges multiple .NET assemblies into a single assembly, sometimes used in on-premises plugin development but not supported in Dynamics 365 Online.
•
AX Client: The legacy desktop client for earlier versions of Dynamics CRM on-premises, no longer supported in Dynamics 365 Online.

chamara iresh's Blog

Mastering Microsoft Dynamics 365 CRM Plugins: The Ultimate Deep Dive

What Exactly is a Dynamics 365 Plugin?

Real-World Plugin Use Cases

Understanding the Plugin Execution Pipeline

Stages in the Pipeline

Synchronous vs Asynchronous Plugins

Transaction and Rollback

Depth and Preventing Infinite Loops

Images: Pre-Image and Post-Image

Filtering Attributes

Synchronous vs Asynchronous Plugins: When to Use Each

Plugins vs. Other Tools

The IPlugin Interface

Accessing Context and Services

Implementing Logic

Exception Handling

Registering Plugins

Plugin Best Practices

Advanced Techniques for Senior Developers

Automating Plugin Deployment: spkl and DevOps

Testing and Debugging Plugins

Common Pitfalls and How to Avoid Them

Latest Features and Innovations

Final Thoughts

Model Context Protocol (MCP) + Dataverse: The Next Leap for AI and the Power Platform

What is Model Context Protocol (MCP)?

Why Does MCP Matter?

What Can You Actually Do with MCP + Dataverse?

What Tools Are Available?

Limitations & Tips

Conclusion

How to Master Solution Layering and Troubleshoot Customization Conflicts in Dynamics 365 CRM

What Is Solution Layering in Dynamics 365 CRM?

The Three Key Layers

How Do Layer Conflicts Happen?

Merge or “Last One Wins”?

How to Troubleshoot with the Solution Layers Tool

The Unmanaged Layer: A Double-Edged Sword

Resolving Managed Solution Conflicts

Dependency Issues: Why Can’t I Uninstall a Solution?

How to Use Layering to Your Advantage

Best Practices & Tips

Summary

How We Recovered a Retired Product in Microsoft Dynamics 365 CRM (And What You Can Do)

The Problem

What They Did

The Hidden Problem

The Real Fix

Key Takeaways

Decoding the Mystery of msdynci Columns in Dynamics 365 and Customer Insights

The Purpose Behind the Pattern: Why Only Some Tables Get the msdynci_ Prefix

Validating Your Integration: Ensuring Smooth Synchronization

Key Insights for Administrators

Diving Deeper: Exploring Other msdynci_ Tables

Real-World Applications: Putting msdynci_ Columns to Work

Staying Informed: Recent Updates and Best Practices

Mastering the Intersect Method in C#: A Beginner's Guide

What is Intersect?

Basic Usage with Simple Types

Using Intersect with Custom Objects

Performance: Why Intersect Shines

Handling Null Values Like a Pro

Wrapping It Up

Try It Yourself!

Virtual Tables in Microsoft Dataverse - CRM Online

How to Integrate Customer Insights with Microsoft Dynamics 365 CRM Online

What is Dynamics 365 Customer Insights?

Steps to Integrate Customer Insights with Dynamics 365 CRM Online

1. Set Up Dynamics 365 Customer Insights

2. Enable Integration with Dynamics 365 CRM

3. Configure Customer Insights Cards in Dynamics 365 CRM

4. Utilize Prebuilt AI Models

5. Enable Real-Time Data Synchronization

6. Build Custom Visualizations with Power BI

7. Integrate with Marketing and Sales Tools

Benefits of Integrating Customer Insights with Dynamics 365 CRM Online

1. Centralized Data for a Unified Customer View

2. Improved Customer Engagement

3. AI-Powered Decision Making

The Purpose Behind the Pattern: Why Only Some Tables Get the `msdynci_` Prefix

Diving Deeper: Exploring Other `msdynci_` Tables

Real-World Applications: Putting `msdynci_` Columns to Work