Are you looking for a reliable way to integrate Dynamics 365 CRM with external systems in real time? Polling APIs or scheduling batch jobs can delay updates and increase complexity. What if you could instantly notify external services when key events happen inside Dynamics 365?  This blog will show you how to use webhooks—an event-driven mechanism to trigger real-time updates and data exchange with external services, making your integrations faster and more efficient.  A webhook is a user-defined HTTP callback that is triggered by specific events. Instead of your external system repeatedly asking Dynamics 365 for updates, Dynamics 365 pushes updates to your service instantly.  Dynamics 365 supports registering webhooks through plugin steps that execute when specific messages (create, update, delete, etc.) occur. This approach provides low latency and ensures that your external systems always have fresh data.  This walkthrough covers the end-to-end process of configuring webhooks in Dynamics 365, registering them via plugins, and securely triggering external services.  What You Need to Get Started  Step 1: Create Your Webhook Endpoint  Step 2: Register Your Webhook in Dynamics 365  Step 3: Create a Plugin to Trigger the Webhook  public void Execute (IServiceProvider serviceProvider)  {     var notificationService = (IServiceEndpointNotificationService)serviceProvider.GetService(typeof(IServiceEndpointNotificationService));     Entity entity = (Entity)context.InputParameters[“Target”];     notificationService.Notify(“yourWebhookRegistrationName”, entity.ToEntityReference().Id.ToString()); }  Register this plugin step for your message (Create, Update, Delete) on the entity you want to monitor. Step 4: Test Your Webhook Integration  Step 5: Security and Best Practices Real-World Use Case A company wants to notify its external billing system immediately when a new invoice is created in Dynamics 365. By registering a webhook triggered by the Invoice creation event, the billing system receives data instantly and processes payment without delays or manual intervention.  To conclude, webhooks offer a powerful way to build real-time, event-driven integrations with Dynamics 365, reducing latency and complexity in your integration solutions.  We encourage you to start by creating a simple webhook endpoint and registering it with Dynamics 365 using plugins. This can transform how your CRM communicates with external systems.  For deeper technical support and advanced integration patterns, explore CloudFront’s resources or get in touch with our experts to accelerate your Dynamics 365 integration project. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com.

When it comes to Microsoft Dynamics 365, one of its biggest strengths—and challenges—is how many ways there are to integrate it with other platforms. Whether you’re syncing with an ERP, pushing data to a data lake, or triggering notifications in Teams, the real question becomes:  Which integration method should you choose?  In this blog, we’ll break down the top 5 tools used by teams around the world to integrate Dynamics 365 with other systems. Each has its strengths, and each fits a different type of use case.  1. Power Automate – Best for Quick, No-Code Automations  What it is: A low-code platform built into the Power Platform suite. When to use it: Internal automations, approvals, email notifications, basic integrations.  Lesser-Known Tip: Power Automate runs on two plans—per user and per flow. If you have dozens of similar flows, the “per flow” plan can be more cost-effective than individual licenses.  Advanced Feature: You can call Azure Functions or hosted APIs directly within a flow, effectively turning it into a lightweight integration framework. Pros:  Cons:  Example: When a new lead is created in D365, send an email alert and create a task in Outlook.  2. Azure Logic Apps – Best for Scalable Integrations  What it is: A cloud-based workflow engine for system-to-system integrations. When to use it: Large-scale or backend integrations, especially when working with APIs.  Lesser-Known Tip: Logic Apps come in two flavours—Consumption and Standard. The Standard tier offers VNET-integration, local development, and built-in connectors at a flat rate, which is ideal for predictable, high-throughput scenarios.  Advanced Feature: Use Logic Apps’ built-in “Integration Account” to manage schemas, maps, and certificates for B2B scenarios (AS2, X12). Pros:  Cons:  Example: Sync Dynamics 365 opportunities with a SQL database in real time.  3. Data Export Service / Azure Synapse Link – Best for Analytics  What it is: Tools to replicate D365 data into Azure SQL or Azure Data Lake. When to use it: Advanced reporting, Power BI, historical data analysis.  Lesser-Known Tip: Data Export Service is being deprecated in flavours of Azure Synapse Link, which provides both near-real-time and “materialized view” patterns. You can even write custom analytics in Spark directly against your live CRM data.  Advanced Feature: With Synapse Link, you can enable change data feed (CDC) and query Delta tables in Synapse, unlocking time-travel queries for historical analysis. Pros:  Cons:  Example: Export all account and contact data to Azure Synapse and visualize KPIs in Power BI.  4. Dual-write – Best for D365 F&O Integration  What it is: A Microsoft-native framework to connect D365 CE (Customer Engagement) and D365 F&O (Finance & Operations). When to use it: Bi-directional, real-time sync between CRM and ERP.  Lesser-Known Tip: Dual-write leverages the Common Data Service pipeline under the covers—so any customization (custom entities, fields) you add to Dataverse automatically flows through to F&O once you map it.  Advanced Feature: You can extend dual-write with custom Power Platform flows to handle pre- or post-processing logic before records land in F&O. Pros:  Cons:  Example: Automatically sync customer and invoice records between D365 Sales and Finance.  5. Custom APIs & Webhooks – Best for Complex, Real-Time Needs  What it is: Developer-driven integrations using HTTP APIs or Dynamics 365 webhooks. When to use it: External systems, fast processing, custom business logic.  Lesser-Known Tip: Dynamics 365 supports registering multiple webhook subscribers on the same event. You can chain independent systems (e.g., call your middleware, then a monitoring service) without writing code.  Advanced Feature: Combine webhooks with Azure Event Grid for enterprise-grade event routing, retry policies, and dead-lettering. Pros:  Cons:  Example: Trigger an API call to a shipping provider when a case status changes to “Ready to Ship.”  To conclude, Microsoft Dynamics 365 gives you a powerful set of integration tools, each designed for a different type of business need. Whether you need something quick and simple (Power Automate), enterprise-ready (Logic Apps), or real-time and custom (Webhooks), there’s a solution that fits.  Take a moment to evaluate your integration scenario. What systems are involved? How much data are you moving? What’s your tolerance for latency and failure?  If you’re unsure which route to take, or need help designing and implementing your integrations, reach out to our team for a free consultation. Let’s make your Dynamics 365 ecosystem work smarter—together.  We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com.

