Dual-write offers a direct integration between Dynamics 365 applications (notably between CRM and ERP applications). With the use of this integration, application architects can now systemize end-to-end business processes and centralize previously siloed data.
Since the birth of Microsoft’s Power Platform, CFO’s observed the low-code/no-code capabilities of the scalable platform with jealousy. After all, Dynamics 365 Finance & Operations implementations remain highly complex, and the concept of a citizen developer is almost non-existent. Furthermore, what good is the Dynamics 365 ecosystem if it can’t be seamlessly integrated? In today’s modern world, a transaction’s lifecycle begins in a CRM and ends in an ERP system. But to truly understand the lifecycle of a sale and generate reporting around its successes and failures, the two systems must communicate.
Understanding a full lifecycle is important across all industries and the informational gain is relevant to all roles in a company. A Chief Marketing Offer (CMO), for example, must be able to understand Lifetime Value. A Sales Director, on the other hand, may want to understand Churn. A CFO may have a separate set of obstacles- they could want to understand primary acquisition strategies in order to continue funding the methods that work and pull back from the ones that don’t.
In this Ultimate Guide to Extending Dynamics 365 Finance With Power Platform, we’ll be consoling executives and citizen developers around the world by explaining how Dynamics 365 Finance can now fully integrate with Microsoft’s Power Platform. Furthermore, we’ll be discussing how Dynamics 365 Finance and Supply Chain Management can be extended using Power Apps. The scalability of the two platforms’ marriage will drive unique opportunities to garner data across all systems that can be leveraged by almost any role in a business.
Before we tap into the extensibility of Dynamics 365 Finance using the Power Platform, we must first understand the general architecture of Power Platform and its underlying database, Dataverse. I’d like to introduce some of Microsoft’s terminology wrapped around these aforementioned topics so that you may better understand the rest of the guide.
The first term worth acquainting yourself with is Dataverse. Dataverse is the underlying database. That is leveraged Dynamics 365 Customer Engagement as well as model-driven. Apps. Built using the Power Platform. The advantage of Dataverse lies in its ability to seamless centralize data across. All Dynamics 365 Customer Engagement applications (Dynamics 365 Sales, Customer Service, Field Service, and Marketing) along with model-driven apps and Power Apps (if you so choose to use the connector). This database is specific to the environment your applications reside in.
Data within Dataverse is stored within a collection of tables. For those familiar with SQL databases or Excel spreadsheets, you can think of Dataverse in terms of rows and columns. A table represents a set of rows and their relevant columns, or attributes. Each column contained in a table stores a type of data. A table could for example, represent a person (Contact). This Contact table could have relevant columns, or fields, that store their name, job title, phone number and more. When deploying a new Dataverse database, you’ll notice the base set of standard tables. Thanks to Microsoft’s use of the Common Data Model this out-of-box set of tables covers common business scenarios. This doesn’t mean, however, that you can’t create your own custom tables specific to your business. On the contrary, the upper-hand of Dataverse is its customizability and scalability– you can create as many custom tables and fields as needed. The Common Data Model simply offers a head-start by offering up data points leveraged by most businesses around the world.
Once your database is deployed and configured, you can use Dynamics 365 Customer Engagement applications and Power Apps to expose the tables and columns you’ve created.
So, let’s take a moment to talk about why a business would use Dataverse opposed to a SQL database, or another option. I’ve outlined some of the benefits of using Dataverse below:
Now that we’ve taken some time to understand the fundamentals of Microsoft’s Power Platform and relevant integration terminology, we can begin to understand how these components play together. Together, dual-write, business events, data events and virtual entities make up the shared data layer that acts as the convergence of Finance and Operations applications and the Dataverse platform. You. Can begin to view them not as separate platforms, but rather complimentary technologies intended to work together seamlessly.
Business Events allow you to use Power Platform to respond to events happening in Dynamics 365 Finance & Operations applications. When a process is run in the app with business logic, an event occurs. Business events can be raised from any app, including Finance, Supply Chain Management, Sales, Customer Service, Commerce, and more. These events subsequently can be handled by Power Platform business logic. The handling of the event includes querying or interacting with additional data through either tables native to the platform (native entities), or what we call virtual entities. Virtual entities differ from other tables, which you’ve learned about tables in the section above.
Virtual Entities are somewhat different from the tables covered above in that they are read only. Virtual entities enable scenarios where access to Dynamics 365 F&O data from Power Platform applications is required. For example, if you wanted to expose a Dynamics 365 Finance table inside of Dynamics 365 Sales, you would use a virtual entity to do so. When you do this data isn’t copied between systems. Instead, it’s accessed through a virtual entity infrastructure that Power Platform technologies can already bind to. Using this out-of-box infrastructure you can query data, bind forms and views to it, and use the full power of Power Platform against the full breadth of Dynamics 365 Finance and Operations applications.
Data Events, are similar to business events in that they enable external apps to receive notifications from Finance and Operations applications when an event occurs. An example of what could cause a data event, is a change to a record inside of Finance and Operations. External systems can then react to a notification with a record is created, updated, or deleted in the database. This allows Finance and Sales, or Customer Service to work closely together in a more transparent setting.
In some scenarios, data has to be physically copied over between platforms (Finance and Operations applications and native Dataverse tables). These scenarios involve overlapping tables that have out-of-box bound logic attached to them in both Dataverse applications and Dynamics 365 Finance applications. For this reason, data has to reside in the local database. For each type of app. These scenarios specifically wrap around the Core Tables. For example, it would make sense that both Dynamics 365 Sales and Dynamics 365 Finance have a table called Account. Another example of this scenario are the tables Company, Product, and Sales Order. To tackle these core tables, Microsoft has created dual-write, an integration connecting Dynamics 365 Finance applications and Dataverse. This integration works in near real-time synchronous physical copying of data. This way, existing applications can continue to operate against local data while ensuring that overlapping tables are kept in sync.
Dual-write can solve common business obstacles that require insight into end-to-end data. In the paragraph above, I offered a CMO (Chief Marketing Offer), having the obstacle of needing to see acquisitions data and how it translates into actual transactions. The acquisitions portion of this data could sit inside of Dynamics 365 Sales, while the recurring transactions, may sit inside of Dynamics 365 Finance- two completely separate platforms. A scenario like this could benefit from a Dual-write integration.
Below, I offer a few more typical scenarios that use Dual-write to address their obstacles:
Is there a requirement for real-time data?
Peak data volume
Frequency of scenario
The best way to remedy this obstacle is to create a real-time data synchronization between two systems- using Dual-write. Here’s a step by step explanation of how we can mirror our data using a Dual-write integration:
2. A sales representative needs to change a customer’s credit limits without leaving CRM and having to sign-in to a Finance and Operations application. In this case, let’s assume that a customer currently has a credit limit of $4,000 and wants to increase it to $6,000. This particular customer calls in and requests this increase. The support ticket is assigned to an Account Executive in the sales department. The Sales Manage reviews this request, reviews the customer’s payment history and determines that the customer is eligible for an increase in credit limit. The Sales Manager approves this request and resolves the ticket. The customer then receives an email about the approval for a $6,000 credit limit. Again, let’s break down the requirements in the table below and then discuss a Dual-write use to solve it.
Is there a requirement for real-time data?
Peak data volume
The best way to address this scenario would be to implement Dual-write. Here’s a step by step explanation of how Dual-write would address this:
When you create a new Finance and Operations applications environment inside of Microsoft Dynamics Lifecycle Services (LCS), you can enable the integration of Finance & Operations apps with Microsoft Power Platform.
Below, I outline the prerequisites for setting up the integration between Power Platform and Finance and Operations applications:
Upon deploying a new environment in LCS (Life Cycle Services), you are faced with a deployment wizard that offers several sections where you set values. One of these sections is titled Power Platform Integration.
Below, I’ve outlined the steps you’ll need to take in order to configure the Power Platform integration section.
I’m going to pause right here and advise you of a few important things:
In some cases, the integration is enabled during deployment of the Finance & Operations apps environment. If it isn’t, you can enable it inside of LCS after deployment. Below, I’ll walk you through the steps to set up the integration post-deployment:
Tip: The environment can take anywhere from an hour to an hour and a half to provision.
Once the Power Platform environment is provisioned, you’ll be able to see the Install a New Add-In and Dual-write Application buttons under the Power Platform integration section.
Now that the Power Platform environment has been deployed, and the integration is enabled, you unlock the ability to set up Dual-write. You can complete this portion of the set-up directly inside of Lifecyle Services (LCS). As mentioned above, Virtual Entities are tucked into the Power Platform environment through the Power Platform integration- this saves you serious time from having to sync these tables, since they are pre-connected. For the remaining tables, you can choose which to map between environments.
Book a free meeting and let us have a look at your opportunities with Microsoft Solutions
Discover how Avantiico helps you improve business processes, provide customers with a seamless experience and transform the way you do business.