CODEWITHSUNDEEP
dynamics-crmdynamics-crm-online
Don Cheadle
Don Cheadle

Reputation: 5576

Importing Unmanaged Solution from Dev does not remove Field from Form added in QA

In all environments, there is a field MXM_RemoveMe we want gone from the Account "Information" Form (one of the Account's OOTB Managed Forms, but of course we've customized it on our own a lot by now)

In Dev, I remove MXM_RemoveMe from the Account "Information" Form.

I put that Form in an Unmanaged solution in Dev, export and import into QA. Publish all.

Problem: but the "MXM_RemoveMe" field is STILL on the form in QA.

What could cause this? Do we have to manually remove fields from Forms in all environments? I don't think that's the case normally.

I've verified this behavior in a specific test after the fact. If I add a field to the Account form in QA... then export/import from Dev that Form (Unmanaged) WITHOUT the field... it still stays in QA! I encourage everyone else reading this to do this simple test themselves and see the same behavior I see.

How should this be handled/understood?

Upvotes: 1

Views: 1634

Answers (2)

AdAstra
AdAstra

Reputation: 1984

I might be wrong here but this might be changed in the modern make.powerapps.com compared to how it worked in the classic import experience. You might have the option to overwrite your customizations there(not recommended).

https://learn.microsoft.com/en-us/powerapps/maker/data-platform/update-solutions#overwrite-customizations-option

Probably the safest way is to manually go about and delete the components.

Could have to do with solution layering and using the accounts OOTB managed form. Usually, id say it is better to use a custom form

Upvotes: 1

Henk van Boeijen
Henk van Boeijen

Reputation: 7918

I think this is because the form itself is managed. The system simply adds fields to the form on import and does not simply overwrite unmanaged changes any more. In older versions of Dynamics CRM this did not work this way though.

When you prefer to continue working with unmanaged solutions (I feel there are valid reasons to do so), a best practice would be to always copy managed forms first and modify, export and import the copy instead of it.

The copy would be in its entirety an unmanaged form. Up to now I have never seen issues with those forms when imported in target environments in an unmanaged state.

Upvotes: 1

Related Questions