Have you ever needed to pull data out of Dynamics 365 but didn’t know where to begin? Whether you’re building a report, wiring up a Power App, or feeding data into another system, OData is your friend. In just a few clicks, you’ll be able to write simple HTTP requests to retrieve exactly the records you want—no complex code required.  What Is OData and Why It Matters OData (Open Data Protocol) is a standardized way to query RESTful APIs. Microsoft Dynamics 365 exposes its entire data model via OData, so you can:  This means faster development and fewer custom endpoints.  1. Finding Your Web API Endpoint  https://yourorg.crm.dynamics.com/api/data/v9.2 That’s your base URL for every OData call. 2. Exploring Entities via Metadata  Append $metadata to your base URL:  GET https://yourorg.crm.dynamics.com/api/data/v9.2/$metadata  You’ll get an XML file listing all entities (contacts, accounts, leads, etc.), their fields, data types, and navigation properties. Tip: press Ctrl + F to search for your entity by name.  3. Core OData Query Options  a. $select – Return Only What You Need  GET https://yourorg.crm.dynamics.com/api/data/v9.2/contacts?$select=fullname,emailaddress1,jobtitle This limits the payload to just those three fields, making responses smaller and faster.  b. $filter – Narrow Down Your Results  GET https://yourorg.crm.dynamics.com/api/data/v9.2//contacts?$filter=firstname eq ‘Ankit’ Operators: eq (equals) ne (not equals) gt / lt (greater than / less than) Combine with and / or :  GET https://yourorg.crm.dynamics.com/api/data/v9.2//contacts?$filter=statecode eq 0 and jobtitle eq ‘Consultant’ c. $orderby – Sort Your Data GET https://yourorg.crm.dynamics.com/api/data/v9.2/contacts?$orderby=createdon desc  Newest records appear first.  d. $top – Limit Record Count GET https://yourorg.crm.dynamics.com/api/data/v9.2/contacts?$top=5  Great for previews or testing.  e. $expand – Fetch Related Records  Example: Get each contact’s full name and its parent account name in one request:  GET https://yourorg.crm.dynamics.com/api/data/v9.2/contacts?   $select=fullname,parentcustomerid   &$expand=parentcustomerid_account($select=name) parentcustomerid is the lookup field  parentcustomerid_account is the navigation property  Nested $select limits expanded fields  Another example: Expand opportunities with customer account info:  GET https://yourorg.crm.dynamics.com/api/data/v9.2/opportunities?$expand=customerid_account($select=name,accountnumber) Finding Expandable Names In your $metadata, look for lines like:  <NavigationProperty Name=”parentcustomerid_account” Type=”Microsoft.Dynamics.CRM.account” />  Use that Name value in your $expand.  Putting It All Together Suppose you want all active contacts at “Contoso” and their account names:  GET https://yourorg.crm.dynamics.com/api/data/v9.2/contacts?$filter=statecode eq 0 &$expand=parentcustomerid_account($filter=name eq ‘Contoso’; $select=name)&$select=fullname,emailaddress1  Conclusion:  OData might sound technical at first, but once you get the hang of it, it becomes one of the most powerful tools in your Dynamics 365 toolbox. Whether you’re building integrations, reports, or simple automations, OData gives you the flexibility to query exactly what you need—without relying on custom development.  Start small. Open your environment, locate the Web API URL, and try your first $select or $filter query. Once you’re confident, move on to advanced options like $expand and $orderby.  Call to Action:  Need help designing smarter OData-based solutions or integrating with Power Platform tools? Reach out to our team today and we’ll help you build something great. 

