The latest release of Connector for Microsoft Dynamics supports integrating multiple Microsoft Dynamics ERP companies into a single Microsoft Dynamics CRM organization. Connector supports these scenarios if an instance of a Microsoft Dynamics CRM entity can tell Connector which company in the Microsoft Dynamics ERP it needs to be sent to. When this occurs, Connector honors that attribute and sends the entity to the appropriate Microsoft Dynamics ERP Company.
There are a number of mechanisms that you can use to customize Microsoft Dynamics CRM to provide this information. Then, you can use a filter in each map to specify which records integrate back to the Microsoft Dynamics ERP for the appropriate Microsoft Dynamics ERP company. And then records are sent into Microsoft Dynamics CRM, this property can be defined in the map as a constant value, since each pairing of a Microsoft Dynamics ERP Company and a Microsoft Dynamics CRM organization has its own unique set of maps. This posting IS NOT intended to be your guide for these types of deployments and integration scenarios, but we are trying to provide some insight into the upfront design considerations.
We are very specific about the scenarios that are be supported, however, because this functionality IS NOT how Microsoft Dynamics CRM naturally defines the data boundaries within the system today and serious data integrity / security concerns could arise, depending on the implementer’s specific scenarios. This means that the Microsoft Dynamics CRM administrator needs to be diligent in how this enterprise data is exposed to the users inside of Microsoft Dynamics CRM if there are security concerns.
Also, note that current Microsoft Dynamics CRM customizations are at the Organization level – meaning that if your Microsoft Dynamics ERP companies have different customizations in them, or they have different values for what corresponds to Microsoft Dynamics CRM Option Set Values (Picklists), you need to develop a way for your user to select the appropriate entry in Microsoft Dynamics CRM. For example, if Company A has "Federal Express" as a shipping method, and Company B has "FedEx" as a shipping method, then you need to customize all of the shipping method option sets in Microsoft Dynamics CRM to contain options similar to the following: "Federal Express –Company A"; "FedEx – Company B." The Microsoft Dynamics CRM user needs to know which company they want this data integrated to when they select the option set value. This is true for all option sets in Microsoft Dynamics CRM, so imagine what it will be like to manage Payment terms across all Microsoft Dynamics ERP companies in a single Microsoft Dynamics CRM organization – unless they are all the same across all of your companies. If all of your option set values are the same across all of your Microsoft Dynamics ERP companies, then you can reduce this overhead by several factors.
The implementer also needs to develop a way for salespeople in Microsoft Dynamics CRM to select which Microsoft Dynamics ERP company to send updates for accounts and contacts to. The implementer also needs to enforce this solution on any transactional data that is moving in both directions between each system, for example, sales orders. You could accomplish this with a drop down list or with Microsoft Dynamics CRM workflows / plugins that execute prior to integration. Or, you could use the Business Unit entity in Microsoft Dynamics CRM and filter on the well-known GUIDs for those entities within your deployment. Other issues might arise with entities in the Microsoft Dynamics CRM product catalog, asthey are mainly held at the organization level as well, and the various Microsoft Dynamics ERP companies might have different inventory, units of measure, and price lists. Many of these issues do go away if you are simply looking to integrate accounts / contacts and aren't interested in moving transaction data.
At a high level, there are two scenarios:
Other Microsoft Sites
I'm a Customer
I'm a Partner
Use the official Twitter tags:
#MSDYNCOMM | #CONV13