Dynamics 365 Integration: Testing Best Practices

Testing the data flow within two separate systems to ensure accuracy and consistency of data is called integration testing. Microsoft Dynamics 365 can be integrated with other systems. First, let’s take a look at a few ways we can leverage integrations and some examples of why we might use one of these integrations. Then we’ll take a look at how test that data flow.

Integration between Dynamics 365 and an External Database

This is very common scenario where CRM is integrated with another application’s database. For example, Contact, Accounts, or System User data is pulled from Feed-Store and stored locally in CRM for further business processes. Data is pulled from external systems using SQL jobs or by Web service calls. The frequency to pull data depends on how often the data is been modified in the source system.

Integration between Dynamics 365 and a Web Form

Web Forms enable external individuals (non-Dynamics 365 users) to submit a request to Dynamics 365. For example, a customer logs into an external system and inquires about a product and then a lead is created in Dynamics 365.

Integration between Dynamics 365 and a Portal

The integration of Dynamics 365 with a Portal allows the users of the portal to submit requests into Dynamics 365. For example, a customer logs into a portal and submits a request for support for an installation that they bought – then a case is created in Dynamics 365.

Web-Service is consumed by Dynamics 365

The source system may expose a web-service such that Dynamics 365 retrieves the data from their system so that the business rules are honored. For example, the products data is stored in an external system but is consumed by Dynamics 365 for creation of Quotes and Orders to complete the sales process in Dynamics 365.

Web-service is exposed by Dynamics 365 for External Applications

Sometimes the external system needs data from Dynamics 365 for further processing in their system. For example, upon qualifying a lead, an Opportunity, Account, and Contact is created. Dynamics 365 exposes the unique ID created for the Opportunity to an external system.

These tests scenarios cover validating Dynamics 365 interactions with any of the above mentioned external systems.

• Data mapping – Data mapping is to map source data fields to their related target data fields. For example, source data field A goes into target data field X. Before the tests are performed, be sure to get the mapping sheet from your team and cover the test cases such that every field is validated. If the fields are not correctly mapped, then the data flows to the wrong field.
• Consistency of the Data Type – The data type and field size of the fields should be consistent in both the systems. For example, a text field of size 250 characters in source system should be mapped to text field of size 250 characters in Dynamics 365.
• CRUD Operation – The Create, Read, Update, and Delete operations should be performed to ensure that new and updated data is flowing to the Dynamics 365 system. The tests should ensure that updates to data in the source will bring the data in Dynamics 365 application and keeps the systems synchronized.
• Count of Records – The records count in the source and Dynamics 365 system should be same when business rules are met in Dynamics 365.
• Failure Message – There must be a failure messages when one of the systems in the integration (Source-Staging-Destination) fails or the network is down between the systems.
• Verification of Records – A few of the records (it can be 2 or 3 records) should be picked from the source and it should be verified with the corresponding set of records in the Dynamics 365 system to ensure that the data didn’t become corrupt during the data flow.
• SQL jobs Frequency – The frequency of the SQL job that pulls the data from source system depends upon how often the source data is being modified.

There you have it! What other testing best practices do you recommend?