Introduction: This guide will walk you through creating and accessing Azure Blob Storage and integrating it with Azure Data Factory to automate data pipelines. From setting up a storage account and managing containers to configuring pipelines and transferring data to an Azure SQL Database, this step-by-step tutorial ensures you gain a comprehensive understanding of the process. Steps: 3. Click on + Create to initiate the creation of a new storage account. 4. Fill in the required fields like subscription, resource group, and region. Review all the settings before proceeding. 5. Create a Storage Account 6. Once the storage account is created, go to the resource by clicking on Go to Resource. 7. In the storage account, navigate to the Containers section and click + Container to create a new container for storing your files. 8. Click on the container you just created to access its contents. 9. Upload the desired JSON file into the container by clicking on Upload and selecting the file from your local system. 10. Ensure that the uploaded file is now listed in the container. 11. Go back to the Azure Portal and search for Azure Data Factory to open the ADF service. 12. From the ADF home screen, go to Author > Datasets. Click + New Dataset to create a new dataset for your Blob Storage. 13. Select the Azure Blob Storage dataset type, as you are working with data stored in Blob Storage. 14. Choose the data format that matches the file you uploaded, such as JSON, and click Continue. 15. Enter the necessary details for your dataset, including the file path and format settings. Select the appropriate Authentication type and specify the Storage account where the Blob Storage resides. Click Create to finalize the dataset creation. 16. Verify the settings and click OK to confirm the dataset configuration. 17. Navigate to the Pipelines section and click + New Pipeline to create a pipeline that will define your data flow. 18. Pipeline gets created successfully as shown below. 19. In the pipeline, select the dataset type as Azure SQL Database and click Continue to set up the SQL Database dataset. 20. Provide the necessary Linked Service details for your SQL database and click Create. 21. After configuring both the source and target datasets, and the pipeline, publish all the elements to save your work. 22. Once the pipeline is running successfully, you can verify its functionality by querying the destination database to ensure data is being transferred properly. a. Go to the SQL Database and select the relevant database. b. Select the database on which we have perform a query. c. Log in with your credentials. d. Write a simple test query to verify data has been transferred from Blob Storage to the SQL Database. Execute the query and confirm that the expected output is returned. Conclusion: Integrating Azure Blob Storage with Azure Data Factory is a powerful way to manage and automate data workflows in the cloud. This guide walks you through creating a storage account, configuring containers, uploading data, and designing a pipeline to process and transfer data to Azure SQL Database. By following these steps, you can efficiently handle large-scale data integration and ensure seamless communication between your data sources and destinations. Azure Data Factory not only simplifies the process of orchestrating data pipelines but also provides robust options for monitoring and optimizing workflows. Whether you are managing JSON files, processing transactional data, or setting up complex ETL processes, Azure’s ecosystem offers a reliable and scalable solution. Start exploring these tools today to unlock new possibilities in data-driven operations! We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com.

