In an ideal world, all changes to a production Dynamics CRM instance would come from a single development instance where the developers were working only on one feature at a time. Reality can be a different story. A production instance will likely include fields from imported packages that your dev environment won’t have, and your dev instance may have multiple features under development at the same time. In these cases, it’s important to know how Dynamics handles solution exports and imports on entities that have overlapping entity changes.
In this dev environment, I’ve created a solution named “Test Solution Export”. I then added the core entity Address to the solution. Working with a core entity should be a decent representation of a real scenario where multiple packages are making changes on a common entity. In this dev solution, I’ve added a single custom field to Address: Field A.
In this alternate instance, I’ve created a solution named “Test Solution Export 2”. I followed the same procedure as I took in dev by adding the core Address entity and adding a custom field. The only difference is that the field I created in my alternate instance was named Field B.
After exporting the solution in dev, I imported the solution in my alternate environment. As a result of the import, the alternate environment Address now includes both Field A and Field B. This proves that the solution import is additive, not overwriting in its approach to handling changes in a shared entity.
It’s also important to know how Dynamics exports entity changes when there are changes in a shared entity from a different solution. In dev, I added a new solution named “Test Solution Export 3” where I again added the address entity. Then I added a new field to address: Field C. I exported the original “Test Solution Export” out of dev.
I backed all the changes out of the alternate environment, then imported the newly updated “Test Solution Export”. The end result was that all 3 columns now exist on the Account Object. Field A came from the original dev change. Field B already existed in production. Field C was pulled in from the “Test solution Export 3” change even though the solution we exported was, “Test Solution Export”.
If two different solutions both add fields to a common entity, importing will only add new fields to the entity. It won’t undo the entity changes the other solution made to the entity. The other takeaway is that when you add an existing entity to the solution you’re developing, all changes to that entity will get exported with your solution regardless of which solution the changes were made in. This is especially important if your team does feature-based deployments where multiple features are being worked on in dev concurrently. Basically, this means that release planning should be a regular part of your process.
For more information regarding custom Dynamics CRM development, training, or assistance, contact our expert dev team today!
Salesforce integration consulting is about more than just finding a partner with experience in integrations.…
Platform: HubSpot Where It Shines: Email marketing - easy to use email lists, automation, and…
Don’t be left behind by neglecting these 2024 manufacturing trends.
With a comprehensive ERP like CloudSuite Industrial (CSI) from Infor, there are countless possibilities for…
An Infor ERP solution isn’t just a temporary fix to today’s issues, it’s an investment…
An Infor ERP can dramatically improve your operations, but with an ERP integration, you can…