In part two of this blog series, we examine the role of technology in enhancing the customer experience in government with a focus on streamlining and automating customer-facing processes.
When running your integrations between two CRM organizations with the Connector for Microsoft Dynamics and Microsoft Dynamics CRM 2011 Instance Adapter, it’s important to run your integrations in a specific order. Currently, the Connector does not offer a mechanism for ordering, so the task falls on the integrator.
The areas of concern are Picklists (Optionsets), system level entities (e.g. Business Units, Users, Teams) and entities with hierarchical relationships. We’ll highlight these concerns in the following sections.
Before you do anything else, you should integrate your picklists between the two organizations. Every entity has the possibility of having an optionset associated with it and you need to make sure that they are the same on either side.
What the Picklist integration does:
What the Picklist integration does not do:
While the CRM Instance Adapter is extremely capable when it comes to transferring data between organizations, there are some special cases to be aware of when transferring entities between the two systems. The following is a list of those entities:
Upon installing and configuring CRM, you are required to create a business unit. This becomes your root business unit, thereby making it impossible to transfer a root business unit from a different organization. If you want to have a separate business unit to represent the transferred data from the source organization, you have to create one manually. The Adapter is written so that, in the case of any entities that rely on the Business Unit, the name of the business unit is used to find matches. When creating or modifying the business unit on the destination organization, make sure it matches the name of the business unit in the source organization.
Since the Adapter is capable of transferring data between an on-premise environment and an online organization, it needs to be capable of relating users that may not share the same GUID or domain name. To accommodate this requirement, the Adapter utilizes the full name of the contact as its method for doing the matching. In the case of an online destination organization, you will need to create the users manually and associate them with the organization before being able to utilize them as references.
Teams are dependent on both Business Units and Users being configured before integration.
Security Roles are dependent on both Business Units and Users being configured before integration.
Throughout CRM, there are a ton of dependencies. One example of one such dependency is the account and contact entities. A contact entity can be associated with an account both as a child record and as a parent record. You might be asking yourself, if these kinds of dependencies exist, how are you supposed to have all the records relate to each other?
The great thing about the Microsoft Connector and the configuration utility for the Dynamic CRM Adapter, is that they’ve been configured so that if a reference isn’t found the entity will still be created on the destination organization. In addition, because the adapter is capable of updating entities as well as configuring them, we’re able to add detail back into them later.
In this manner, it’s good to run all mappings through the connector twice; once for the initial migration of the entities and a second time to resolve all their relationship dependencies. Luckily, the Connector for Microsoft Dynamics handles this inherently if utilizing a continuous integration between your two organizations. If you were not utilizing the continuous integration feature in your integration, you’d need to run each mapping manually a couple of times in order for the updates to take place.