In Dynamics 365 and Power Platform, C# plugins play a crucial role in extending the functionality of your applications. One of the key aspect’s developers need to grasp is how to handle various data types effectively. This guide will walk you through the most commonly used data types in C# plugins, including strings, currency, lookups, option sets, and more. Introduction to C# Plugins C# plugins are custom business logic that you can implement in Dynamics 365 to execute in response to specific events, like creating, updating, or deleting records. They allow you to manipulate data and interact with the system in powerful ways. Understanding how to work with different data types is essential for writing effective plugins. Retrieving Entities Before you can manipulate data types, you first need to retrieve the entity record you want to work with. Here’s how you can do that: public void Execute(IServiceProvider serviceProvider){IPluginExecutionContext context =(IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext)); IOrganizationServiceFactory serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory)); IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId); // Retrieve entity by IDEntity entity = service.Retrieve(“entity_logical_name”, context.PrimaryEntityId, new ColumnSet(true));}   Working with Different Data Types String The most common data types are strings. They can represent text values. Getting a String Value: string name = entity.GetAttributeValue<string>(“string_attribute_name”); Setting a String Value: entity[“string_attribute_name”] = “New String Value”; Currency Currency is represented by the Money type in Dynamics 365. Getting a Currency Value: Money amount = entity.GetAttributeValue<Money>(“currency_attribute_name”);decimal currencyValue = amount?.Value ?? 0; Setting a Currency Value: entity[“currency_attribute_name”] = new Money(150.00m); // Set to 150.00 Lookups Lookup fields refer to related entities. They are represented by the EntityReference type. Getting a Lookup Value: EntityReference lookup = entity.GetAttributeValue<EntityReference>(“lookup_attribute_name”); if (lookup != null) {     Guid lookupId = lookup.Id;     string lookupName = lookup.Name; // Requires another retrieve call to get the name} Setting a Lookup Value: entity[“lookup_attribute_name”] = new EntityReference(“related_entity_logical_name”, lookupId); Option Sets (Picklists) Option sets are used to represent a list of choices. They are represented by the OptionSetValue type. Getting an Option Set Value: OptionSetValue optionSetValue = entity.GetAttributeValue<OptionSetValue>(“optionset_attribute_name”); int selectedValue = optionSetValue?.Value ?? 0; Setting an Option Set Value: entity[“optionset_attribute_name”] = new OptionSetValue(1); // Assuming 1 is a valid option Multiselect Option Set Multiselect option sets allow multiple selections from a list. Getting a Value: IEnumerable<OptionSetValue> multiSelectOptions = entity.GetAttributeValue<IEnumerable<OptionSetValue>>(“multiselect_optionset”); Setting a Value: entity[“multiselect_optionset”] = new List<OptionSetValue> {     new OptionSetValue(1),     new OptionSetValue(2) }; // Assuming 1 and 2 are valid options Boolean Values or Two Options Boolean fields represent true/false values. Getting a Boolean Value: bool? isActive = entity.GetAttributeValue<bool?>(“boolean_attribute_name”); Setting a Boolean Value: entity[“boolean_attribute_name”] = true; // or false Getting a Boolean Value: OptionSetValue twoOptionsValue = entity.GetAttributeValue<OptionSetValue>(“two_options_attribute”); bool isSelected = twoOptionsValue?.Value == 1; // Assuming 1 is ‘Yes’ Setting a Boolean Value: entity[“two_options_attribute”] = new OptionSetValue(1); // Set to ‘Yes’ DateTime DateTime fields are used for date and time information. Getting a DateTime Value: DateTime? createdOn = entity.GetAttributeValue<DateTime?>(“datetime_attribute_name”); Setting a DateTime Value: entity[“datetime_attribute_name”] = DateTime.UtcNow; // Set to current date and time Image Image fields store binary data like photos or documents. Getting an Image: var image = entity.GetAttributeValue<EntityImage>(“image_attribute”);byte[] imageData = image?.ImageData; // Assuming you handle the image type properly Whole Number Whole numbers are represented as int. Getting a Value: int wholeNumber = entity.GetAttributeValue<int>(“whole_number_attribute”); Setting a Value: entity[“whole_number_attribute”] = 42; Floating Point Number Floating point numbers allow for decimal values. Getting a Value: float floatingPointNumber = entity.GetAttributeValue<float>(“floating_point_attribute”); Setting a Value: entity[“floating_point_attribute”] = 3.14f; Decimal Number Decimal fields store precise decimal values. Getting a Value: decimal decimalNumber = entity.GetAttributeValue<decimal>(“decimal_number_attribute”); Setting a Value: entity[“decimal_number_attribute”] = 123.45m; Setting Data Types After retrieving the desired values and possibly making changes, you need to update the entity. This is done using the Update method. service.Update(entity);    Some Additional Data Types you Might Encounter in Dynamics 365 C# Plugins such as : 1. Guid Getting a Value: Guid uniqueId = entity.GetAttributeValue<Guid>(“unique_attribute”); Setting a Value: entity[“unique_attribute”] = new Guid(“d3c1d9c8-7438-44b5-91b1-f40241b0f84d”); 2. Composite Fields Getting a Value: string city = entity.GetAttributeValue<string>(“address1_city”); string state = entity.GetAttributeValue<string>(“address1_stateorprovince”); Setting a Value: entity[“address1_city”] = “Seattle”;entity[“address1_stateorprovince”] = “WA”; 3. Unique Identifier (Primary Key) Getting a Value: Guid entityId = entity.Id; Setting a Value: Entity newEntity = new Entity(“entity_logical_name”) {     Id = Guid.NewGuid() }; 4. PartyList (Used in Activities) Getting a Value: string city = entity.GetAttributeValue<string>(“address1_city”); EntityCollection partyList = entity.GetAttributeValue<EntityCollection>(“to”); foreach (Entity party in partyList.Entities) {     EntityReference partyRef = party.GetAttributeValue<EntityReference>(“partyid”);     // Do something with partyRef }   Setting a Value: Entity party = new Entity(“activityparty”); party[“partyid”] = new EntityReference(“contact”, new Guid(“c3e4b159-64af-4c3d-b894-6d62007dbe79”));   EntityCollection partyList = new EntityCollection(new List<Entity> { party }); entity[“to”] = partyList; Conclusion Handling various data types in Dynamics 365 plugins is critical for creating robust and adaptable solutions. Knowing how to work with fields such as text, currencies, lookups, option sets, and others enables you to manage data more precisely and conduct custom activities in our CRM. With these examples, you now have the ability to retrieve and set values for a variety of common data types, making it easy to create plugins that match our organization’s requirements. As you gain experience, you’ll notice that handling data in plugins becomes easier, allowing you to focus on developing smart and effective solutions. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Azure Service Bus, paired with Logic Apps, offers a powerful combination for sending, receiving, and managing messages between different applications and services. In this blog, we’ll walk through the process of sending and receiving messages using Azure Service Bus and Logic Apps. Steps to send and receive messages from service bus using logic app Step 1: Create an Azure Service Bus Namespace Navigate to the Azure Portal: – Go to portal.azure.com and log in with your credentials. Create a Service Bus Namespace: – In the search bar at the top, type “Service Bus” and select Service Bus from the results. – Click + Create to start the creation process. – Fill in the required details: Click Review + Create, and then Create to deploy the namespace. Step 2: Create a Queue or Topic in the Service Bus Namespace Access the Service Bus Namespace: – After the namespace is deployed, navigate to it by clicking on the resource in the portal. Create a Queue or Topic depending on your use case I am going to use: – Creating a Queue: Step 3: Create a Logic App to Send Messages to the Service Bus Navigate to Logic Apps: – In the Azure portal, use the search bar to find and select Logic Apps. – Click + Create to start a new Logic App. Configure Your Logic App: – In the Basics tab, provide the following details: – Click Review + Create, and then Create. Design the Logic App: – Once the Logic App is created, open the Logic Apps Designer and a trigger “When a HTTP request is received” along with POST request. – Add a compose action and pass the input parameters. – Go to Service bus –> Shared access policies –> Copy the Connection String Endpoint url – Add action Service Send Message and paste the copied end point in Connection String. – Pass the Output of compose in content. – Add a response action and the logic app workflow. – Now Copy the Url from trigger and paste it in postman hit the url. – As soon as you hit the url you will get customer Id as response in postman body. – Now Go to azure portal and check the run history I will see the Date and Status has been added for that particular customer id. – Now, Let’s verify this particular message whether it has been sent at the logic level or not. – Go to queue in my case Queue name Is “receivingqueue” –> Go to Service bus Explorer –> Click on Peek form Start. – Now in order see the content/ Message select the sequence number Step 4: Create a Logic App to Receive Messages from the Service Bus – Create a New Logic App: Repeat the steps to create a new Logic App. – Go to Logic app designer. – Add the Trigger “When a message is received in a queue”. – Add a compose action – Add a Terminate action on Succeeded. – Now to verify you check the run history of logic app you can we are getting the content in base64 Format – You can decode it and check it’s the same data that we were sending. Conclusion We’ve successfully set up a messaging system with Logic Apps and Azure Service Bus by following these steps. This configuration makes it possible to automate workflows, integrate apps seamlessly, and create reliable cloud solutions. Whether you’re working with batch processing or real-time data, Azure’s tools give you the strength and flexibility you need to scale your business effectively.

If you’re finding it challenging to decide when to use Azure Service Bus Queues or Topics, this blog is for you! In our previous blog, we explored Azure Service Bus Queues, Topics, and Subscriptions. To recap, Azure Service Bus is a fully managed messaging service provided by Microsoft Azure. It helps decouple and scale applications by allowing different components to communicate with each other through messages. In this blog, we will delve deeper into Azure Service Bus Queues vs. Topics, examining their differences, use cases, and how to choose between them based on your application needs. By understanding these core concepts, we’ll be better equipped to design scalable and efficient messaging solutions using Azure Service Bus. Azure Service Bus Queues vs. Topics Service Bus Queues Queues work on a First In, First Out (FIFO) basis. This means that clients that receive messages from the queue and then process that message in the order in which they were added to the queue, and they will be the only consumer that processes this message. The queue will store this message until our client is able to process them. To process the message, the client will pull the message off the queue. Purpose: Queues are designed for point-to-point communication. They are ideal when a single consumer needs to process messages from a single sender. Message Handling: Messages are stored in a queue and processed by a single consumer in a first-in, first-out (FIFO) manner. Use Case: Best suited for scenarios where a specific task needs to be handled one at a time. For example, in an order processing system where each order needs to be managed sequentially. Fig – Message Queue with Messages One of the benefits of using queues is that producers and consumers do not need to exchange messages simultaneously. Messages are stored in the queue and are processed only when the consumer retrieves them. This setup enables producers to continue sending messages to the queue independently. Consequently, components within our architecture can be decoupled, as producers and consumers are not required to synchronize their actions. If there is a high volume of messages entering the queue, we can scale up the consumers without needing to scale the producers. Service Bus Topics Topics are different to Queues since instead of working with a single consumer, we can have multiple subscribers to our topic, who will receive their own copy of the message from the topic. This works in a pub/sub pattern, where we will have messages being published to the topic and have multiple clients subscribe to that topic. Purpose: Topics are designed for publish-subscribe communication. They allow messages to be sent to a topic and processed by multiple consumers. Message Handling: Messages sent to a topic are delivered to multiple subscriptions. Each subscription can have its own filter and process messages independently. Use Case: Ideal for broadcasting messages to multiple systems. For instance, a CRM system might need to notify various departments (e.g., sales, marketing) about a new customer record. Fig – Topic with three Subscription with Messages In Topics, our consumers don’t directly consume the message from our Topic. Instead, we create subscriptions that subscribe to the topic and our consumers receive a copy of a message from the topic. In Azure Service Bus, we can define filters on these subscriptions that determine conditions for messages to be published to a subscription and actions that modifies the message metadata. Conclusion In this post, we discussed the differences between Queues and Topics in Azure Service Bus. To summarize, Azure Service Bus Queues are ideal for point-to-point communication in which messages must be handled sequentially by a single consumer. Topics, on the other hand, are suitable for scenarios that need publish-subscribe patterns, as they enable several consumers to process the same message independently. Choosing the proper solution is determined by your application’s, individual requirements, ensuring that your message system is both scalable and efficient. If your system requires sequential processing and single customers, queues are the best option. However, if your system wants to broadcast messages to several users, Topics will give the necessary flexibility and scalability. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Introduction In Dynamics 365 CRM, integrating with external systems, running automated processes, and developing custom applications often requires non-interactive access to CRM data. One of the most secure and efficient ways to achieve this is by creating an Application User via the Azure Portal. In this blog, we’ll guide you through the step-by-step process of setting up an Application User and explain when and why you should use it in your CRM environment. Steps to Create an Application User: – Navigate to the Azure Portal and log in with your Azure account. – Search for Azure Active Directory or select from the left-hand menu. – Click on “App registrations” in the Azure Active Directory blade and click on “New registration”. – Enter the following details: – Click “Register”. – Select the newly created application from the App registrations list and click on “API permissions” in the left-hand menu. – Click on “Add a permission”. – Select “Dynamics CRM”. – Select “Delegated permissions” and check the necessary permissions such as user_impersonation. – Click “Add permissions”. – Click on “Grant admin consent for [your organization]” and confirm. – Go to “Certificates & secrets” in the application settings. – Click on “New client secret”. – Add a description (e.g., “CRM App Secret”) and set an expiry period. – Click “Add”. – Copy the value of the client secret and store it securely. You will need it later. – Add Application User in Dynamics 365 CRM – Log on to the Microsoft Power Platform Admin (D365 Admin) centre as a system administrator. – In the navigation pane, go to Environments, and then select an environment form the list. – On the Settings tab, go to Users + permissions, and then select Application users. – The application users page appears. – Click + New app user. – After clicking on + New app user. A side menu slider will appear. Here you will have to: When to Use an Application User Conclusion Creating an application user in Dynamics 365 CRM via the Azure Portal is a straightforward process that enhances the integration capabilities and automation potential of your CRM environment. By following the steps outlined above, you can set up an application user and leverage it for various integration and automation scenarios. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Introduction Azure Service Bus is a fully managed, multi-tenant cloud messaging service functioning as a brokered messaging system. In a software-oriented architecture (SOA), application components interact through communication protocols over a network, facilitated by the Service Bus. This article provides an overview of Azure Service Bus, highlighting its role in integrating systems like Microsoft Dynamics 365 CRM with third-party e-commerce platforms. Real-World Scenario: Integrating Dynamics 365 CRM with an E-commerce Platform Azure Service Bus is instrumental in enabling seamless interaction between Dynamics 365 CRM and external e-commerce applications, enhancing data management and operational efficiency. – Customer Data Synchronization: Customer data from the e-commerce platform is transferred to Dynamics 365 CRM using Service Bus queues, ensuring the CRM system reflects the latest information. – Order Processing: When an order is placed, it triggers a message to Dynamics 365 CRM, streamlining order fulfilment and tracking through Service Bus topics and subscriptions. – Inventory Management: Inventory levels are updated in real-time across both systems. Messages sent through Service Bus ensure accurate stock levels, preventing overselling. – Customer Support Integration: Customer support tickets from the e-commerce platform are channelled to Dynamics 365 CRM, providing a comprehensive view of customer interactions and improving support quality. Use Case Real-Time Data Synchronization Between Dynamics 365 CRM and Finance & Operations Scenario: Imagine a company that uses Microsoft Dynamics 365 CRM for customer relationship management and Dynamics 365 Finance & Operations (F&O) for financial and inventory management. To ensure consistent and accurate data across these systems, especially regarding inventory levels, real-time data synchronization is essential. Solution: In this integration scenario, the goal is to synchronize inventory levels between Microsoft Dynamics 365 CRM and Finance and Operations (F&O) systems to ensure real-time accuracy. The process starts with Dynamics 365 CRM, where changes in inventory, such as sales or restocking, trigger an event. This event generates a message containing the updated inventory details, which is then sent via Azure Service Bus. Azure Service Bus serves as a reliable messaging service that decouples the CRM and F&O systems, facilitating smooth communication between them. Once the message reaches Azure Service Bus, it is picked up by an Azure Logic App. The Logic App orchestrates the integration process, potentially using Azure Functions for tasks such as data transformation, validation, or enrichment. For instance, it may convert the message into a format compatible with the F&O system, such as OData, a standard protocol for data exchange. After processing, the transformed data is sent to the F&O system, where the inventory levels are updated accordingly. This setup ensures that inventory records are synchronized in real time across both systems, preventing issues like overselling by maintaining up-to-date stock levels. The use of Azure Service Bus and Logic Apps not only supports real-time communication but also offers a scalable and flexible integration solution that can adapt to evolving business needs. Key benefits of this approach include real-time updates, fault tolerance through message persistence and retry logic, and the flexibility to scale and integrate systems without tight coupling. Azure Service Bus Queues and Topics and Subscriptions Azure Service Bus offers Queues and Topics and Subscriptions as core features, enabling different messaging patterns to suit various use cases. Queues facilitate point-to-point communication, while Topics and Subscriptions support a publish-subscribe model. This flexibility allows for efficient data transfer and processing across applications. Stay tuned for my next post, where we’ll explore the specific scenarios in which to use queues versus topics and subscriptions. Conclusion Azure Service Bus provides a versatile and reliable messaging solution for building scalable, decoupled distributed applications. By integrating seamlessly with the broader Azure ecosystem, Service Bus empowers developers to create efficient communication channels, enhancing the performance and reliability of their applications. Whether you’re modernizing existing systems or developing new cloud-native applications, Azure Service Bus is an essential tool for delivering an excellent user experience. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com